Live data from Hacker News

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

simplethread.com

601–610 of 745 posts

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

#601

Earlier quoted context omitted.

At my company you get one interview, if you get a second interview it is because we liked you but someone else was better and passed your resume on to a different team. One thing we do is take every candidate to lunch (COVID has changed this of course) with someone who doesn't have input into if you are hired: so feel free to ask those questions that you are not sure about. Having done a few interviews, nobody knows…

> lunch ... with someone who doesn't have input I think part of this could be that they don't know whether to believe that you truly have no input. When I was an interviewee, my lunch escort told me they didn't, and I was pretty sure it wasn't a devious trick to get me to let my guard down, but I had no way of knowing for sure. I also thought, if there isn't a formal process, maybe if I say something too dumb or wron…

Yeah, in principle it's a great idea. Realistically no rational candidate would believe that the lunch escort has no input.

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

#602

Earlier quoted context omitted.

Author nails it though with: "We should be far more concerned with keeping 0.1x programmers off our teams than finding the mythical 10x programmer."

This is just rescaling. The author is actually acknowledging that there exists 10x differences but divides by 10 for some reason.

The author's point is that more effort should be spent removing negative outliers instead of hunting for elusive positive outliers.

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

#603
The 10x programmer discussion feels a bit silly partly because it’s on the wrong scale. The real scale is more like this:

In a specified amount of time, N, what is the conditional probability that the engineer, e, can design and code a solution which is (relatively) error free?

This shifts into [0, 1] and is really asking the more important question.

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

#604

Earlier quoted context omitted.

This is the opposite of how you should want any knowledge worker to think. If you believe that there’s some innate ability that makes people 10x better at a skill than you rather than hours of practice and study then you are much less likely to acquire that skill or learn those skills efficiently. You need to have a growth mindset to be an effective knowledge worker not a fixed mindset. This is discussed in the book…

> This is the opposite of how you should want any knowledge worker to think. Some of us don't choose our beliefs based on what is most convenient or most beneficial to us. Instead, we try to see the world for what it is, truthfully (or as close to a true representation of the world as it's possible to get, anyway). If having a realistic worldview hinders my ability to learn, then so be it. Not everything is about max…

> If having a realistic worldview hinders my ability to learn, then so be it.

I think the point is that the worldview you described is not realistic.

Many people are successful because of hard work and dedication. Sometimes having talent in a tangential field (design, reading, being a good listener) is enough to make you an excellent engineer or team member. Success is complicated and often depends more on the world than on your particular attributes. Example: Maxwell was a true genius, but he had Faraday's life's work to read through. Faraday was a hard worker and a meticulous note taker who didn't really know math, but without his work Maxwell would not have been able to write his equations. Can you imagine if Faraday gave up science because he wasn't good at math?

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

#605
post #405

The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. You know, 10x is an optimistic number here. Some programmers will do in 1 day what you wont achieve in a life time. And not understanding that makes you a bad programmer by my book simply because this is the foundation of the job. So let…

> You think John Carmack was the only one trying to make 3d games when Doom came out? Thousands of programmers where trying to. Does that make him a 10x programmer in your opinion? Or more like a 1000x? I think the idea of 10x programmers gets so much pushback because it's often bundled with this kind of toxic hero worship. There's a difference between acknowledging the impressive ability of outliers, and idolizing h…

Warren Spector's quote, for reference:

>"There's a tendency among the press to attribute the creation of a game to a single person," says Warren Spector, creator of Thief and Deus Ex.

https://www.ign.com/articles/2001/11/12/deus-ex-2

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

#606
> "The only way someone can be a 10x programmer is if you compare them to 0.1x programmers. Someone who wastes time, doesn’t ask for feedback, doesn’t test their code, doesn’t consider edge cases, etc… We should be far more concerned with keeping 0.1x programmers off our teams than finding the mythical 10x programmer."

I think I would add to that that 0.1x programmers are to some extent a product of their environment. Maybe there are people who are inherently 0.1x programmers and there's nothing anyone can do about it, but I think it's also the case that the local engineering culture can turn people into 0.1x programmers. So, the important thing is to figure out how that happens and don't do it.

Some examples: make people do arbitrary repetitive tasks. Hide information. Make infrastructure changes frequently to the point where people regularly have to ask "how do I do this important job function today?" Create domain-specific languages and don't document them. Use build systems that don't work reliably. Have CI systems that require users to wade through megabytes of errors to find the one line that failed. Invent new words for things, or use old words in creative new ways. Speak in acronyms. Create technical documentation (if at all) that never explains "why". Don't set aside time for training. If a question warrants a one-sentence answer, filibuster for ten minutes to prevent follow-up questions from being asked. If it warrants a ten minute answer, reply with a sentence. Especially if you're in a very different time zone, and every follow-up question adds 24 hours to task completion time. Treat "programming ability" as some immutable attribute that is conferred on developers by completion of a bachelor's degree in a computer-related field, and that these programmers are interchangeable and their skills always current and directly applicable to the task at hand. Create Byzantine labyrinths of web-based tools that none can navigate without first having been shown the way through.

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

#607

Earlier quoted context omitted.

You’re looking for a job. You have 10 minutes to ask questions that make you stand out, to a individual who probably cannot answer the question. You do you.

Employment is a partnership, not servitude. That means the employer needs to convince the employee to work for them. I'm fine being rejected by a place that will treat me like shit.

Isn’t a partnership supposed to be mutual?

You seem to think that it should be one sided, with them doing all the selling/figuring though, which seems to be pretty problematic in other ways.

For some folks, at some times, that can certainly work. But it sounds like you want them to be in servitude to you, not an actual partnership.

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

#608

Earlier quoted context omitted.

The company buys, the candidate sells. This is proven by which way the money flows - from the company to the employee. But both have to agree. You're right that a company will have to be willing to offer enough to get the candidate willing to sell. I recall interviewing a candidate long ago who was only interested in what the company could do for him. He never displayed any interest in the company or what he could do…

I understand that I have to bullshit people like you in interviews and pretend to care.

And they know they need to not hire people who think this way, as it is inevitably cancer for whatever team or product they are on.

Why not find something you actually care about instead of spending all your time and effort faking it?

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

#609

Earlier quoted context omitted.

That's so spot on. Your Q&A session is your chance to learn something real and convey what you care about. A good question might me like "what's the hardest thing you had to do this year" or "how did you make decisions in cases of disagreement?" or something like that. It shows you're thinking about the job and whether you're a right fit. High quality questions say something about you. Low quality questions do too. W…

Different priorities I guess. Personally I’m exchanging my time for money and would like to know what kind of a deal I’m getting. I’m too old for all the fluff bullshit. Yes yes yes I’m sure you’re changing the world and creating super exciting CRUD

> Different priorities I guess. Personally I’m exchanging my time for money and would like to know what kind of a deal I’m getting. I’m too old for all the fluff bullshit.... Yes yes yes I’m sure you’re changing the world and creating super exciting CRUD

You know, I actually found this comment clarifying. I don't look at work as solely exchanging time for money (don't get me wrong, I care about money a lot, I just want to get a lot more than money out of my work) so I was coming at it from a different direction.

I do think there's an employee-employer compatibility in play here. Because I care about engagement/mission, I tend to work at companies with a strong culture and seek the same when I interview others - but yeah it's a good reminder that this is not for what everyone wants/needs.

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

#610

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

Maybe we should all ask this question in our interviews so we can avoid these shitty teams that way!

I like to ask if their health insurance covers drug rehab. That goes over well.
Post reply on HN