Live data from Hacker News

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

simplethread.com

71–80 of 745 posts

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

#71
post #52

Earlier quoted context omitted.

I've also met one 10x programmer in my life. A lot comes down to being able to reason fast, architect well, and write code on the fly without resorting much to: * Documentation * The debugger / print() Becoming a 10x developer means that you have a set of skills that work well together in an end to end process from going to initial requirements to fully fledged architecture and/or code.

> Becoming a 10x developer means that you have a set of skills that work well together in an end to end process from going to initial requirements to fully fledged architecture and/or code. The problem with that definition is that it tags the coveted 10x label onto the problematic cases mentioned in the article: that guy who is able to hack together POC code that he demos and passes off as the solution, but requires…

Honestly I’ve met real 10x programmers.

Well, speaking honestly probably more like 5x, but it would take a solid 5 person team working well together to do the same things he did.

His ability to reason about the problem- get to the root of the persons actual issue, proof of concept intitial revision and iterate until it was better quality than most popular open source projects was honestly awe inspring.

His only problem was his own lack of self confidence. He used tools and always asked if they were really the best or if he was inflicting them, had good reasons for not using things that we consider industry standard (he prefers restructured text over markdown because it’s more expressive, for example) but was ultimately very sad about every project he made because he felt like he had inflicted his (good) work on the world.

So, idk. The people who think they are rockstars probably not. He definitely didn’t think he was but he was a god to me.

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

#73
post #64

Earlier quoted context omitted.

Well, all economy is human economy, so yeah .. okay. You can learn from the fact that its a social service by actively NOT resisting the truth of this fact. Incorporate it into your thinking with every commit you make and you will become a better programmer over time. (Corollary: those developers who forget this fact, make shitty software...)

Everyone agrees that software is to serve humans. What they disagree about is how to best make software that serves humans. For example, lets say you write an API that translates text. Should you assume the text the human sent in is correct and return an error? That way you can make better translations when they send the right data. Or should you try to be helpful and automatically fix spelling errors you think you'v…

Either option is fine, as long as your user agrees.

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

#74
"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 talk to me instead while answering her questions.

My first through was that he was misogynistic, which is an automatic disqualification. But even if he was just shy, he's going to have to work with her daily for the first few months, and be in meetings with her for the entire time he worked there.

That's an extreme example, but there were plenty of instances where we were looking for the best candidate, and the interview made the decision easier when the code hadn't. We can only hire 1 candidate, and we have to do what we can to pick the one that will do the best work and get along best with the team.

That's what interviews are for.

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

#75
post #33

Earlier quoted context omitted.

It would be impossible to do any work at all without making assumptions. This attitude belies the fact that of the 1000s of assumptions you make every day 1 or 2 will end up being incorrect, but it's usually very, very hard or even impossible to know which in advance.

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.

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

#76
Excellent advice. I would add:

Showcase your work as much as possible and refine your ability to do so over time - Not only does regular showcasing of things you've built improve your reputation within a company but also allows you to disconnect from the implementation and focus on how something will be used. You'll often find bugs, shortcomings, or opportunities for improvement that you may otherwise have overlooked. Look for opportunities to showcase wherever possible and advocate for opportunities if they don't exist already.

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

#77
post #52

Earlier quoted context omitted.

I've also met one 10x programmer in my life. A lot comes down to being able to reason fast, architect well, and write code on the fly without resorting much to: * Documentation * The debugger / print() Becoming a 10x developer means that you have a set of skills that work well together in an end to end process from going to initial requirements to fully fledged architecture and/or code.

> Becoming a 10x developer means that you have a set of skills that work well together in an end to end process from going to initial requirements to fully fledged architecture and/or code. The problem with that definition is that it tags the coveted 10x label onto the problematic cases mentioned in the article: that guy who is able to hack together POC code that he demos and passes off as the solution, but requires…

If their code isn't running in production with little maintenance required then they didn't actually produce the thing. Just add that requirement and it becomes clear.

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

#79
post #49

Earlier quoted context omitted.

I've also met one 10x programmer in my life. A lot comes down to being able to reason fast, architect well, and write code on the fly without resorting much to: * Documentation * The debugger / print() Becoming a 10x developer means that you have a set of skills that work well together in an end to end process from going to initial requirements to fully fledged architecture and/or code.

I think most people who have worked with me would consider me a 10x developer, I am capable of writing something in hours that would take others weeks (not in a half-arsed way, but taking all of the complexities of the domain into account). And I think that's what most people think a 10x'er is: that they can just do stuff quicker. That's not what I think 10x'er is though. I think a 10x'er is someone who enables the '…

The way I see it:

Developer: a person that creates software.

10x development: a person that does it 10x faster.

What you describe, I'd simply call a lead developer since making other developers 2x or more is a lead developer his job.

If you're a developer and you're doing this, then it'd be one argument to get promoted to lead.

Also, if you really are a 10x dev, the one I know works in the HFT space. He's making bank. I'm not sure if that's your thing, but I've noticed they seem to appreciate 10x devs a lot more than any other company out there (and that includes FAANG).

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

#80
post #64

Earlier quoted context omitted.

Everyone agrees that software is to serve humans. What they disagree about is how to best make software that serves humans. For example, lets say you write an API that translates text. Should you assume the text the human sent in is correct and return an error? That way you can make better translations when they send the right data. Or should you try to be helpful and automatically fix spelling errors you think you'v…

Either option is fine, as long as your user agrees.

You have more than one user. Some of them will want power, other will want ease of use. You can't satisfy everyone without making multiple products.
Post reply on HN