Live data from Hacker News

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

simplethread.com

561–570 of 745 posts

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

#561

Earlier quoted context omitted.

They're the same thing if your day-to-day productivity requires invention, as it does in Carmack's case (and I would argue most programmers)

They are not the same thing, unless they achieve what a 1x programmer won't on a lifetime on a day-to-day basis. If the 10x, 100x or 1000x programmer does not do the 10x, 100x or 1000x times on average on their day to day then they are not 10x, 100x or 1000x programmers. (for whatever the heck a 1x programmer is, which people talking about 10x programmers oddly always skip on giving any decent definition)

Yes, exactly.

The best programmers can produce code every day that a mediocre programmer cannot ever produce under any conditions. That is the entire point of the discussion.

I don't even think it's that controversial of a statement, just shift to another field and I think it's self-evident. Paul Erdos could on any day produce better mathematics than the rest of us could produce in a lifetime. Not better maths than his peers, but his peers were also exceptional. Better than the average person who knows how to do their times tables though? Absolutely.

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

#562

Earlier quoted context omitted.

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…

Last month I ran into The Principle of Least Power, and it's grabbed me and the more I think about it, the more it expands. I think all of your statements lines up with this principle, except one. Containers are a simpler solution than Operating Systems. Operating Systems is a tightly bound non-simplistic system that breeds complexity, just as you state npm does. Because those interfaces are tightly bound, we were no…

yeah, no. Containers run on top of Operating Systems. They inherit everything that the underlying OS has. They're not simpler, they're actually more complex, but pretend to be simpler.

What you're thinking of is Unikernels. These are simpler than OS's. And yes, Unikernels are a good alternative to containers for a lot of applications we currently use containers for.

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

#563
post #377

> “if they ask about time off in the first interview then they are never going to be there!” The fact that this attitude is common scares me when I'm doing interviews. Time off is incredibly important to me. What's the use of making a great income if you can't get the time off to enjoy it? The culture about the use of PTO varies wildly between companies. A friend of mine worked somewhere that supposedly gave 20 days…

The problem is not what's important to you when you do an interview. It's not a friendly club, it's the guys who will pay your rent for a while, just act like you pretend to understand this, and ask by side channel, out of sheer strategy. You CAN refuse once the contract arrives for signature, the interview is a lot also for the company to have argument to sell you to management as a worthy investment. I admit I neve…

This sounds absolutely dreadful. You’re doing everyone you turn away a huge favor, and I feel bad for anyone you don’t. If I got even a hint of this in an interview I’d be out the door without letting you complete a sentence.

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

#564

Earlier quoted context omitted.

They're the same thing if your day-to-day productivity requires invention, as it does in Carmack's case (and I would argue most programmers)

I would argue that that's not the case for most programmers, at least not in the sense of developing a new p2p protocol, or a fast inverse square root algorithm. Would John Carmack code, e.g. a checkout system for an iPhone app 1000x faster than most programmers? I doubt that.

The interface he produced for that checkout system, the naming conventions he chose, the nature of state encapsulation, the testability of it? Yes, I believe Carmack would produce _better_ code in all those things than the median programmer every time.

There is much more to 10x than how many lines of code you can produce. A monkey on a keyboard can type faster than Carmack but productivity is not assisted. No one is arguing that a 10x programmer is more efficient by way of swift fingers.

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

#565

Earlier quoted context omitted.

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…

Those seem like pretty unobjectionable opinions. Have an upvote! You want a controversial opinion (on HN), how about mine: "It's not always a good tradeoff to throw something under the bus to save developer time." So many important things are routinely sacrificed at the altar of developer speed and comfort, app runtime performance being the big one. It's used to justify all sorts of crazy things we do in modern softw…

Have an upvote yourself! yes, totally agree.

Like Wordpress optimises for edit functionality, at the expense of render speed. Most of the internet is now slow, optimised for Susan From Marketing because they don't know how to edit HTML.

Same for Ruby/Rails, same for Python/Django, same for Node/whatever. Web pages render slower so that whoever edits them can do that faster.

This isn't good.

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

#567

Earlier quoted context omitted.

Usually I am more inclined to hire someone who discusses time off during an interview. It shows that they think about their life-work balance. I do not need heroes, I need reliable folks who do not burn themselves out. Or to put it in a cliche... I need people who work to live rather then live to work.

and also importantly people who have family to take care of. If someone comes to me and asks for time off because they have children or partners or parents to take care off and they take that seriously that certainly deserves some respect would make a better impression on me than someone showing up with a Patrick Bateman business card in hand

If I ask for time off to sit on my arse all day and play games what would you say?

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

#568

Earlier quoted context omitted.

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…

Totally agree. Some problems are complex. However, that does not mean that the code needs to be complex. Simplicity should still be a design goal even if the problem space is complex.

I don't really agree that there is a "complexity floor". Things can always be made simpler, up to the limit of the problem space. As you say, complexity can always be added. Most projects do this. Very few stick to the minimum complexity. The complexity floor for most projects is therefore way below where that line is normally drawn.

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

#569

Earlier quoted context omitted.

That’s a pretty huge distinction. Can’t believe he misrepresented the author like that.

That was not my intention. I was operating under the assumption that anybody in the comment section had read the article first, since then it would have been known that I wasn't quoting the author, I was quoting something the author quoted.

It's the correct assumption to be made for the comments section to the article you quoted from.

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

#570

Earlier quoted context omitted.

Your quote of the article made me think I was going to hate the advice, but then I realized you quoted it out of context, here's the full quote: > People might claim they have “signals” for these things… “if they ask about time off in the first interview then they are never going to be there!” But these are all bullshit. If you’re using signals like these you’re just guessing and turning away good candidates

Ooof...re-reading my comment, I can certainly see your interpretation. It definitely was not my intent to paint the author of the article as the person who made that quote. Unfortunately, I can't edit my comment now.

I was going to not read the whole thing based on your comment, but now I'm reassured
Post reply on HN