If something in your software is confusing to a customer, it is confusing.

I’ve been a practitioner of Shawn Wang’s ‘Learn in Public’ for years. In this post, I’ll share a list of ways I’ve found to learn in public.

When I was learning to program, I was fortunate to pair with very experienced engineers. One day while coding, I said: “I think we need to use Ruby’s map method, but I’m not sure how that works. Let me look it up.”

Later, my pair offered some feedback: “You can’t be looking up map. You need to know how all of Ruby’s Enumerable methods work.”

How do you introduce new ways of working? We want to bring a new idea to our engineering teams, such as a new command-line configuration, testing tool, or design pattern. But engineers can be discerning and stubborn customers. The idea needs to stand on its own. And, you have to sell it.

Ben Kuhn’s ‘Think Real Hard’ shares a problem-solving checklist from the scientist Richard Feynman:

• Write down the problem.
• Think real hard.
• Write down the solution.

On its face, this advice is ridiculous. If only we just sat and thought about the problem, we’d win a Nobel Price like Dr. Feynman!

I used to have a bad habit when working alone: I’d start a feature, begin doubting my approach, throw away my work, and start over from scratch. Sometimes more than once. The result? Wasted energy, abandoned code, confusion about what I had and hadn’t implemented, and repetitive rework. This post is a collection of thoughts on this practice.

Programming is a new and abstract field, and so we place great emphasis on ideas. When I find one that sticks with me, I end up sharing it again and again. These are some of my favorites.

When a stakeholder asks for a change to the software I’m building, my typical responses are, in order: “Got it.” Then: “I’m working on that issue.” Finally: “It’s done.” Here’s an alternative: skip the first two conversations and go straight to the third. As soon as you can, just do the thing, and respond with: “It’s done.”