Live data from Hacker News

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

simplethread.com

201–210 of 745 posts

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

#201

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

20+ years and I concur.

Improvements in my "soft skills" have carried me further than any technical learning.

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

#202

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

What a depressing reaction to adversity. An alternative reaction is to try and figure out why nobody cared, and get better at expressing yourself in ways that people will care.

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

#203
post #194
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…

Also, sometimes it isn’t someone ‘moving fast and breaking things’ - sometimes everyone else gets paralyzed with indecision and can’t even get started. Someone who can sit down and start coding in an ambiguous environment, period, can easily make 10x more value themselves, and allow others to go from .1x to 1-5x merely by being able to pick somewhere to start and just doing it, which allows everyone else to break the…

The "MVP" or "strawman" is incredibly valuable; people can't tell a blank sheet of paper what they want, but if you show them a thing they'll tell you what's wrong with it.

I've noticed myself that I can happily write detailed comments on HN or StackOverflow but have no inclination for blog posts, for that kind of self-content-marketing that seems to be popular these days.

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

#204

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

What's the quote? Knowledge can be taught. Wisdom can't be taught or told... it can only be learned through experience? Edit: Ah, found it. "Wisdom cannot be imparted. Wisdom that a wise man attempts to impart always sounds like foolishness to someone else ... Knowledge can be communicated, but not wisdom. One can find it, live it, do wonders through it, but one cannot communicate and teach it." - Siddhartha

"Wisdom can't be taught or told... it can only be learned through experience"

I recently had the thought, that good education guides you to certain experiences to really learn the subject and not memorize some definitions.

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

#205
> 4. The best code is no code, or code you don’t have to maintain

> 17. Keep your processes as lean as possible

> 20. Always strive to build a smaller system

He stops just short of saying it, but IMO a program with fewer lines of code is almost always better. You can write your Java in Python and have it be 1/5th the lines. You can drop the classes and use functions and save some lines.

Exceptions to this rule only happen because lines of code isn't an infallible measure of "size" or complexity.

> Project size is easily the most significant determinant of effort, cost and schedule

https://blog.codinghorror.com/diseconomies-of-scale-and-line...

This comes to mind after having written some short pieces of code which get "improved" by others. But all they did was move things into different files and turn some functions into classes. As though what makes good code is trivially wrapping everything in a class. I can't understand it.

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

#206

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

The more I learn the more I realise everyone else is wrong too. Especially when it comes to general purpose tools - there's so many tradeoffs even in an ideal world but really often the original author just did things wrong, but right enough that his solution stuck and everyone kept piling on and building on top. PHP and node come to mind immediately. Ruby is down right retarded with promoting Concerns for modeling c…

Your comment about Ruby is actually referring to the Rails framework. It also suffers for the slur.

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

#207

20 years of experience here. My little contributions: 21. Do not mistake hype and popularity for quality. 22. The best code is no code, but configuration is worse than code. Maintaining 1000 lines of YAML is worse than 9000 lines of code. 23. The best code is no code, but replacing a script with a zoo of tools and libraries is often worse.

I think I somewhat disagree with 22. Not specifically in terms of YAML or what is categorized as configuration (basically anything?). I think a well designed data model is much more productive and simple than arbitrary code.

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

#208
post #5

Amazingly, I agree with every single point. >> Nobody asks “why” enough This point is the most important IMO. It's so common for people to do things without asking themselves why they're doing it. Every line of code should fulfill a clear purpose. You want to avoid writing code which is difficult to explain to a non-technical person. >> People don’t really want innovation... If you believe in what you’re doing, and k…

> developers who work for big companies will get jealous and they will reject you. If you're very good, you need to pretend to be mediocre and above all; compliant.

To add to what another poster said, it's not jealousy.

Big companies move slow because generally, to get big, they had to be successful (to some extent) and changing too much all at once is a risk that the bureaucracy isn't always comfortable with.

One of my old managers (I work in "enterprise") used to say things like "the efficiencies that this solution will bring the company..." which was just a euphemism for more folks getting laid-off (happened all the time, and glassdoor was full of warnings about this) or more jobs being shipped to our offshore units or even down-sizing in our offshore units.

I think it's reasonable, at least in the US, where healthcare & retirement & welfare is so tightly coupled with employment, for folks in big companies to be wary of innovation. They might want their job to be easier, sure, but too easy and they could be out of a job (for example, if the workload that previously took 5 people can now be managed by 2 or 3).

We're building software for people.

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

#209

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

I got dinged in a 360 review by peers for not advocating for my views more.

I feel that if I present what I think we should do, and why I think it's the best alternative, I shouldn't have to get into a shouting match or even a debate. I don't take it personally if people disagree with me.

If I've got the best ideas and my managers are ignoring them for the loudest ideas, that's on them, not me.

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

#210

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

Same here. Been working professionally as a dev for 20 years and each year I care less and less about changing other people’s minds about architecture.

Just this year I was working with another team that wanted to move to an architecture that I thought was overengineered for their specific problems. They shared with me an article about some company that was using it. I explained my experiences with such a pattern and where the pitfalls were, hoping their lead dev would think about it or discuss the pros and cons. Well, it was met with silence. They went ahead with their plan anyway.

Too many times that’s happened in the work world, so at least now I don’t invest a lot of effort into changing minds. Best advice

I’ve learned these last few years is don’t tie yourself to your work. If you’re opinionated about how to do things because you love designing software, that’s great, but you’re setting yourself up to be disappointed by how things really get done.

Post reply on HN