Live data from Hacker News

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

simplethread.com

51–60 of 745 posts

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

#51
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 once worked on a team that in hindsight had two 10x developers in a team of only 12. They were vastly different, and the difference to me is extremely interesting.

The first one was not a bad person by any means, but had no social skills, no ability to communicate and often just forged ahead building great stuff on his own. Entire areas of the software were entirely conceived and created by him, and it was difficult to even grasp what he was doing while pair programming with him. In a day he would write more tests and get more coverage than the rest of us would create in a week.

The second one had come from a FAANG-ish place where he was extremely successful, but didn't want the money or stress. He was extremely kind, considerate and great at communicating. Pair programming with him was a joy and he helped everyone else on the team grow. I'm confident he could have created entire regions of the software on his own, but he knew that wasn't the right thing to do. He would often ask questions until someone else on the team could solve a problem, even though I'm sure he knew how to solve it easily himself.

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

#52
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'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 a whole team to fix and to rewrite and to rearchitect to get it to actually work and be production-ready and be maintainable.

Inadvertently, this means that we see the 10x label being tied to observable behaviors that are actually a productivity nightmare just because they go from zero to demo in record time.

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

#53

> 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 think that there is a very important distinction between having opinions, and willing to have it 'my way only'.

I subscribe to the 'strong opinions, weakly held' model. It's necessary to have opinions about things you're involved with. However, the real art is to be able to not be too attached to one's opinions, be open to change them, and be able to be a productive team member, even if there is a decision to do things in a way that doesn't conform to one's opinions even when the opinions haven't changed.

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

#54

I have seen many similar posts what people have learned but not once have I seen: "Don't assume anything". So many times when shit hit the bricks because someone assumed something about some other thing they clearly don't know everything about. Which eventually lead to the system failing.

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 experience yet. But my PoV is as follows: assume as much as you can and ensure that if those assumptions are broken, you have fail-fast-and-log triggers (when it's possible). So when that trigger hits, you'll understand what assumption is broken. For example in Java I'll write Objects.requireNonNull(x, "x") and move on. If that assumption is broken, I'll have stack trace in my logs and I'll write additional logic. It won't take much time. But if that assumption will not be broken, I just saved few hours of time and few dozens of LoC from future maintenance.

Some people hate NullPointerExceptions and want to get rid of them. I love them. They're incredibly useful for me.

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

#55

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

Approching the same experience level and fully agree.

A piece of coding art that doesn't fulfill customer needs, or requires understading of language standard minutia for fellow devs to do maintainance updates is worthless.

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

#56
post #28
post #8

Earlier quoted context omitted.

-1x programmers also exist, in a variety of guises. From the dev with long cv of projects he’s contributed nothing to and been sidelined from, but who manages to keep getting hired because of his cv, to the dev who crowbars in new tech where it’s not needed and causes a ton of problems.

Presumably a 1x programmer is an average programmer. The type who does his job acceptably. He doesn't create huge problems, nor solve them. He is a fine team player and team member, but not a leader. Nobody despairs when he leaves, and he will be forgotten after a few months. Basically, the majority of programmers.

This was about minus 1x, so having a negative impact. And yes, these do exist.

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

#57
post #33

I have seen many similar posts what people have learned but not once have I seen: "Don't assume anything". So many times when shit hit the bricks because someone assumed something about some other thing they clearly don't know everything about. Which eventually lead to the system failing.

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

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

#58

Earlier quoted context omitted.

So you write code in machine language? Or are you writing in a language that tries to be readable by English speaking humans?

Or they write it for themself and not _other_ humans.

Your future self can be seen as “other” humans given a long enough time frame.

Anybody who has looked at their own code done more than 5 years ago can surely attest.

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

#59

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.

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

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

#60

> 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 think points 11 and 15 (Don’t mistake humility for ignorance) play of each other.

I don't have a hate/love opinion on most things. I may have an opinion on wether or not one particular technical choice is contextually a good or bad idea. I may not be able to form an opinion.

Post reply on HN