The humanity in each line of code

Our hunt to algorithmize (is that a word?) all the wrong things has ruined software engineering as it exists today. A few years back I used to look at code I wrote as replaceable, and saw it as a commodity (from what I read and understood from practitioners around me), I no longer see it that way. I think the human aspect of software engineering will be more crucial than ever now (if it wasn’t already).

Emotion Is Not a Weakness

You might think, Bhupesh, this sounds naive, maybe I am, but I am also not afraid to be reasonable. The industry is pushing developers to be rational, do the work, don’t get attached, behave like a robot with no attachment to your goddamn work, and I am here to say, y’all are too weak. Too weak to say that you care about your work, too afraid to say that you have emotions. I will explain in language some of you nerds will understand. Imagine someone spent years contributing to a widely used open-source project as one of the maintainers. Now something happened, something human, a disagreement between authors and maintainers.

What do you suppose happens?

• The author kicks the maintainer with whom the said disagreement happened.
• The maintainer loses some privileges.
• The maintainer leaves with a fork off to a new project.

Even in well-run projects, the human stuff creeps in — ego, disagreement, fallout. Human emotions are combined with the effort you put in every day when you open VS Code.

And I am not even making this up, folks active in the ecosystem might have noticed how licensing or issues related to perspective & ideologies have popped the need to create forks. Did this happen because folks who put in the effort (in terms of code) were not attached to the work they did? Would you still say that every line of code you write has no significance?

A couple of weeks back I was watching Pantheon on Netflix (great sci-fi btw), anyway, there was this recurring theme about how “emotions” play a key role in motivating humans to solve problems on the show (the underlying emotion being love in the show), which is weird since in hindsight, we have been told to keep emotions out of the equation when making decisions, so what gives?

This brings us to the Affect as Information hypothesis, which states:

Emotions are not just byproducts of cognition — they are a source of information. The way we feel informs how we interpret situations, evaluate outcomes, and make decisions.

In other words, your emotional state is data. It’s like an ambient signal your brain uses to decide: “Is this situation safe?”, “Am I motivated to fix this?”, or even “Do I give a damn enough to refactor this ugly module?”

This flips the traditional programming mindset on its head. If you believe emotion clouds judgment, you’re taught to suppress it — but if you believe emotion conveys contextual intelligence, then your attachment to your code is not a weakness. You care, therefore you notice. You feel frustrated, therefore you improve. You get excited, therefore you create.

And guess what? This same effective signal is why burnout exists, and why people argue over tabs vs spaces, yaml or no yaml. It’s not just about logic & runtime performance — it’s about care, identity, and meaning.

If you fancy TED talks, there is this good lecture by Jaak Panksepp, The science of emotions: Jaak Panksepp at TEDxRainier that relates to some of the points I made.

The Happy Accident

I think the most accurate way to describe what I do every day is converse, each line of code is a way to communicate, communicate with the machine, communicate with the people who will read it, and communicate with the people who will maintain it.

Imagine if you & I were talking about whether using panic in Go is a good or bad idea, we were naturally conversing using a common language like English, coming up with situations, edge cases, etc. Now, no third party will come to us & offer us money to keep talking.

Now imagine, if instead of just talking, both of us applied some of our knowledge and discussion points to build a tool that helps Go programmers detect all potential areas where your code can panic at build time & it worked (hypothetical scenario, don’t come at me with whether it’s feasible/possible or not), there’s someone out there who will be willing to pay for that, this is the “happy accident”, your way to communicate to the world in the form of code can be capitalized.

Where do we go from here?

When it’s all said, and done, I hope that the people who love their craft remain in the industry, despite how “commercialized” & “process-oriented” software engineering is, there are always people who enjoy doing what they do (wherever they work, whatever they earn).

It’s hard to predict what the next 10 years look like, and I sure as shot will not take anyone’s word for it (despite whatever moat they have), in the end, what matters is how much you care — not how fast you do the job.

Sometimes both these sentiments align. Sometimes they don’t. And that’s just life. If AI doesn’t take your job, someone who gives more fucks about what they do, most definitely will.