
The Recovering Programmer (2010) - marttt
https://prog21.dadgum.com/56.html
======
hardwaregeek
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.

~~~
alextheparrot
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.

~~~
Tainnor
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.

~~~
MaxBarraclough
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.

------
solidasparagus
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.

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

------
donatj
> 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.

------
altitudinous
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.

~~~
vsareto
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?

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

[https://news.ycombinator.com/item?id=23528483](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](https://www.youtube.com/watch?v=o__2ks4XWho)

------
kosma
Please add [2010] to the title.

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

------
buildbot
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.

~~~
Cthulhu_
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.

