I was reading 97 Things Every Programmer Should Know in my spare time. Here are notes on what caught my attention.

  • Technical debt must be repaid immediately in the next iteration. Otherwise, the interest will accumulate.
  • You must resist the impulse and temptation to rewrite from scratch. Make the most of existing code.
  • When adding new changes, improve at least one place.
  • Writing code is designing. It’s not mechanical work, but creative work.
  • The purpose of code reviews is not just to fix errors, but to establish shared ownership of code.
  • Comments should contain things that are valuable to readers. That is, things not written in the code or things that cannot be written in code.
  • Start deployment work from the early stages of the project.
  • If you spend 10,000 hours, you can definitely become an expert. It’s almost a matter of your will to become one.
  • Windows 2000 contains “TERRIBLE HORRIBLE NO GOOD VERY BAD”. Don’t use data that would be embarrassing if seen.
  • The troublesome ones are people who are not programmers now but have “done a bit of programming” before.
  • After checking in to SCM, developers should become observers
  • Developers don’t access environments beyond the development server, QA/customers don’t access the development server
  • Test not only the API itself but also the code that uses the API
  • Hard work doesn’t pay off. The more you reduce the time and effort you work, the greater your contribution to the project.
  • You must not neglect the study of knowledge and skills.
  • Bug reports should include how to reproduce the bug, frequency, expected specification, and actual behavior.
  • Learn a second language with a different paradigm.
  • Know the time and space complexity of data structures and algorithms.
  • When asked for an estimate, distinguish between estimate, target, and commitment.
  • If the interface is good, it’s easier to use correctly than to make mistakes.
  • Use message passing instead of shared memory.
  • Testers are not enemies but friends.
  • Version control information about the environment as well.
  • Mutual understanding requires shared experience, not shared definitions.
  • The singleton pattern is disadvantageous in terms of testability and maintainability.
  • Ubuntu means compassion for others in Zulu.
  • Write code thinking you’ll support it for life.
  • Tests are written for people who will read them.
  • Frequently question customers. It’s good to rephrase what the customer said in your own words.
  • It’s important to use diagrams and drawings during discussions. It’s also good to create mockups early in the design.
  • When handling state, be aware of state machines.
  • Give code names. Names that are familiar and well-known are good. A password for team unity.
  • Even if it’s simple work, it’s good to leave room for routine work at the beginning of the day.
  • It’s good to find a mentor.
  • Pursue a comfortable environment.
  • If you faithfully respond to requests from vocal users, you’ll end up with bug-prone software. You’ll fall into Feature Creep.
  • Be particular about naming. It’s an important part of feature design.