Live data from Hacker News

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

simplethread.com

111–120 of 745 posts

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

#111
post #97

Earlier quoted context omitted.

To pose it another way: for general software Dev (not some niche use case that only one guy understands), let’s say building websites in Vue or React, the idea of a 10x developer is that they can work in January and another, average, programmer can then spend February, March, April, May, June, July, August, and Sept… and the average guy won’t get more done? Or they come in only every other Monday and contribute as mu…

There is no "10X" touch-typist because a) the performance limit is absolute & relatively low and b) the learning curve is such that it's easy to get to the limit and plateau. Now let's increase complexity - still typing, but you must translate the text from another language. Increase again - now you're translating poetry. Increase again - the poetry is original Shakespeare. You need to translate into contemporary Eng…

Even with drudge ticket-punching work, there is a vast spectrum of productivity between somebody who is capable and conscientious enough to do it correctly the first time and the person who has to rework everything multiple times because they can't do it right the first time and continue making mistakes.

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

#112
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…

Of course one programmer can create 10X the code of another. The limit isn't how fast they type. Its how correct the code is, and how much it leverages what you have and what you'll need. And that results in 'pumping out' more code per day. Whatever the reason (context, background, experience)

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

#113
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…

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

Yes, because that's how it's always presented. And if it's not, then it's also a myth because then it's not a 10x dev, it's 10x context, background understanding, and experience.

Either way it doesn't hold water.

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

#115

> 11. ..... > Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. The more you learn the more you realise you were wrong. Having an opinion has often come to mean one is a fan boy of something and will have it no other way. I have heard team leads say "this python code is bad because it uses no classes" or "we need to use EMR so we can process all cu…

> I have heard team leads say "this python code is bad because it uses no classes"

And they'll say it's "best practice".

"best practice" has basically come to mean "whatever that particular developer knows/likes"

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

#117
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…

I like FactoryFactory devs, they are even worse than 0.1x. After some time every other team member who touches their code becomes 0.5x.

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

#118

Earlier quoted context omitted.

That's a useless advice IMO. How can you not assuming anything. I assume that my CPU works, for example. You can't write useful programs without many assumptions. Imagine program that does not assume that CPU works and reruns every algorithm few times with few different code versions to verify that outputs match. It might make sense for moon mission, but definitely not for another CRUD app. I don't have 20 years of e…

> I assume that my CPU works This is not a blind assumption that you make, but one based on lots of evidence (for example you are aware of the testing procedures and QA processes of the CPU manufacture, and you are aware that millions of people and companies use the same CPU model as you and if there were bugs they would have detected them). If you were to buy some CPU that someone shady made themselves in their base…

TBH, I got bitten by this assumption. Once, in the course of many decades. A single flipped bit - in a place where it never could happen in the program. After checking everything up and down the stack, this was our conclusion: "the issued command was invalid, thus caught and aborted; the higher-level operation was rolled back, retried, and succeeded; impact: some insignificant delay; root cause: probably cosmic rays; probability of repeating: infinitesimal. Result: no point in guarding against that." (Note that this was in normal athmospheric conditions, not in deep space, hence the probability.)

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

#119

> I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. I've been a developer for 15 years... anybody else feel like the further they get into their career, the more they want to keep their opinions to themselves? I feel like as a junior dev I had way stronger opinions and I was a lot more vocal about them. Now, I still have opinions, but I've learned that nobody…

It comes in waves. I'm in my 22nd year of developing software and I can reflect on times when I felt incredibly confident and didn't shy away from sharing my opinions, and other times when I felt like it was better to remain silent because I had things to learn from others.

There are times for both speaking and listening in our careers; as I've progressed further in my career I have felt it is often more valuable to exercise active listening.

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

#120

Earlier quoted context omitted.

And, as the article says, your advice and the GP’s are contextual. If you’re interested in creating software that makes people happy, solves their problems, gets cherished and recommended - then work hard to not lose sight of that goal in the thick of crafting a massive code edifice. If you’re interested in pushing the limits of your own creativity, and building a technical structure capable of handling domain comple…

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

But then we can also go the other way, and forget how crazy and diverse humans are. So you will still, eventually, end up facing the same challenge, framed differently.
Post reply on HN