• 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.

Before the Project

This chapter will focus on project management from an agile perspective (framework-free).

The Requirements Pit

Requirements gathering is more like requirements digging—nobody knows exactly what the want. Programmers help people understand what they want. The requirement (once expressed) should be seen an invitation to explore.

For example, the statement “Shipping should be free on all orders over $50.” should beget a bevy of questions about including tax, which shipping methods are included, internationalization, frequency of changing that $50 number, etc. The client (who has great domain knowledge, hopefully) has probably thought of some of these cases, but discussing them helps flesh out the actual requirements. A developer’s role is to interpret what the client says and feed back to them the implications.

Requirements are a process. They are learned in a feedback loop. Help your client understand the consequences of their stated requirements. Sometimes you won’t know the domain of knowledge well enough to provide salient feedback, so use “is this what you meant?” through mockups and feedback.

Walk in your client’s shoes. Work with a user to think like a user.

There’s a difference between requirements and policy. Policy should be metadata. Policy can be something like “Only an employee’s supervisor and the personnel department may view that employee’s record.” Taken literally as a requirement, it might be hard-coded. Taken as policy, you’d build / use an access control system that allowed authorized users to view a record—defining what is an authorized user would then be metadata (or configuration).

There’s also a difference between doing what the requirement asks, but not how the customer wants. Early prototypes and tracer code are key to nailing both.

Requirements are best recorded as user stories—describing a small portion of what the application does from the perspective of the user. Keep the stories small enough to fit on an index card (real or virtual), which encourages develpoers to ask clarifying questions (record the answers, for documentation).

Developers should maintain a project glossary that contains all domain-specific vocabulary for that project. It’s hard to succeed on a project if users and developers cal the same thing by different names.

Section Challenges

• [ ] Exercise 33 Which of the following are probably genuine requirements? Restate those that are not to make them more useful (if possible).

1. The response time must be less than ~500ms.
2. Modal windows will have a gray background.
3. The application will be organized as a number of front-end processes and a back-end server.
4. If a user enters non-numeric characters in a numeric field, the system will flash the field background and not accept them.
5. The code and data for this embedded application must fit within 32Mb.

• [ ] Can you use the software you are writing? Is it possible to have a good feel for requirements without being able to use the software yourself?
• [ ] Pick a non-computer-related problem you currently need to solve. Generate requirements for a non-computer solution.

Solving Impossible Puzzles

The key to solving puzzles is both to recognize the constraints placed on you and to recognize the degrees of freedom you do have, for in those you’ll find your solution. Challenge any preconceived notions and evaluate whether or not they are real, hard-and-fast constraints. Categorize and prioritize your constraints.

You can help yourself solve puzzles by getting out of your own way. If you get stuck, do something else so that you let your subconscious (an amazing associative neural net) can process it. If you can’t do that, try to explain the problem to someone. And, like Hitchiker’s Guide to the Galaxy says, “DON’T PANIC”.

Section Challenges

• [ ] Take a hard look at whatever difficult problem you are embroiled in today. Can you cut the Gordian knot? Do you have to do it this way? Do you have to do it at all?
• [ ] Were you handed a set of constraints when you signed on to your current project? Are they all still applicable, and is the interpretation of them still valid?

Working Together

I’m a lover of pair programming, so this section really resonated. I love the resultant product that comes from the tensions of two people (or more) working out a solution together. I think two is almost always better than one.

• [ ] Have you tried pair programming? What was your experience?

The Essence of Agility

From the manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Any framework or method that pushes the right side over the left side should be abandoned. Agility is:

1. Work out where you are.
2. Make the smallest meaningful step towards where you want to be.
3. Evaluate where you end up, and fix anything you broke.

Section Challenges

• [ ] The simple feedback loop isn’t just for software. Think of other decisions you’ve made recently. Could any of them have been improved by thinking about how you might be able to undo them if things didn’t take you in the direction you were going? Can you think of ways you can improve what you do by gathering and acting on feedback?

While You Are Coding

Coding is an intensely creative act that happens through instincts / nonconscious thoughts and the active thoughtful application of principles.

Listen to Your Lizard Brain

The first trick is to notice that it’s happening; then work out why. You may not be able to, but try to crystallize it into something solid that you can address. Let your instincts contribute to your performance.

• fear of the blank page is usually caused by
• some kind of important doubt lurking below perception
• you might be afraid you’ll make a mistake
• how to figure out what’s lurking below perception?
• let your subconscious brain process the problem by doing something else away from the keyboard
• try externalizing the issue: rubber duck, doodle
• maybe even prototype around the problem space giving you disease; this context switch can help you work through it
• in other people’s code, notice what give you pause so that you can lean from the person who wrote it