Live data from Hacker News

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

simplethread.com

61–70 of 745 posts

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

#61
post #41
post #6

This is a very insightful list. But there is one thing I'd quibble with: while it's inherently a super-subjective metric, I would say that 10x programmers do exist. Both in the "can support a company by themselves" sense and the "mad lone genius" sense. Not all the 10x programmers are good at working with other people or on other people's ideas. 0.1x programmers are often lost or afraid, although they may just be uni…

My go-to examples of 10x developers are benevolent dictators like antirez (of Redis), evanw (of esbuild + Figma CTO), youyuxi (of Vue), Carmack, etc. Both qualitatively and quantitatively, their output is at least 10x of a typical developer at a typical company, not even counting everything these people do besides writing code. Many more are not famous but are in the same league of impact/productivity - I'm genuinely…

You mix popularity with 10x. Not all 10x programmers are popular.

I believe 10xers exist within a business or technical context. This isn't limited to the field of computer science, but even traditional engineering (Edison) and sciences (Newton) have plenty 10x examples.

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

#62
post #6

This is a very insightful list. But there is one thing I'd quibble with: while it's inherently a super-subjective metric, I would say that 10x programmers do exist. Both in the "can support a company by themselves" sense and the "mad lone genius" sense. Not all the 10x programmers are good at working with other people or on other people's ideas. 0.1x programmers are often lost or afraid, although they may just be uni…

Saying 10x programmers are a myth because it's crazy that someone could do in 1 day what another could do in 1 week makes the assumption that both programmers in the example have the same amount of context, background understanding, and experience. The benefit of talented engineers comes from the fact that they avoid costly pitfalls - not that they pump out more code per hour worked. I feel this "10x programmers are…

I always read it as a direct comparison though.

It doesn’t matter if I have better experience or I can contextualise intent better; the phrase “10x” means it would take a team of 10 to do it, in the time, scope, budget (whatever).

But there are major reasons this could be the case, if I’m on my own and I know the direction then I don’t have to quibble about what framework to use, how to name my variables, what I consider “proof of concept quality”. You just get your head down and do it with the entire scope and progress in your head at once.

No infighting about semantics, no deeply technical progress reports or trying to subdivide tasks which are not inherently subdividable.

More people is more communication and it’s quadratic.

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

#63
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 '…

In the fantasy organization where means justify ends, the 10x-er's time is better spent making the 1x-er obsolete. Your lip service to the 1x-er however does not go unappreciated as keeping him on and making him feel more productive is instrumental for political advancement, which is more important for your fortunes than the technical kind.

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

#64
post #11

Earlier quoted context omitted.

you can replace the word "software" with basically any other professional work and that is still the same. I don't know what you can learn from the fact that it's a social service.

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've found in order to make the API more human friendly? Would make it easier but reduce accuracy.

You seem to be in the second camp, reduce power of API and make them easier to use. But lots of people think that the best way to serve humans is to make more powerful and strict API's.

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

#65
> You can design the most technically impressive thing in the world, and then have nobody want to use it. Happens all the time.

Very true... just yesterday someone posted about the Pony language main user switching to Rust:

https://www.wallaroo.ai/blog-posts/wallaroo-move-to-rust

Despite Pony being an impressive programming language, technically, with a lot of promise, pretty much only one company ever used it and now that it's moved on, Pony is pretty much in the camp "no one uses it".

And much of it is serendipity. A few tiny things could've happened differently, and now everyone would be talking about Pony, not Rust. Similarly, perhaps, happened with Ceylon (anyone remembers that??) VS Kotlin.

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

#66
"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

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

#67
post #11

40+ years of experience here, and I'll tell you the #1 thing I've learned: * Software is a social service. Its for other humans. Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in...

you can replace the word "software" with basically any other professional work and that is still the same. I don't know what you can learn from the fact that it's a social service.

I've met a lot of people who are writing code to satisfy requirements and collect a paycheck. They're good people, but just don't automatically think about the end user. They stop when the requirements are met, instead of when the user will be happy.

That's what they're supposed to learn from that, IMO.

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

#68

40+ years of experience here, and I'll tell you the #1 thing I've learned: * Software is a social service. Its for other humans. Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in...

Can't agree with this enough. Sometimes it is directly for other humans (a GUI), other times it is indirectly related (an ETL job that converts data into a form that can be easily used to drive a recommendation engine which provides recommendations ... to people).

This is tied into asking "why", another one of the author's points. At the end of the day, if you dig deep enough, the why will be related to human happiness.

Bonus! If you keep this in mind, you'll also gain perspective. While you don't want to live at 30k feet all the time, periodically gaining high level perspective of the problem you are solving has been, for me, one of the joys of software development. (Not the only one, but definitely a significant one.) Hopefully it is that way for you too.

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

#69
I loved a lot of this list, but the best part was the disclaimer in front. I've given talks about software development in the past and usually start with a similar disclaimer.

If I am giving you advice, you should know my context. It'll help you determine if my advice is useful in yours.

Bravo!

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

#70
post #59

Earlier quoted context omitted.

Even if YOU are the only user, you're still writing software for a human. Hopefully.

With that argument you could say that everything humans ever did was for humans. So either it is a platitude or it is wrong.

You could say that, but my cat thinks you'd be wrong.

However, I'm yet to see my cat boot up the computer.

Post reply on HN