Author: josh

An unfortunate, unexpected, unlikely situation comes about. You deal with it. Then, while cleaning up the mess, you decide to put a process in place to prevent it from happening again.

But! Don’t forget to weigh the costs of that new process versus the cost of doing nothing.

There’s a thing that goes on in your brain called intervention bias. When something bad happens, intervention bias makes you feel like you need to do something about it. Sometimes the intervention ends up being helpful. But sometimes it actually makes things worse, in the grand scheme.

This is how bureaucracy grows, too: We add processes and procedures, little by little, in the name of averting risks that are less costly than the processes meant to prevent them.

Sometimes the remedy is worse than the malady. At least ask yourself: “What if I do nothing?”

If you buy a used car with the clear expectation that it runs, and then you find out a month later that it’s a piece of crap, that it needs a ton of repairs, you’re probably going to be pretty upset. This is a common enough thing that there’s a name for it: We call it selling someone a lemon. The car is the lemon. (It’s a common enough thing, in fact, that there are even laws against it in many states, called “lemon laws”.)

Some very common advice for avoiding a lemon: Have the car you’re buying inspected by an independent mechanic. Like programmers, auto mechanics are technicians, and they’re good at finding technical problems. Sign-off from good independent mechanic will give you a good deal of confidence in the soundness of your new used vehicle.

It’s interesting to me that I haven’t seen more of this independent review sort of thing done when it comes to custom software. Businesses often hire people to write custom software without having a strong ability to determine the quality of the software that they’re paying for. They can tell whether it works to the specifications, but those specifications are rarely as rigorous as they probably should be. Those specifications also frequently change over time, and the ability to make reasonable changes without great cost is a huge component of software quality. How can they tell whether their custom software can be changed reasonably easily? Basically: How can they tell whether they’re buying a lemon?

It seems to me that a review from a reputable third party would offer a fair amount of confidence, and wouldn’t be particularly expensive. Many experienced developers I know wouldn’t need a lot of time to look at your project and give a reasonable assessment of its quality. Like auto mechanics, programmers are technicians, and we’re good at finding technical problems. We probably wouldn’t turn up every possible specific problem in short order, but we could tell you pretty quickly whether you might be buying a lemon.

A big nerd-brain habit I have: correcting you on inconsequential stuff. Language is a popular domain for this: grammar, spelling, syntax, semantics. But also facts. The nerd-brain loves trivial facts.

If you absolutely must correct someone about something not that relevant to the conversation at hand, just… try waiting. Do it later. Holding your tongue in the moment can keep ideas and conversation flowing, keep the good will going. Picking nits annoys and distracts.

Can you sleep on it? Try it. Half the time you’ll find it’s not that important to you to set people straight after all.

Morning me has my best energy. It’s his to use or lose. He needs to keep his eye on the ball, so my best energy gets used on something worthwhile. He needs to not get sucked into email or social media or someone-is-wrong-on-the-internet. That’s not what I want to spend my best energy on.

Evening me generally has the dregs of my energy tank for the day, so he can dick around. He can file and organize stuff, or goof off on Twitter, or play games. What he should not do is mess with morning me. Which means he should make sure we don’t stay up too late. Morning me is best well rested.

Here’s another thing evening me can do: Decide what morning me should work on tomorrow. There’s a good chance evening me is bummed about something that didn’t get done today. That might be a good candidate.

“If this sounds totally obvious, well, good for you because it wasn’t obvious to me.” – Kent Beck

Just pretend I add that line to the end of every post from now on.

The “obvious” is deceptive.

There’s plenty of great advice out there that seems obvious when it’s in front of you, but which you can never manage to bring to mind and act on when it would be useful.

There’s plenty of stuff you’ve known for ages and have built many layers of knowledge on top of, which you rarely bring back to the surface for a look with fresh eyes.

There’s plenty of stuff you know in your gut that you’ve never bothered loading into your brain to have a closer look at.

And there’s plenty of stuff you know that you assume everybody else knows, too, and thus isn’t worth talking or thinking much about.

In all of these cases, looking past the “obvious” can cause us to miss out on opportunities — to improve our knowledge, our wisdom, our habits, and to help others do the same.

Critical thinking and creative thinking are often at odds. That is, when we try to come up with ideas to solve a problem, our nerd-brains like to butt in on our creative-brains to say “no no, that won’t work and here’s why”.

Instead, keep the nerd-brain and the creative-brain separated when you need to come up with ideas. Brainstorm first, evaluate later. Make a list of crazy ideas with your creative-brain, then come back to it later with your nerd-brain to sort out what’s good.

To put it another way, a famous quote comes to mind: “Write drunk, edit sober.”

Repeat back.

It’s called the Fast Food Rule because it’s what they do at the drive-thru window: They repeat your order back to you to make sure they heard it right.

It’s a vital rule for every single knowledge worker (and, I might argue, every single person in modern times). We all do a crap-ton of communicating all day long. We do jaw-droppingly little verification that the messages we send are the messages that were received. And so much gets lost in translation.

If you’re worried you’ll sound stupid or that you’ll waste people’s time by clarifying and verifying, think about it this way: You might end up seeming much stupider or wasting much more of their time when what you heard doesn’t match what they said. Maybe you’ll go off and build them the wrong thing, or buy the wrong thing, or deliver the wrong message, or so on, or so on.

Just like fast food, it’s cheap. Repeat back.

Here’s something I used to hear about Derek Jeter: His defense wasn’t actually that great. Sure, he made lots of flashy plays on the balls he could get to, but his range — the amount of ground he could cover — wasn’t very good. There were actually fewer balls he could get to. Someone with better range would make all those plays, too, but you wouldn’t even notice them. They would look so easy as to be trivial. Meanwhile, Jeter, with his crappy range, had plenty of opportunities for plays that looked impressive, while producing effectively poorer results than average.

I’m not a baseball expert, so that could be an incorrect assessment of Mr. Jeter. But the general case rings true to me: Struggling with a problem and succeeding draws more attention than just taking care of the problem quickly and quietly. Same with causing the problem and then fixing it. Oof.

“We often reward people for solving the very problems they should have avoided in the first place.” – Shane Parrish

This is worth keeping in mind if you run a a team or a project or an organization: The work you notice isn’t necessarily the most valuable work being done. The folks whose good work you notice aren’t necessarily the ones doing the most valuable work.

In fact, pretty often, the folks you notice are the ones who care more about looking good than making sound decisions. They’ll deliver something quickly by taking shortcuts, and then draw even more positive attention by fixing the problems caused by those shortcuts.

Notes on what to look for when considering contract development work:

1. Compensation
   • Rate
   • Duration/size of contract
   • Potential for extension/additional work
2. Learning
   • Will you learn new technical skills?
   • Will you learn other useful things (domain, process, architecture, management, people skills)?
3. Experience
   • Will you enjoy the work itself?
   • Will you like working with the people involved?
   • Will you enjoy the work environment?
4. Marketability
   • Project visibility (“I worked on iOS” is better than “I worked on some internal systems for Big Company X.” It’s more meaningful to the next person hiring you. And the next and the next.)
   • Technical skills (Gaining six months of experience in Node, for example.)
   • Network (Will you make valuable new relationships?)
5. Potential For Surprises
   • Does the client know the real-world problems they’re trying to solve and are their efforts actually aligned with solving those problems?
   • Do they have a clear idea of what success looks like?
   • Will you be hand-holding on process and requirements definition?

Tell me what I’m missing on Twitter.

My nerd-brain is always looking for the case against whatever you’re saying. Or whatever I’m saying. It’s nothing personal. It’s not you, it’s me. I consider it a weakness on my part, much of the time.

It’s not a weakness when I’m solving technical problems. Then it’s part of what you pay me for. We want our software to be correct, to work as expected, reliably. That vigilance, compulsively looking for points of failure or better ways to solve the problem, is very useful.

The nerd-brain turns into a weakness when I deal with people. People don’t take kindly to the nerd-brain’s brand of criticism. If you and I worked together and I watched you like a hawk for what you were doing wrong and pointed out every little thing, you probably wouldn’t want to work with me for very long.

At my best, I can turn the nerd-brain off when dealing with people, then flip it back on when I context-switch into some technical work. This isn’t always easy, though. I slip, a lot. Over time, my behavior ends up looking like I have a decent filter on the nerd-brain when dealing with people, but not a foolproof one. But, looking back over time, it also looks like the filter is improving.