The test of a first rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function. – F. Scott Fitzgerald

One of the major differentiating factors between a junior team member and a more seasoned team member is the ability to “assume positive intent”. This obviously has its implications in interpersonal relationships and conflict management within teams (which I’ll save for another post), but it also has direct implications in software development.

Throughout the entirety of my career, I’ve dealt with software engineers, and fascinatingly, prejudgement is fairly baked into engineering culture. Have you ever introduced an engineer into a legacy code base? The first reaction is almost always: “This is crap!” Or, put more cynically and verbosely: “This implementation doesn’t follow my own personal instincts for how I would have solved the problem!” And then, fueled by enough beers or a close enough circle of confidants, you may even hear “Whoever wrote that was an idiot.” In fact, there’s even a handy command that programmers use for figuring out who wrote or changed a line of code. No, it’s not something like `git history`, which would nicely imply an answer to the question “how has this code evolved over time?” Instead, it’s `git blame`. As engineers, we’re trained to assign blame to someone who did something, not dig into the original intent.

(And, by the way, this isn’t unique to software engineers. I’ve seen people react the exact same way after ripping drywall out of a house: “Whoever did this electrical work was an idiot!”)

The solution to this is actually fairly simple: we need context. Assuming that the original programmer wasn’t on the nefarious mission to destroy the productivity of any future inheritor of this code, there are almost certainly a set of conditions that facilitated a piece of software being written in a certain way. Perhaps deadlines caused for a rushed implementation; perhaps an outage warranted a strip of duct tape that never quite got cleaned up; perhaps the office coffee machine wasn’t functioning that week; perhaps that piece of code has existed since the CEO wrote it in a 36-hour Redbull-powered coding binge back in his college dorm room.

The engineers I have most enjoyed working with are able to work under these assumptions. As they see more and more historical code throughout their careers, they start to recognize these common afflictions within legacy code, and they bring their other team members along through that journey of understanding and empathy.