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

Most people mostly care about his/her own opinions, and others opinions only insofar as they reflect on himself/herself (even though of course the others are also thinking about themselves mostly), we're hopelessly self-involved creatures like that. Nonetheless there is inertia and subtle shifts that can come from sharing them, and though it may often feel like coming up against a brick wall if you look in the right way you'll see the bricks may be aligned a bit differently, and you can trace some of those differences to opinions you may have expressed.

As always the wise approach is probably somewhere in the middle, in this case choosing your battles. You don't have to voice every opinion, but you shouldn't be silent if you have a strong and well-formed opinion about something important.

I think he's beating up a straw man, here.

> The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly.

Over such short time scales, maybe, but the idea that someone could contribute in 1 year what another programmer wouldn't accomplish in 10 years is highly plausible, to me.

I have some comments as a software engineer of 8+ years of professional experience.

> 1. I still don’t know very much

Yep.

> 2. The hardest part of software is building the right thing

That's definitely hard but I'd say it's the people that are the hardest part.

> 3. The best software engineers think like designers

I'm not sure I entirely agree. It's also in total conflict with the growth economy the employs many of us; properly designing stuff takes time. No matter what, I always end up in a situation where "they want this as soon as possible". Being able to take the time to actually design something seems more like the exception than the norm. The only way around it is experience so that something resembling good design can occur by knee-jerk.

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

> 5. Software is a means to an end

> 6. Sometimes you have to stop sharpening the saw, and just start cutting shit

Yes.

> 7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system

Honestly, I don't that any of us have a good grasp of the universe of possibilities. A "good" system is highly subjective. Bad code is at least somewhat measurable if it doesn't work, isn't efficient, or takes a long time for engineers to understand.

There may be no such thing as good code. There's working code and there's code that fails to do its job.

> 8. Every system eventually sucks, get over it

I'd put an asterisk in front of "every". Many "good" systems turn out to suck not only because people ruin them but because engineers learn, grown, and change. While I tend to hate codebases more over time, there are some that I come back to years later and am still impressed by.

> 9. Nobody asks “why” enough

Yes. This has to be part of company culture, however. Many get defensive when subordinates question even the simplest of things, no matter how much they encourage that you "ask questions".

> 10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers

Maybe, but I've met more 10x developers than I have 0.1x. And I've met exactly one 10x developer.

There was one guy who got canned at the first company that I worked for, and my bosses justified it because they thought he "wasn't doing anything". In actuality, he was directed poorly. Some people can just ignore bullshit management but others need seniors who can provide direction and some level of mentorship. That doesn't mean they are 0.1x developers. It may mean that team leaders haven't managed to find that developer's particular strength.

The closest I've found to 0.1x developers were some dudebros I met during my education, but every one of them flunked out.

> 11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be

I've always had opinions so I'm not sure I relate to this as a senior engineer. I have more opinions, and sometimes more nuanced ones, but in many ways I feel similar to how I did as a junior engineer. I'm frequently astounded by how much more I need to learn.

I guess the major difference I see is in the kind of opinions. Many juniors have opinions, but they are largely additive. Senior engineers who have been in the battle field long enough have opinions but they're more subtractive, or saying "you know, we don't need to add more steps to our toolchain, and maybe we don't need another framework".

> 12. People don’t really want innovation

Innovation rocks the boat for businesses beyond a certain "escape velocity" and what many consider "innovative" is actually confusing since innovation by definition is non-standard.

> 13. Your data is the most important part of your system

> 14. Look for technological sharks

> 15. Don’t mistake humility for ignorance

Yes.

> 16. Software engineers should write regularly

Meh.

> 17. Keep your processes as lean as possible

If I had things my way, I'd get rid of "standups" and "retros", uninstall unadulterated bullshit like Pivotal Tracker in favor of something much simpler like Trello or even a Google spreadsheet, eliminate estimations, and only have meetings that are goal oriented.

> 18. Software engineers, like all humans, need to feel ownership

> 19. Interviews are almost worthless for telling how good of a team member someone will be

> 20. Always strive to build a smaller system

Yes.

Make an API out of that. There is huge demand for it.

The reason people struggle with the idea of 10x programmers is that people are very bad at evaluating the impact of others. Obviously we can all agree on a select few but for those who are just "regular" workers there is often not enough context.