Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Recovering Programmer (2010)

prog21.dadgum.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: The Recovering Programmer (2010)

#11

Post by 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.

Re: The Recovering Programmer (2010)

#12

Post by Cthulhu_ »

buildbot wrote: post #3

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.

Re: The Recovering Programmer (2010)

#13

Post by Tainnor »

alextheparrot wrote: post #7
hardwaregeek wrote: post #2

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 o…

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…

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.

Re: The Recovering Programmer (2010)

#14

Post by c1ccccc1 »

alextheparrot wrote: post #7
hardwaregeek wrote: post #2

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 o…

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…

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.

Re: The Recovering Programmer (2010)

#15

Post by 082349872349872 »

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

Re: The Recovering Programmer (2010)

#16

Post by scns »

hardwaregeek wrote: post #2

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 o…

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.

Re: The Recovering Programmer (2010)

#17

Post by 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.

Re: The Recovering Programmer (2010)

#18

Post by MaxBarraclough »

Tainnor wrote: post #13
alextheparrot wrote: post #7

Earlier quoted context omitted.

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…

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 socrat…

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.

Re: The Recovering Programmer (2010)

#19

Post by vsareto »

altitudinous wrote: post #11

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 perspectiv…

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?

Re: The Recovering Programmer (2010)

#20

Post by yowlingcat »

Tainnor wrote: post #13
alextheparrot wrote: post #7

Earlier quoted context omitted.

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…

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 socrat…

"What we cannot speak about we must pass over in silence." - Ludwig Wittgenstein
Post reply on HN