While reading book, I wanted to remember and take some notes, since this book is a classic.

Note: this is currently not spell-checked and written on a train ride.

Key Concepts

Tips

1. Care about your work: We feel that there is no point in developing software unless you care about doing it well.
2. Think! About your work: Never run on auto pilot. This is a lifetime practice to do.
3. Good Enough Software: this does not mean you skip on requirements. It means that your software is good enough for your users, future maintainers, and your own peace of mind.
   • Include your users and the company in your "good enough software". Ask them what is it that they need from you. What can the company afford to do? It would be unprofessional to ignore these constraints.
4. Building Your Knowledge Portfolio - analogous to a financial portfolio.
   • Invest regularly: invest in your knowledge regularly, even if it's just a small amount.
   • Diversify: You should know more different things, the more valuable you become. Computing world changes rapidly, and it's good to know the new technologies and adjust to change.
   • Manage Risk: technology is on a spectrum of risky, low-reward, and high-reward. Don't put all your eggs in one basket. Don't be good at just one thing.
   • Buy low, sell high: Learning new technologies early on can be of great value. You can learn earlier, and then get the benefits later once you becomde an expert.
   • Review and Rebalance: revisit technologies that you have learned before, or skipped on learning when it was new.
5. Choose your moment to share ideas: don't bring up irrelavent asks when it's a a really bad time for someone else.

Challenges to Try

• Choose two "broken windows" and discuss with the team on the priorities, and how we can solve them. What are the benefits?
• Consider modularization of software. Can you ship smaller pieces in several milestones, and is that easier to deal with, than 1 monolithic release?

People and Culture

• Team trust: you have to trust in your team, and make sure that you can be trusted by your team. In a healthy environment, you can can safely speak your mind.
• Take responsibility: and when yu do, make sure that you can be held to it. when you make a mistake, admit it and try to offer solutions. You don't need to take responsiblity for everything, though. Imagine impossible situations and don't take responsibility for those, when possible.
• Be the soldiers with the stone soups: Ask the entire village what should be in the soup (software), and then try incorporarting it in your design. With everyone's ideas, you can probably make something great, and it benefits everyone.
• Communication: communication is super important. If you can be the best developer, most pragmatic, and hace the best ideas, it still won't be successful if you can't communicate your ideas to others.

Specific Concepts

DRY Code

DRY is more than just code. It's knowledge, documentaiton, workflows, and more. We want to reduce duplication across: internal APIS, external APIs, Data Sources (key/value store, hash, or external data), and functional programming

Make code easy to reuse. Make sure that the code you write is easy to use again by someone else, otherwise no one is going to do it.

Personal Thoughts and Criticisms

• Some of the ideas mentioned here are not relavent anymore, for existing developers that are trying to grow in their career. For example, one tip that is mentioned is to have Goals. They're definitely super important, but the examples mentioned are not. One example was to "learn a new language every year" and I think this is not one that belongs with my career path anymore. You can learn any new language as it's needed, but software design principles are should be learned as you go along.
• DRY Code: The book explains DRY as one of the core concepts, and that's amazing in an academic setting and "perfect code". However, companies don't work in a perfect environment , and often require trial and error to get the requirements correct.
  • I feel that we should have DRY code, but don't be afraid to repeat yourself sometimes, until it's required to keep it DRY.
  • For example, you can have 2 functions that are for similar concepts in different code bases, but maybe one only needs 10% of the code to run. Would you rather use the other 90% of the code as well, when you only need 10%? Or, just write the 10% of code in the codebase which is easier to understand, and live with some repeated code?
  • I find that instead of making code easy to reuse from the get-go, it's a lot better to make sure that your code is refactorable so it can be reused. Having good programming practices and testing can make sure that someone else can update your code effectively and easily for their own use case, without breaking the existing use cases.

Go back home.