Hacker News Reader

Comment by vinayms | Hacker News Reader

Oddly, I can relate to all the points (mentioned below) as a software engineer, except that I love what I do too much to even imagine giving up like the author seems to have. In fact, I had exactly the opposite experience. I hated computer science and programming in the beginning but ended up doing it for fun and profit.

> 1. I expect to not get the answer on the first try

> 2. I can tolerate ungodly amounts of frustration

> 3. I attack problems from multiple angles

> 4. I check my goddamn work

> 5. I practice persistence

I happen to be one of those engineers/persons who thrives working alone, values quality over quantity, and tries to be as self sufficient as possible, so I can really relate to the above points very much.

View on HN

Number 1 was the biggest for me, coming into programming from an entirely different profession. I never learned how to code until I was about 28. I didn't realize that I brought what I call the "consumer attitude" towards electronics into my programming practice in the beginning. The consumer attitude is that machines work. If they don't work, something went terribly wrong.

So when I made a mistake, I'd just crush myself with doubt and anxiety. It literally would hurt my brain and give me the sinking feeling that I'd never be able to do this because I can't code anything without screwing up somewhere.

But now, after about 6 years of doing it, I've developed an entirely different attitude. The correct attitude towards machines is that they do not work. They are broken by default. So if they work, something went terribly right.

Now, when I write a line of code, and it breaks, it's just business as usual.

I can feel what you mean. In college at times when my 101 code wouldn't compile I was convinced that Borland C++ had a bug.

For me its the point 2 that is most relatable. Every time I have to use a library, even C++ STL beyond the oft used portions, or learn a new framework or language, my heart sinks a little anticipating the impending path of thorns. I have had so many encounters where it is literally a pain in the neck from all the peering into the screen trying to see just what the heck is not working, or eye burn from staring into the monitor squinting at the debugger window with small fonts, or both of this along with sore and sweaty fingers out of frantic googling that I shudder just writing about it. I call this "wrestling with the API". Its an occupational hazard for us to deal with all the man made pieces of software that are as different as their creators, and I have made my peace with it.

It usually turns out that I missed a fine detail in the documentation. Sometimes its my fault where I wouldn't have read the docs properly or have made uncalled for assumptions, and other times its squarely the documentation's fault for being unhelpful. When its my fault, I feel really disappointed with myself for having been so careless despite being an experienced dev. That adds to the frustration. Almost every time, stackoverflow has bailed me out, and invariably it would be an old post. (At times when I find a solution to something seemingly insurmountable, I have even mused about donating some money to them.) I take solace in the fact that someone had faced similar problem long before me and I need not be so harsh on myself. That until it happens again.

Haha! I was in the process of spinning up my little blog, and I had a similar experience trying to get dns configured, had I merely checked my provider's knowledgebase instead of going through github's more generalized procedures I would have accomplished what I was trying to do within an hour instead of the 5 I spent scouring every bit of github's docs I could find. Urp.

well said!

I feel that's related to the mentality that if something was broken, and you do not know why it's working again, then it's not really fixed.

This can be difficult to inculcate in new programmers as they try to tweak their way past error messages.

In the past 7–8 years I’ve come around to the realisation that programming truly is a branch of mathematics, in a deep sense—and a strange one at that. It makes sense that they would share a lot of lessons.

In my experience, those who say programming isn’t mathematics are usually mistaken about what math actually is. Or at least I know I was. I used to think math was about calculation, because that’s most of what I was exposed to in school—virtually every problem, even in higher-level mathematics, was brought back around to work with concrete values, perhaps in an effort to tie the problems to something “real-world” and get kids interested in it. But it had the opposite effect on me—that’s like saying programming is about making a machine do calculations! Yes, in a literal sense, but there are much higher-level, more abstract and interesting things at work there.

To me, a computer’s value is that it’s an automated proving machine. You can make useful, entertaining, or interesting things happen in the real world—just by writing a proof that you can!

Reply on news.ycombinator.com