Author: josh

When many people are accountable for something, nobody is accountable for it. When we all say “somebody else will deal with it,” often the result is that nobody deals with it.

This is an actual, scientifically-observed psychological phenomenon. It’s called the Bystander Effect. Also observed: The larger the group of bystanders, the less likely anyone is to intervene.

We need to fight this. And the way to start is by going first, by taking on responsibility and accountability. By not being bystanders but being participants, helpers, doers.

If you’re walking by and you see the coffee pot is empty, make a fresh pot.

If the team needs a volunteer and nobody’s speaking up, speak up, volunteer.

If you see someone struggling with their code, offer to pair or to be a rubber duck.

They don’t teach the A students how to work with the B and C students. In my experience, at least, all the A students were kept together in “honors” classes. We were led through harder material faster, while the B and C students did their own thing. There’s some value in that, but it also creates problems down the road. In real life, I’ve never worked on a whole team of A students.

Sometimes maybe you’ll be the smartest person in the room. And maybe you’ll assume everyone that will recognize that, and that they’ll listen to your sage advice. They won’t. If you’re really so smart, listen: You need to understand how to work with them and how to help them. If you can’t do that, you’ll resent them. And you will move on to the next “them” and quite probably resent them too.

We want to believe in meritocracy. We want to believe in fairness. We want to believe that rewards follow from skill and effort.

It’s one of those ideas that sounds great in theory, one of those things where moving in its general direction is often a good thing, but which you shouldn’t hope to achieve. You’ll never get a hundred on the test.

When I think of meritocracy in practice, I mean an organizational structure in which power goes to those with merit. That is, those who earn power, those who prove they’ll use the power best. By “power”, I mean authority. The ability to make decisions for the organization.

One problem with this is that merit is subjective. We might agree on a definition of merit in order to construct a meritocracy and assign power to those who’ll use it well. But we can’t predict the future. So we don’t know who’ll use power best.

Another problem is that everybody’s looking out for number one, so we don’t actually want to give power to anyone else. Our personal incentives may not align with the incentives of the organization.

Another problem is that time goes by. Even if we can agree on a definition of merit, those with merit today may not have merit tomorrow. But if we give them power today, it’s not so easy to take it from them tomorrow.

Look for the code that everybody avoids, the code they’re afraid to touch or that they don’t want to deal with. Watch for the code that you avoid. Maybe you can make that code less fear-inducing, or less difficult to deal with.

You’re probably afraid to touch it because it’s been painful before. Maybe it’s hard to get your head around. Maybe every time you need to touch it you have to spend a while just figuring out what the heck it’s doing. Maybe it’s hard to change. Maybe every time you change it, other stuff breaks unexpectedly.

Those are smells! Those are signs this code could probably use some design attention. Good design means maintainable code. When you have to touch it, it should be easy to understand what’s going on. Responsibilities should be isolated so changes will be isolated. That means less breakage of unexpected stuff. Tests can help with that, too. Blah blah. There are whole books on good design. The point is: Bad design shows its face in the form of code that’s painful to maintain. So when you feel that pain, you need to fix the design.

Sometimes you need to make substantial changes in order to do that, and of course changing stuff might break other stuff. Especially in code like this. That’s okay! Sometimes we should accept some short-term pain in the name of longer-term stability.

And sometimes the effort won’t be worth it. Don’t pour a ton of effort into fixing up code if the pain isn’t there. Bad code you have to fight with regularly begs for some love. Bad code that gets the job done can be left alone. If you only feel pain from it once a year, maybe you have higher priorities.

There’s a balance to be struck: balancing magnitude of pain, frequency of pain, magnitude of effort required to make things better, and just how much better they’ll be after going through that effort.

Have you seen/heard the way pro-vaccine people tend to talk about anti-vaccine people? They call them fools at best, evil at worst.

What about the way anti-Brexit people talked about pro-Brexit people? Same sort of thing: Fools at best, evil fascist racists at worst.

See also: the way anti-Trump people talk about pro-Trump people.

This is awful. It’s not how you should talk to or about people. It’s rude and it’s exclusive and it’s antithetical to progress and productivity. Being right doesn’t give you carte blanche. It doesn’t make it okay to treat people like shit. It feels good to know better. But when you let it become a reason to look down on people, you become an asshole.

I’d rather hang out with a simple-minded mensch than a brilliant asshole. And I’m far from alone.

Also: You only think you know better. There are countless examples of scientists who were ridiculed for their work by their colleagues and by the population at large and later turned out to be right.

Yes, we have a lot of confidence in a lot of stuff. But we can be wrong. We should at least not be dicks to people who question things. If anything, people who question things should be admired. It takes courage.

Maybe this is why I like children so much: They rarely think they know better.

Maybe this is why I like beginner’s mind so much: It tells us to stop thinking we know better. That not only opens us to discovery, but it invites us to not act like assholes to each other in the name of what’s “correct”.

A manager may have scarcely more control over real decisions than an individual contributor does. And they often have the added stress of having to communicate plans they don’t necessarily believe in to folks who will be displeased by them.

The potential level of bullshit that a middle manager may have to deal with is an order of magnitude higher than that of an IC. Is the difference in compensation enough to make up for it? Maybe not, in a software engineering context. Engineers make a darn fine living just fiddling with the bits.

Some mid-level management jobs are great, for sure. But I suspect the worst management jobs are way worse than the worst development gigs.

Management where you can make a difference, where you have some leverage to have more of an impact than you could as an individual contributor… That’s a worthy engagement. Management where you’re not much more than a conduit for information, a deliverer of bad news, a place for blame to fall when things don’t work as expected… That’s not worth your time.

Code review can be tough.

If it’s your code being reviewed, it’s hard not to get defensive. It’s hard not to take criticism personally. (If it’s not hard for you, good for you!)

If you’re reviewing the code, it’s hard not to be overly critical, to pick nits. It’s hard to frame your feedback constructively and/or inquisitively, not turning it into an indictment or devolving into pedantry. It’s hard to choose the right battles. It’s hard to give the code and the person who wrote it just the right amount and kind of direction and feedback. (If it’s not hard for you, good for you!)

It’s hard. So what happens sometimes is we put it off. And then we throw our code over the wall for review when there’s so much of it that it almost certainly won’t be reviewed well.

Short cycle time is better, for this and so many things. Conflicts come up faster, so they’re smaller when you surface them, and they’re easier to deal with. And with code review, you can bring the cycle time to zero: You can pair.

Pairing probably sounds like crazy talk to a good nine out of ten people when they first hear of it: Double the human-hours it takes to perform a task? Doesn’t that double the cost of building your software? No. Oh, god, no. That is crazy talk. Pairing does put two people in front of the first pass at a task instead of one, but it more than makes up for the extra person-hours by making that first pass way, way better. Better in terms of catching bugs and edge cases, designing code and components, and spreading knowledge across the development team. All those things are reasons you won’t have to go back and make changes later. (Changes that can introduce bugs, requiring even more work.)

When it comes to code review: Pairing also gives you essentially real-time review without it feeling like one person is grading or criticizing the other. Bringing the code review cycle time to zero changes it from review to collaboration, and that takes a lot of pressure off of everyone involved.

I’ve been better about not reading so much lately. (No, seriously.) I’ve been reviewing old stuff I’ve read and thinking more deeply about it.

Today I’ve been thinking all day about a good question from The Four-Hour Workweek:

“What would you do, day to day, if you had $100 million in the bank?”

The point isn’t to ponder what you’d spend your money on if you had lots of money. The point is to consider what you’d do with your time if money wasn’t scarce. (Sub-point: Your time is always a scarce resource.)

It’s not the first time I’ve asked myself this question, but this time I asked it at the beginning of a 30-minute walk, so I had some time and the right context to think about it for a while instead of finding something shiny to distract myself, as I must have done the previous times.

I didn’t have a good answer, and that made me very sad.

It’s easy to tell you what I’d do with a lot of money. I’d pay off the mortgage. I’d fix the house up or buy a new and better one. Settle all our debts and establish a comfortable, leisurely lifestyle.

More leisure: I’d spend lots of time with my family. We’d travel a ton. We’d eat out a lot, wherever seemed fun and/or interesting. We love that. I’d spend a bunch of my time reading, seeing shows, going to the movies, watching TV, playing video games.

But then what? Would I get bored with all that? Eventually? Quickly, even? It sounds exciting from this side of it, but I suspect that it wouldn’t be fulfilling. I can even imagine that I’d start to get depressed, having everything I could want but ending up bumming around all the time, consuming. (Double depressing: Getting everything you thought you wanted, seeing that it doesn’t make you happy long-term, and trying to live and grapple with that fact. At least you’d be able to afford a good therapist.)

I considered whether I’d start a software company. Do the job I do now in some form, but own the place. We’d do things my way, and I’d either show the world a thing or two or end up bailing myself out when it turned out I was full of it.

Nah. Probably not.

I considered whether I’d start to dig into investing. How to save and grow $100 million is an interesting problem. It might be the kind of problem I could geek out about once I start to research it.

Meh. Not generating much enthusiasm.

I considered whether I’d write fiction. That’s something I’ve always thought about trying. But my behavior to date suggests it’s something I’d like to have done but maybe not something I’d like to do. (Although part of writing here on this blog is to help me find out how much I actually like writing, and I’m learning that I do like it. At least non-fiction, so far. And autobiography, apparently.)

Would I do more speaking? No, probably not. I like it, but I mostly think of it as a means to an end, a way to strengthen and diversify my skill set as a software professional.

Wait: Am I a software professional just for the money?

No, I don’t think so. I love programming. That’s a big factor. And I’m sure it shows that I enjoy a number of other factors related to the software business.

But without the money being a factor, would I do something else? Yeah, I very well might. Shit. And I don’t know what that something else would be.

So: This line of thinking was terribly upsetting.

…

Well, I didn’t know. It was terribly upsetting. But after some more reflection, a happier thought: When you take away money as a factor, there is still stuff I care about. My family and my friends, foremost. And thinking about them made me realize what else there is: They live in this world, and this world is fucked in a variety of ways. Cultural, governmental, environmental, economic, et cetera. Large ways and small ways. Give me all the money in the world and I’ll still care about that stuff.

So what? Am I going to save the world now? Run for city council or go work for a green startup or something? No. Maybe. I don’t know. Get off my back. I still have a mortgage to pay.

Food is not just for staying alive. It is for that. But it can give us more.

For you, food could be for fueling a workout or a race, or growing your muscles. Looking good. Feeling good. Cooking or gardening or dining might be a hobby or a way you bond with family or friends.

The same sorts of things are true for what you feed your brain and your business and your relationships: There’s the stuff, the deeper stuff, and the meta-stuff. You can eat to stay alive or you can look for ways to thrive.

“You go to war with the army you have, not the army you might want or wish to have at a later time.” – Donald Rumsfeld

Maybe you can see ten steps down the road to how your project could be perfect. Maybe you know just what needs to happen. (You’re wrong. But let’s pretend.) You still need to move a team in that direction. And not just any team, but the team you’re working with right now.

Even if the powers that be have a moment of clarity (They won’t.) and decide to put you in charge of the project, giving you complete authority and control, you’ll still need to move a team in a direction. You can’t do all the work yourself. (And you shouldn’t want to.)