Senior Oops Engineer @ReinH doin capitalism a frighten pronoun.is/he Mar. 11, 2019 2 min read

Most code that seemed terrible was actually written under constraints and pressures I didn't understand.

Earlier in my career, I would say things like "this code doesn't seem very good", not realizing that I was putting down not just the person who wrote it (which is enough reason to not say it) but also the whole team, because coding is a team sport.

These days I try to say things like "I'm not sure why this code was written this way. Do you think we could try something else?"

And after repeatedly getting bitten rewriting code I didn't understand in a way that didn't work, I've realized that people generally have good reasons for doing things and that you often need to understand these reasons to actually understand the code.

The actual code you see is just an artifact of an entire contextual decision-making process, and assuming that people make good decisions isn't just the nice thing to do: it's also the best way to understand that code.

If I was forced to define what "good" code is, I would say that it's code that makes it easy to understand the context in which it was created and in which it functions today.

I think that this is actually what most people mean when they say "readable code. If you look at advice for writing it, the best is stuff that makes context more explicit and visible: intention revealing names, no global variables, single responsibility, DRY, &c.

Also, as an aside, assuming that people's actions are justified is a good way to reduce the severity of the blaming judgements we make. I think this why the Agile Prime Directive is so important.

EMPATHY 👏 MAKES 👏 YOU 👏 A 👏 BETTER 👏 PROGRAMMER

It's important to note that assuming good faith makes you very vulnerable to people who are acting in bad faith, which is why it is so important to remove toxic people from your team. And to prioritize your own safety.

Assuming good faith is definitely not appropriate in all situations for all people, but when you can build a team with the psychological safety necessary to enable it, it is very powerful.

Yes! My bad code is bad because reasons. Your bad code is bad because you are bad at code.

I know it's hard but try not to assume that one idea is better than another just because you had it.

Another important corollary: just because some code is doing the wrong thing today does not mean it was doing the wrong thing when it was written.

But back to @GeePawHill's original point, even if someone is actually objectively bad at writing code and you could somehow know this, there's still no excuse for being a jerk.

It is POSSIBLE that if it could be made simpler, it would have been.

But seriously: things tend to become more complex over time because they need to become more adaptive over time. Complexity is necessary for dealing with complexity.


You can follow @ReinH.



Bookmark

____
Tip: mention @threader_app on a Twitter thread with the keyword “compile” to get a link to it.

Enjoy Threader? Sign up.