Live data from Hacker News

Things I’ve learned in my 20 years as a software engineer

simplethread.com

731–740 of 745 posts

Re: Things I’ve learned in my 20 years as a software engineer

#731

Earlier quoted context omitted.

Bellard is obviously 10x (or 100x) engineer when you need to port Linux kernel to JavaScript or compute the longest Pi sequence. But most jobs aren't like that and require a mixed skillset - problem solving, people skills, stress resistance etc. and it's entirely unclear how Bellard would fare there.

But the question isn't about those skills, the question is about programming. Bellard is blatantly an insanely productive programmer. Also if you think a man who can build an LTE base station from scratch isn't good at "problem solving" I really don't know what metric we're talking about anymore.

No, this is about being 10x engineer and part of the job description is much more than programming.

Re: Things I’ve learned in my 20 years as a software engineer

#732

Earlier quoted context omitted.

That is a interesting thought, that seems to imply that those young programmers will not improve. If you are a master at 25, what do you call yourself after you have gained twenty more years of experience? It may be that those 25 year old's a more like journeymen then masters, or that programming is more like sports where youthful vigor are more important than experience.

John Carmack programmed Wolfenstein at 21 and doom when he was 22. At that point he did what most "masters of that craft" couldn't do. What would you call him? And what would you call him now, 30 years later?

> And what would you call him now, 30 years later?

Something else than thirty years ago, because presumably he has developed since then.

I think that was why GP suggested "journeyman" for younger people, because otherwise there's nothing to differentiate young "masters" from masters honed by thirty years of additional experience -- except adding the whole phrase "with thirty years of experience", which is pretty clumsy.

Re: Things I’ve learned in my 20 years as a software engineer

#733

"Interviews are almost worthless for telling how good of a team member someone will be" Just like "avoid the 0.1x programmers", interviews are for weeding out the really bad team mates. They aren't for finding the best ones. For instance, I and a female programmer do the interviews. During one interview, my coworker kept asking questions of the candidate, and he would not look at her when he talked. He would actually…

> During one interview, my coworker kept asking questions of the candidate, and he would not look at her when he talked.

Or maybe he just thought she looked hot, and was afraid of appearing to be ogling her too much. Sometimes people fuck up by trying too hard not to fuck up.

Re: Things I’ve learned in my 20 years as a software engineer

#734

> “if they ask about time off in the first interview then they are never going to be there!” The fact that this attitude is common scares me when I'm doing interviews. Time off is incredibly important to me. What's the use of making a great income if you can't get the time off to enjoy it? The culture about the use of PTO varies wildly between companies. A friend of mine worked somewhere that supposedly gave 20 days…

Thank God I was born in a poor socialist country and I don't have to think about obvious stuff like my days off

Edit: sorry if that sounded offending but I can't wrap my head around the fact that people in US have problems of this kind

Re: Things I’ve learned in my 20 years as a software engineer

#736
post #713

Earlier quoted context omitted.

No offense, and I mean this, but from what you've said I wonder if you suffer from Nice Guy Syndrome. It is often referred to in the context of dating, but applies to work as well. There is a book called "No More Mr Nice Guy" that you might find interesting.

One person tells me my problem is that I might be an asshole and you tell me my problem might be that I'm too nice... Why is it so far fetched to suggest that maybe the problem is not me? What if the problem is that most people in power have impostor syndrome and they feel jealous and/or guilty when they see a competent person who didn't achieve as much as they did. It makes them doubt their own success narrative. Pe…

> One person tells me my problem is that I might be an asshole and you tell me my problem might be that I'm too nice...

No, what the GP actually said was

>> I wonder if you suffer from Nice Guy Syndrome.

That's not the same thing. Because sufferers from Nice Guy Syndrome only actually think they're being "nice", but they're being so in ways or from motives that actually make them, in practice, assholes. (Sorry if that's a distortion or oversimplification of the book GP suggested; I recently skimmed through it, but didn't actually get to read the whole thing.)

> Why is it so far fetched to suggest that maybe the problem is not me?

Because usually, when one person has trouble with everyone else, and goes "What's wrong with all of them?!?", Ockham's Razor suggests the simpler hypothesis, "Maybe there's something wrong with you?", lies nearer to hand.

All in all, I'd suggest you try to get that book and read it more thoroughly than I did. (And so should I.)

Re: Things I’ve learned in my 20 years as a software engineer

#737
post #75

Earlier quoted context omitted.

Yes the point would better rather be made as "continually question your assumptions" especially when troubleshooting (hence the value of having a rubber duck).

The original point is invalid, although one could say that being good at systematically validating and invalidating assumptions is the sign of a good engineer. One who doesnt make assumptions at all just wouldnt do anything, though.

I assume that when I press a key on my keyboard, the corresponding character will show up in my code editor. If I couldn't assume that, I doubt I'd see the use of pressing any keys at all.

(For clarity's sake: Not disagreeing at all, just illustrating your point with a reductio ad absurdum example.)

Re: Things I’ve learned in my 20 years as a software engineer

#738

> Software engineers should do anything that requires them to keep their written communication skills sharp. In my opinion, code is nicest when it is written communication. When it is almost the same as teaching someone about a problem domain.

> In my opinion, code is nicest when it is written communication. When it is almost the same as teaching someone about a problem domain.

In a way, code is "teaching" the computer how to do some specific task in some specific problem domain. Fortunately, we know how to do that; it's what we do all day. It's just that the computer is a very dumb pupil, so it needs everything explained to it in detail. OK, no problem, so we explain in detail. We know how to do that too; that's still what we do all day.

The next thing is, the computer is very literal-minded, has an excellent memory, and no imagination or sense of "the whole picture". It has absolutely no problem with us calling everything "i, j, k..." and "x, y, z..." But people do; in that sense we're pretty much the opposite of the computer. If only we could remember to call everything something more precise than "i, j, k..." and "x, y, z," the same "explanation" -- our code -- would be much more comprehensible to humans, too, and work as communication not just with the computer but with other people, including ourselves at some later time. (Albeit a rather tedious and detailed explanation, since most humans aren't as dumb as the computer.)

That's (probably, IMO, at least in large part) why "Naming things is the most important problem in computing".

Re: Things I’ve learned in my 20 years as a software engineer

#739
post #212

"If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system" That is what the "old" models such as waterfall say: as a first phase, complete and accurate software requirements list to be captured in a product requirements document

You are conflating process with design. You can have an iterative process and still take time to think, design and specify things.

> You can have an iterative process and still take time to think, design and specify things.

Start with some thinking, designing and specifying, then start implementing from that -- but remember to take the time for some more thinking, designing and specifying throughout the process going forward.

(Not disagreeing, just "spelling out". Hm, is this my new personal definition of "Agile"?)

Re: Things I’ve learned in my 20 years as a software engineer

#740
post #403

"Nothing worries me more than a senior engineer that has no opinion of their tools" Nothing worries me more than the opinioned. Open your mind. You shouldn't have deep opinions on your tools because they change, your need and understanding of them changes.

> You shouldn't have deep opinions on your tools because they change, your need and understanding of them changes.

What's the problem with that? Opinions can also change.

Post reply on HN