The Recovering Programmer (2010) | Hacker News Reader

The Recovering Programmer (2010)

prog21.dadgum.com

96 pointsmarttt26 comments

I've developed a theory that qualities such as empathy, subjectivity, even aesthetic need to be cultivated. You need to exercise them or they will abandon you. And being a programmer is not always conducive to these qualities. When you spend your time in the land of bits and bytes, 1's and 0's, it's too easy to see the world through the lens of objectivity.

But the world is not objective. As much as we try to claim objective knowledge, the world is too complex to be proven. We inevitably call upon models, we inevitable omit data, we inevitably read bias into our evidence. Instead by claiming our objectivity, we're sanctifying our subjective ideas. If I claim that Keynesian economics is objectively correct, I'm not giving an objective proof, I'm simply trying to sanctify Keynesian economics as an infallible truth.

And by making that claim, I'm neglecting the empathy to comprehend that other people very well have their experiences and their data that indicates Keynesian economics is false.

Your opening sentiment is what I believe to be the fundamental truth - but as much as I want to ask how you got there, I believe that would be cutting up the bird to find the song.

“Art should comfort the disturbed and disturb the comforted.” How can I work on comforting and disturbing the person in front of me in a way that elevates the both of us?

If one is engaged in appreciating, They probably aren’t judging? Sounds nice - maybe

"cutting up the bird to find the song"

That is such a good phrase, is it a quote from somewhere?

Seems like the original quote is from "Materialized Apparitions: If Not Beings from Another Life, What Are They" written in 1885 by Edward Augustus Brackett.

"Science may wrangle over the supposed movements of molecules and atoms, and the correlation of forces; may dissect the bird to find its song; but love alone shall set the boundaries of knowledge."

I believe in your theory. I wrote about it recently as it’s been a long-standing challenge for me to balance different creative/literary/social aspects of my self with those emphasized by programming all day.

http://www.pcmaffey.com/how-programming-shapes-the-mind

Great essay, thanks for sharing. In particular, the section you've entitled "The Bad" describes quite precisely that odd type of "brain fog" I sometimes get after spending hours at a computer with a mentally challenging task, even creative writing (especially when I'm stuck somewhere -- or decide to give up and call it a day).

I wish more engineers would look into mathematical constructions of systems. Take something like Gödel’s Incompleteness Theorem and apply it to your own thought process - it shows that it is fallible. The recognition that you can be wrong, and that you might not be able to see how you are wrong, to me provokes a careful, thoughtful scepticism of self.

We still need to face reality, so the sceptic can’t take over the asylum, but we shouldn’t act as if the patients monopolise faulty logic. Just the act of listening and trying to really understand what is being communicated, informationally but also emotionally, is also a view we get of ourselves from outside our local system.

Empathy is a lot like that. Understanding that others have had different circumstances, which led them to different thought processes, which we should try to understand and validate. There’s richness to be found in those differences as well. Deep understanding of another allows directness, vulnerability, and passion to shine phosphorescent.

Honestly, anyone whose precision of knowledge is limited only by Godel's incompleteness theorem deserves to be a little bit arrogant. But no such person exists. Looking back on one's life tends to reveal many errors, blunders, and utterly moronic misconceptions. Plenty of material to provoke humility there.

I should say that none of this means there's no such thing as objective reality. There (probably) is some kind of objective reality underlying all of this. But we don't have access to that. All we have access to are the incomplete, quirky, partially-wrong realities that live in each of our heads.

The point of bringing up Gödel was for analogy rather than as a theory of knowledge. I agree there are many germination points for humility, self-sceptism, and general reflection - we’ve together mentioned a few.

I'm not sure Gödel's incompleteness theorems have anything to do with this. After all, they don't show that any system of reasoning is inconsistent - just that it can't prove its own consistency and that there are statements that can be neither true nor false. Even then, it only applies when your system is able to express arithmetic - for basic syllogisms (like "all men are mortal. socrates is a man. therefore socrates is mortal.") this doesn't apply, as far as I understand.

Also, the field of formal methods exists, and is successfully used to develop ultra-low-defect software. The Incompleteness Theorem doesn't stop it dead.

What was being trying drawn was a parallel from “A numerical system can be hard to prove correct, in unexpected ways” to “A human system can be hard to prove correct, in unexpected ways”. Recognising this is part of accepting ones own limits. Gödel in no way proves this, as you note, and my wording should have made it more clear that I understand that. The essence of his result is easily analogised, though.

"What we cannot speak about we must pass over in silence." - Ludwig Wittgenstein

A logically robust statement would be "We can not say what is right, only what is least likely to be wrong".

As we can see, you won't impress most people with it, they prefer someone who exudes confidence. If he is right or wrong does not matter much it seems.

I like this idea about needing to cultivate empathy, subjectivity and aesthetic. Are you suggesting cultivating these qualities inside or outside of programming?

Great blog post. I think this has to do with the largest companies having the largest megaphones.

When Google writes about how they saved a few bytes by designing their own serialization format and serialization, it makes me, as an engineer who never really cared about those things, feel insecure in my technical decision making. When AWS writes about how they invested tons of effort into improving the performance of EC2 by a couple of percent, it makes me feel insecure that I'm not even measuring my software enough to know if performance has improved by 5%. When Uber mentions the software system they designed to catch a certain rare edge case, I feel insecure because I know I'm not considering all the possible edge cases.

And slowly building 'high-quality' software starts to feel like a Herculean task - there's so much that needs to be thought about! And as my list of tedious-shit-I-need-to-consider grows, I start to lose the joy of programming.

But over time I've realized that not caring about those things isn't a reflection of the quality of your engineering - it's a reflection of the scale you're working at. In a field where there is no limit to how complex we can make things and where there is never enough time to do everything we can dream of, building high-quality software is about knowing what problems aren't worth solving and which ones are. If you have 10 customers, it is poor engineering to spend time enumerating all the 1-in-100,000 edge cases. Write code that fails in the best way possible, that notifies you if this starts to become a common problem, and move on.

Places like HN don't help. There is always a world-class expert ready to give their opinion on how you should be doing things better. But it is important to remember that these people are experts in that area of software - not experts in whether that edge case really matters to your product or experts in how you should be allocating your time.

I used to feel like an imposter before I worked at a FAANG and I realized that they aren't better engineers, they just have more reason and time to focus on the small details.

A well articulated and helpful comment. Can I ask which FAANG you work(ed) at?

this is an immensely reassuring, and at the same time motivating comment

> I've consciously tried to rewind, to go back to when programming was a tool for implementing my visions, not its own end.

I recently rebuilt a website I built in high school circa 2001 in a modern framework to make it more maintainable. It was PHP 3 / MySQL 4 when I built it. It only ran as it was with a number of polyfills for long gone language features.

The original site was wacky, completely different layouts for different pages, some with characters that tracked your mouse. A ton of creativity. I redesigned in 2008 into a reasonably standard blog format. Looking back during this latest rebuild I feel like so much was lost in that redesign.

The point of having a website when I was in high school was not to write code, it was a place to pour my ideas. Somehow somewhere in the last 20 years the means to an end became the end, and I am not sure how I feel about it.

I’m certainly not the well of creativity I once was, but at the same time the things I do produce are of much higher quality. Is that just the innate balance of life? I really can’t say. Getting older is strange.

This - Hacker News is one of the worst: Arrogant trash highly technical programmers :

"And I realized that the inherent bitterness and negativity of programming arguments and technical defensiveness on the web were making me bitter and negative. "

And indeed this :

"I've consciously tried to rewind, to go back to when programming was a tool for implementing my visions."

At over 50, implementing from a user perspective rather than from boorish technical perspective gives me a fantastic advantage over just technical programmers.

I've disovered the same as this guy.

Maybe the technical programmers just aren't in a place where their talents are valued and used effectively? Maybe you found a great place that's a good fit before they did?

Emphasising stack over stuff[1] is the programmer's equivalent of emphasising style[2] over story:

https://news.ycombinator.com/item?id=23528483

[1] I'm legacy enough to claim one should first design state, then decide on stack: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious."

[2] Bonus clip: https://www.youtube.com/watch?v=o__2ks4XWho

Please add [2010] to the title.

OP here. I somehow forgot this, thanks for pointing out.

There is some simple joy in being able to let it go and just quickly script something to get something done without any more pretense than just that.

I'm working on a biggish Go application (a rebuild of a poorly written 160K LOC app) and I've been trying to make it "perfect" because it has to work for the next decade, and (in theory) I'm laying the groundwork for a slowly growing team of developers and my successors.

But in practice I'm stuck on the one side in analysis paralysis, and on the other I feel like what is pushed as best practices is slowing me down and adding a lot of boring, fragile boilerplate (use case: adding a field means changing structs and conversion functions in 3-4 packages).

I'm seriously thinking of just flattening everything again and work from my database representation, because right now I'm not moving very fast and adding / changing fields feels daunting. And it shouldn't, because that should be the easiest part, and it's something I've done for so long already.

Reply on news.ycombinator.com