I Love This

Technologists like to make systems better. We look at a system, see how things work and we’re drawn to “problems”: errors, inefficiencies, potential for confusion, etc, etc.

On a team, though, when we find a better way, we should often steer clear of “This is better.” Instead, consider: “I love this.”

“Check this out, this will make x, y, and z easier and lets me not even worry about p, q and r. I’m loving it. What do you think?”

Even if you have objective reasons to point to for why a thing is better, it’s not as if subjectivity just goes away, bowing in the face of objectivity. We like to think this should happen. It doesn’t.

Show me a thing that you think is better than my thing and I’m likely to get defensive. Show me a thing you’re excited about and maybe I can get excited, too.

Try It On

You can carry an idea around in your head for a while without committing to it. You don’t have to believe in it. You don’t have to buy it. You can just try it on. See how it fits with your other ideas.

Don’t end up liking it? Then don’t buy it.

Notebooks, Notecards, Post-its

A notebook is a bunch of pieces of paper bound together in a (somewhat) fixed order.

Notecards are a bunch of pieces of paper in an order, but the order is easy to change. And it’s easy to throw one out. Or insert one. Sort ’em. Shuffle ’em.

Post-its are a bunch of pieces of paper you can stick to stuff. They’re easy to attach to a wall, window, monitor, or whatever. When you spread them across a surface, there can be a vertical order and a horizontal order. There can be a stacking order, too. A wall of post-its is great for expressing relationships, giving structure to a bunch of related ideas. It’s great for figuring out what you want that structure to be, too: You can move stuff around, step back, have a look, reconsider.

I take notebook to meetings, but maybe I should take a stack of notecards instead. The notebooks I buy are so nice, though.

Maybe I should take post-its? That seems a bit much.

Got It Working

When you say “I got x working”, I hear “I’m not thinking about whether x is designed well.”

When you “get it working” and then ship it without spending time getting it right, thinking it through, planning for change: You’re shipping prototype code. I could maybe imagine a context where that might be acceptable, but it’s usually not a good decision. At the very least, it should be a conscious decision.

Kent Beck’s old line is: “make it work, make it right, make it fast”. Effectiveness, design, performance. Shipping the prototype gives you only the first of those.


A narrative is a story you tell yourself, generally about the past and the future. You tell yourself lots of stories, actually. Stories about yourself, stories about the world. Sometimes these stories pull you hard in a direction when you’re making a decision.

Maybe your narrative is that you’re a pitcher. You wanted to pitch in the major leagues when you were a kid. Your heroes were people like Tom Seaver or Nolan Ryan or Pedro Martinez or whomever. You pitch for your high school team. You love it. And now two colleges want to give you scholarships: one wants you to pitch, the other wants you to focus on your hitting and move to first base.

Which one are you more likely to pick?

Your narrative sits there in your head and tells you the answer is obvious: You pick the one that lets the story — a story you cherish — continue.

I’m not here to tell you to embrace that narrative or any other one. Or to avoid narrative thinking like this. What I will say is this: You have some control over the stories you tell yourself. You can commit to one or you can throw it away. You can let it influence your decisions or you can focus on other factors. You get to choose.


We can think about some goals more clearly when we realize they’re more like directions than destinations.

Health is like this: I don’t reach a point where I’m done being healthy, or getting healthier. It’s an ongoing process in a complex and changing system. I might decide to start exercising three times a week. If I do that for six months, will I be healthy?

Maybe healthier. But never sufficiently healthy that I can simply stop thinking about my health. Never “done”.

Exercising three times a week for six months? That’s a destination. But it’s a destination in the service of the greater goal of heading in a direction. After those six months, I reevaluate: I’ve tried doing thing x to head in the general direction of better health. Now I ask myself some questions: Am I as healthy as I want to be now? Am I doing enough? Could I do less? Could I do more? What if I stop entirely? Should I try something different, like exercising differently, or eating better?

This is course correction with a moving target. It doesn’t have to happen every six months. It can happen much more frequently. And that’s good, because not only does my health change as time passes, but my opinion about what “healthy” looks like also changes. And that’s not a thing I can really control. So I might want to take a hard right turn tomorrow based on some new information.

Enough about health. This direction/destination idea isn’t exclusive to health. This is a useful and interesting pattern that also exists elsewhere.

Personally, there are other general things I work toward that fit this pattern: better relationships, better parenting, more productivity, better financial security, spending my time in more pleasurable and fulfilling ways.

Beyond personally, into the professional realm: High software quality is a direction and not a destination. A good team is, too — it’s something that changes over time, so it’ll never be done and can constantly be evaluated with an eye toward improvement along whatever vectors you decide. You might think of a meritocratic organization as something you continually strive for, too. Or a diverse organization. Even being a profitable organization is a moving target.

Beyond professionally, into the realm of government and society: Both liberty and social equality are fundamentally direction-based, not destinations that’ll ever be reached. (In the US, at least, we seem to be involved in a constant negotiation among groups with different ideas about which of those directions is more important (among other things). That negotiation itself looks like course correction with a moving target.)

We do our best, we learn, we try to get better. Don’t let your destination-goals lead you to lose sight of the direction-goals they’re meant to serve.


Two pieces of advice that each sound good but which also seem in conflict with each other:

  1. Focus on your strengths and delegate where you’re weak. This provides leverage: You get much more and better work done when you spend most of your time on what you’re good at doing. The stuff you’re not so good at can be done by someone else who’s better and faster at that stuff.

  2. Don’t lean too heavily on your strengths. If you do, you’ll become addicted to them and it’ll blind you to the benefits of strengthening yourself in other areas. When you throw out all your tools except for the hammer, the habit arises of looking at every problem like a nail. Think of the ace developer who wants to turn every problem into a technical problem: Sometimes, that problem could be solved more effectively and efficiently with a conversation.

So: Focus on your strengths for leverage. Don’t focus on your strengths, so you don’t stagnate. Can both of these things be true?

What if we rephrase? “Focus on your strengths for leverage; but not too much, so you don’t stagnate.”

So Simple

“Find a business so simple an idiot could run it, because in all likelihood one day an idiot will be running it.” – Warren Buffett

But, hey, we write software. So maybe an update:

“Design your systems to be so simple an idiot could maintain them, because in all likelihood one day an idiot will be maintaining them.” – Me

My interest in good software design comes from years of maintaining systems for which design was an afterthought. Just a little bit of thought toward maintainability can make life a lot easier for the next person who has to take care of a system. Not doing it is, frankly, rude.

And developers doing maintenance work tend to be less skilled than developers creating systems, so they need to be set up for success that much more.


“Leadership is a choice. This is apparently controversial, but more than any other element I can track, leadership occurs when someone decides it’s important that they lead.” – Seth Godin

Leadership is a means to an end, not an end in itself.

Why do you want to lead? Where are you hoping to go? Why do you want to take other people there?

There’s a question of identity versus outcomes here. Are you interested in being a leader, or in doing leadery things, like helping a team of people accomplish something?

If it’s about you being something, it’ll be an uphill battle. If it’s about helping people, you’ll cruise.