Live data from Hacker News

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

simplethread.com

421–430 of 745 posts

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

#421

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

No, I've been doing this for ~30 years now and I have really strong unpopular opinions on things. Like: - NPM/Yarn/Gems etc is a disaster waiting to happen. Having lots of dependencies is a security nightmare and a maintenance issue. As these projects get dropped by their original maintainers we'll start seeing more supply-side attacks and more vulnerabilities going unpatched. - Docker is a great solution for a speci…

> Simplicity is an important design goal for all systems. Complexity breeds bugs

Counterpoint: some problem-spaces are inherently complex; most problem-spaces have hidden complexity. Complexity cannot be removed, it can only be moved up or down your tech stack, and obviously, you can needless add more complexity.

Docker, K8s and the like are perfectly fine when they fall below your project's complexity floor - they are good place to shift your complexity to as they are battle-tested and well-documented. If your projects complexity floor is lower than docker/k8s, then integrating them will just increase your solutions complexity needlessly.

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

#422

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

30+ years here, so I'm just a youngster compared to you, but yes, that seems to get lost.

My first mentor in the 80's was a jolly drunken programmer genius who enjoyed getting me to laugh at how bad my code was.

His biggest lesson was that other people need to read and use my code, not just me. It isn't enough to just hack a solution -- "Anyone CAN write code, but not everyone SHOULD write code" was his favorite quote -- but code needs "style" and "heart".

He even had a t-shirt made for me after my internship ended that had those two words and a bunch of my worst code examples printed on it. I still have it: just a bunch of MASM code. I'll Never forgot that guy.

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

#423

Earlier quoted context omitted.

> How long would it have taken you or me to write Doom, or Quake? How long would it have taken Carmack, if it'd just been him? I'm not a games programmer. I doubt a median games programmer would take 10x the length of time that it would take any other games programmer. It just seems implausible, and I don't know why people want to defend it.

I spent 8 years at EA and was a senior software engineer. I have absolutely witnessed 10x game programmers. I think in any field where you have a deep domain with complex, difficult constraints, it is entirely possible to have programmers with 10x the effectiveness of the median simply because of their greater domain expertise. They know the unique algorithms, data structures, design patterns, hacks, tricks, hardware…

[deleted]

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

#424
post #355

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

> Software is a social service. Its for other humans. I deeply disagree with this Calvinist utilitarian sentiment. Its akin to saying sex is for making babies. Maybe its an academic thing - When I went to grad school for CS, on Day 1 my Algorithms Professor paraphrased Perlis's famous quote on the blackboard - "Shaft the paying customer!" You can find the whole quote on the first page of SICP[1], or elsewhere[2]. imh…

So if Linus works on Linux for his own selfish reasons, howcome Linux isn't a one-person effort that nobody else is using? And why did they pick the GPL?

It sounds to me like you're describing bad social behavior but generally altruistic motivations with good social behavior but non-altruistic motivations, and you prefer the former over the latter. Sure, thats fine.

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

#425
post #52

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.

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

Disclaimer: I feel strongly about this. However, if you have a strong other opinion, then I applaud you and I'd be curious to read it. Rationally, I don't think this term matters a lot as there are better terms to describe programmers, but emotionally it's tied too much to a friend of mine and that's what makes me feel so strongly about it.

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

As I said in another comment. I've met one 10x programmer. So I consider him to be the archetype 10x programmer since he's the only visible proof I have. We're good friends, we mostly talk about life. I sometimes see him code. Let me assure you, he is the last guy that would hack together POC code. I know this, because I'd be one of the first to do that and he gives me a lot of flack for that when I show it to him xD

I should have left out the "or" in my definition. He knows how to architect, he knows how to code, he micro-optimizes every nano, is capable of understanding how underlying ISAs are doing their thing. He knows how to reason well. At companies where he'd enter as a junior, he was immediately recognized for having better technical skills than people 10+ years their senior (note: not his social skills, those are simply normal).

They exist. And it's easy to see why 10x programmers exist. Take a bell curve of ability and you find many 10x'ers on many scales of ability.

Or would you argue that people like Einstein was not a 10x physicist, or that Euler wasn't a 10x mathematician? And there are many more that I wouldn't even know of.

10x programmer is very related to the idea of a genius, in my opinion. It's simply a subset of it.

Feel free to disagree. It's good to see other perspectives.

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

#426

Earlier quoted context omitted.

This is always my go to example of a 10x programmer: https://norvig.com/spell-correct.html How many developers do you know that would bang out a spelling corrector on a single plane flight, in half a page of code? It's a question of knowing the algorithms of tools that make things possible that other developers might not even consider, and how to express those ideas cleanly and concisely, evaluate your solution, and…

Norvig wasn't given a random problem that he then solved quickly. He picked the problem to work on. I'm sure I can give him problems of similar complexity that I work on for my job and he wouldn't do it that quickly. Quicker than me, for sure - but it wouldn't be hard to find someone who does it quicker than he did. I'm sure I can find problems that I can solve quickly and amaze people. Being able to pick your own pr…

This is one example.

Norvig has written a ton of kick ass programs in his career that are concise, efficient, and correct, in much less time than most programmers would require.

Furthermore, even picking your own problems can be a way to achieve > 10x productivity, as identifying useful problems to solve is also a crucial skill.

I attended a talk given by Norvig, where he frankly admitted Google picked markets to enter where they could get good quality data to train their machine learning models on (this was many years ago). Maybe lesser developers wouldn't have that insight.

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

#427
post #398

Earlier quoted context omitted.

Unlimited just means they don’t have to pay out when you quit or get laid off, doesn’t it?

Yes, but it also doesn't give any indication of norms around the amount of time off people take. Expectations may differ from how much time is in a traditional PTO bank but at least in general, it's OK to take accrued time off barring special circumstances.

I worked at a place that gave us 2 weeks and then took an act of Congress and months of social engineering to take even a day.

We got bought out and the new overlords announced they were going to give us five weeks of vacation. There was actual laughter in the room. We can't even use 2 weeks, what's 5 gonna do for us?

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

#428
post #142

Earlier quoted context omitted.

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.

> They stop when the requirements are met, instead of when the user will be happy. that's because they are doing software "for other humans" - aka, their manager and PM, who gave them the requirements. So the problem is not the software engineer, but the person who creates those requirements to be fulfilled.

I'm not asking that develop to go against the requirements. But it's often possible to satisfy requirements without satisfying the user, even though it's actually possible to do both.

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

#429

Earlier quoted context omitted.

Umm exactly? I’d rather get my own red flags out of the way rather than waste 8h of everyone’s time to find out the company has a shitty culture. I also checksum the compensation and on-call and other things in the first interview

Like it or not, when interviewing for a job, you're doing a sales presentation. A good sales presentation doesn't open by saying what you want. It opens by finding out what the customer's problems are, then you demonstrate that you can solve them, then when the customer is sold the price negotiation starts. If you want to vet a company's benefits and culture beforehand, which is a good idea, do the homework first and…

> Like it or not, when interviewing for a job, you're doing a sales presentation

Maybe in the 90s. Nowadays it's becoming very balanced in the way that companies are the ones who are doing a sales presentation as well.

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

#430

Earlier quoted context omitted.

> If you’re dealing with a reasonable person, you should be able to preface the question by explaining how having sufficient time off helps you do your best work and avoid burnout If you are dealing with a reasonable person, hopefully you want have to explain any of that.

Sure, I've just found that it can be helpful to clarify intent is all, especially when you're dealing with someone you've just met - e.g. maybe the interviewer is mostly reasonable, but is scarred from past negative experiences with colleagues who were legitimately lazy. This phrasing might help such a person understand where you're coming from a bit more easily.

If you need to clarify intent for something as fundamental as work/life balance, wouldn’t that be (at best) a yellow flag?
Post reply on HN