- p. xvi: №1 Care About Your Craft. Not just care about being right, or care about being respected: care about your craft.
- p. xvi: №2 Think! About Your Work. It’s hard work but rewarding. You’ll improve in your craftsmanship.
- p. 1: №3 You Have Agency. “You can change your organization or change your organization.” —Martin Fowler
- p. 4: №4 Provide Options, Don’t Make Lame Excuses. You can factor in everything that went wrong—including that which is outside your control—but holding yourself accountable and providing options to move forward shows humility and dedication to your craft.
- p. 7: №5 Don’t Live with Broken Windows. Hey, that project you worked on where that suite of tests didn’t pass but you never fixed it? It’s only getting worse…you’ve stopped writing new tests.
- p. 9: №6 Be a Catalyst for Change. “It’s easier to ask for forgiveness than it is to get permission.” —Rear Admiral Dr. Grace Hopper
- p. 10: №7 Remember the Big Picture. This differs from tip № 7, in which one stops caring. When you lose sight of the big picture, you just don’t notice how things deteriorate.
- p. 12: №8 Make Quality a Requirements Issue. Perfect is the enemy of good
- p. 15: №9 Invest Regularly in Your Knowledge Portfolio. Invest regularly; diversify; manage risk; buy low, sell high; review and re-balance.
- p. 17: №10 Critically Analyze What You Read and Hear. Perhaps even get into a good discussion with a friend.
- p. 20: №11 English is Just Another Programming Language. Write natural language as you would natural code: honor the DRY principle, the ETC principle, automation, etc.
- p. 22: №12 It’s Both What You Say and the Way You Say It. The more effective your communication, the more influential you can become.
- p. 23: №13 Build Documentation In, Don’t Bolt It On. Comment source code with the why; how should be apparent in your code. In‐code comments can capture engineering trade‐offs, why decisions were made, what other alternatives were discarded, etc.
- p. 28: №14 Good Design Is Easier to Change Than Bad Design. ETC (Easier to Change) is a value—not a rule—that is the beating heart of many complex design principles. If you’re not sure what is the appropriate change toward ETC, try to make what your code replaceable and describe the situation in your engineering daybook (tag it). When it’s time to change the code, review your notes and train your initial instinct.
- p. 31: №15 Don’t Repeat Yourself. Applies to code, documentation, data, APIs, even developer knowledge.
- p. 38: №16 Make It Easy to Reuse. Foster an environment where it’s easier to find and reuse existing stuff than to write it yourself.
- p. 40: №17 Eliminate Effects Between Unrelated Things. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design calls this cohesion. We want to design components that are self-contained and independent of each other—components that have a single, well-defined purpose. >
- p. 48: №18 There Are No Final Decisions…not even this one.
- p. 49: №19 Forgo Following Fads. Your code will be far more durable if you don’t make decisions based just on what’s hot now.
Archives for February 2024
Documentation
Thoughts on Documentation
My idea workplace will faithfully document institutional knowledge in order to empower developers. When one person holds up a team because they’re busy holding up the team (see what I did there), that team needs to level themselves up. They should not be satisfied to let the one teammate carry the team. Do the hard work of the debrief and learn, then document. Document because knowledge is power, and you want a strong team.