The Missing README Reading Notes

• The four areas that software engineers should be competent in:
  • Technical knowledge
  • Execution: create value by solving problem with code
  • Communication
  • Leadership: help new team members, give meaningful feedbacks
• Experiment with side projects
  • Don't choose projects based on what you think need to learn. Focus on problem solving and solve the problems using the tools you want to learn. A goal that intrinsically motivates you will keep you engaged longer.
• Asking Questions
  • Use these three steps:
    1. Do research
    2. Ask clear questions
    3. Time your questions appropriately
  • When asking:
    • Show your work: Outline what you have tried and discovered succinctly. This signals that your have spent some time in understanding and solving the problem, it also gives others a starting point for their answer.
    • Don't interrupt
    • Prefer Multicast, Asynchronous Communication
    • Batch Your Synchronous Requests: Chat and email are great for short questions, but complex discussions don't work asynchronously. In-person conversations are 'high bandwidth' and 'low latency'. But it is costly, though. Interrupting your coworkers affects their productivity. Avoid this by setting up dedicated time with tech lead or manager for nonurgent questions, write down the questions and hold them before the meeting.
• Overcoming Growth Obstacles
  • Imposter Syndrome: It is self-reinforcing. Every error is seen as a proof of incompetence. Meanwhile, every success is a evidence of a good 'faker'. Once people enter this cycle, it is difficult to get out of. Awareness helps: if you watch for this pattern, you can consciously break it. When you accomplish something, it's because you actually did it - you aren't just getting lucky.
  • The Dunning-Kruger Effect: To solve it, cultivating a mindset of trade-offs, not of right and wrong.
• Some other resources:
  • Dave Hoover and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman (O’Reilly Media, 2009) is a great collection of “patterns” one can use to get started in a new environment, seek guidance, learn skills deeply, and overcome common hurdles.
  • For more on asking questions, we recommend All You Have to Do Is Ask: How to Master the Most Important Skill for Success by Wayne Baker (Currency, 2020). This book is divided into two parts. The first section discusses the value of asking questions and why it’s hard. The second half of the book is a toolkit for asking questions effectively.
  • For more on pair programming, the classic text is Extreme Programming Explained: Embrace Change by Kent Beck and Cynthia Andres (Addison-Wesley, 2004). The book covers much more than just pair programming. If you are interested in a shorter read, the article “On Pair Programming” by Birgitta Böckeler and Nina Siessegger at https://www.martinfowler.com/articles/on-pair-programming.html is an excellent practical guide.

About the code

• Addressing Technical Debt
  1. State the situation factually
  2. Describe the risk and cost of the debt
  3. Propose a solution
  4. Discuss alternatives
  5. Weight the trade-offs
• Legacy Code Change Algorithm
  1. Identify change points
  2. Find test points
  3. Break dependencies (change the code to make the test easier, since test points are not easily accessible for most of the cases)
  4. Write tests
  5. Make changes and refactor
• Try to keep the code-cleanup commits separate from your behavior changing commits. Separating commits makes it easier to revert code changes without losing code-cleanup commits.