Live data from Hacker News

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

simplethread.com

501–510 of 745 posts

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

#501
post #498

Earlier quoted context omitted.

As your sports coach always said "You don't need talent to practice!" I'm not a huge believer of some mystical "innate ability" that people sometimes use to explain talent. Imagine a great concert pianist who plays flawlessly. After the concert, someone says, "Oh, you were born with such a wonderful gift of talent!" If I were that pianist, I'd be kind of offended--it totally ignores the decades of daily practice it t…

The capacity to practice is itself partially innate. Take a person with ADHD - they will naturally have a harder time practicing piano. I myself was unable to practice piano as a child, but for different reasons.

> Take a person with ADHD - they will naturally have a harder time practicing piano.

Or easier. Depending on how the hyperfocus-or-none dice roll for piano...

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

#502

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

If the company thinks they have a good story around PTO they will sell it in the first interview. As an interviewee it's very important to me and I will definitely ask questions, but later in the process when I have more leverage. I don't think someone asking in the first interview is lazy, just perhaps naive. They'd be better to ask about work/life balance and expectations in general and then probe what the intervie…

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 what questions to ask.

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

#503

Earlier quoted context omitted.

Someone who replies with that kind of hyperbole is just saying they don’t want anyone who is going to take more than a bare minimum of PTO. 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, and that you want to clarify expectations up front to make sure that you and the company are an ideal…

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

If you are not dealing with a reasonable person you don't want to work there anyway.

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

#504

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 think you have a false dichotomy here. Carmack isn't 10x better a C or assembly than me. But in his domain he's easily 10x smarter and more productive than me. And on top of that, he has a quarter century more experience in graphics programming than me. That shit accumulates. Yes, actually. I…

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

The median games programmer wouldn't be able to do it in 50 years. (assuming they were locked in a room for 50 years with that same hardware, not that they got to see state of the art progress and upgrade their machine)

The amount of innovation, from applied BSP, Zbuffer tradeoffs, light maps with interpolation, interleaved FPU corrections for texture mapping, multiplayer protocols (qtest used TCP), brush-levels, etc...

Before ID software did these things, they weren't checkboxes for what to do. After, sure. But the hard part of programming is not typing.

The median programmer would not have been able to do it before it had been completely irrelevant. The median games programmer could do it in 2005. In 1993-1996? Not a chance.

The main competitor to Quake was Duke Nukem, which technologically was just "doom and a half". The enemies were sprites, ffs.

ID software was years ahead of every other games developer.

The reason other games licensed the Quake engine wasn't that it was cheaper than doing it yourself, it was that they couldn't do it.

Edit: granted, I have a low opinion of the median programmer. But sometimes in life you meet people who, with things you think you're actually pretty good at, just completely mop the floor with you without even trying (or showing off). It's humbling.

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

#505

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

Agree. If I were the interviewer I would probably do the same. Asking about how people spend their life can also reveal a lot about their personality as well.

Asking about how people spend their life is often illegal to ask. If you don't know the local laws only ask job related questions. This is why my company gives me a script of questions I'm allowed to ask - to get the conversation started on legal topics in ways that are unlikely to stray into illegal areas. (more than once I've had illegal information given to me - but I didn't ask so that is okay)

Illegal information isn't anything that will affect how someone does the job in general. You learn about personality, but I hope you can deal with those personalities anyway.

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

#506

Earlier quoted context omitted.

Agreed, I don't know why the industry (or people?) in general have a problem with accepting this abilities gap. It's as if the notion of people being arbitrarily born more or less with a knack for something is evil. Let me tell you the story of when I realized I was (at best), a "not-mediocre" dev: 1. I've been programming for fun even as a kid. That's what got me into it: If you count kid-programming as "programming…

There was some tweet recently that went "Saying 10x engineers don't exist is as true as saying 10x basketball players don't exist or that all writers are basically the same." It's self-evidently not true.

No. It's like saying that a good mechanic can fix a car 10 times faster than another. Even if a good mechanic manages to find the problem in less time than a non experienced one, he still has to do the repair.

That is similar to programming: even if you have everything clear in your head, you know how to do every single thing that is written in the requirements of the program, you still have to type it out.

A lot of time I thought, well this is fairly easy, and then spent I month just typing out code.

The only situation where really a more experienced programmer can be more or less 10 times faster than a non experienced one is in debugging/troubleshooting problems, because with more experience he tends to know by experience where it's most likely that the problem is and thus test in that direction.

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

#507

Earlier quoted context omitted.

> factual Nope. Just because it says so in a book doesn't make it true. When you make a statement of the form "X does not exist", a single counter-example is sufficient to prove you wrong. Lucky for me, many such counter-examples exist, and many have even been discussed in this thread. I'll add one to the list: tourist (Gennady Korotkevich). He's a competitive coder that's several orders of magnitude (e.g. 1000x) bet…

I think you’re missing the point or I was unclear. The point is not that masters at a skill don't exist. The point is that attributing their skill mostly to something innate rather than practice, study, etc is not supported by the body of research they review in the book (the book is written for a general audience, their academic research supports the arguments in the book).

There is a mountain of evidence to the contrary. No matter how much you or I would practice, study, etc. we would never become as good as tourist. Most people reach their plateau in competitive coding within 1 year.

For example, here's my Codeforces profile: https://codeforces.com/profile/baobab

Started in 2015, plateau'd in 2016 and no measurable improvement from subsequent 3 years of practice and study.

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

#508

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.

Picking a career you're interested in and company you're interested in makes things a lot easier than having to maintain a phony facade.

A word of caution - interviewers tend to interview people an order of magnitude or two more times than candidates do interviews. What this means is they learn to detect the bullshit. A friend of mine is in the recruiting business. He interviews candidates all day, and has for many years. He told me that detecting bullshitters and liars is a crucial job skill, and he's pretty good at it.

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

#509

Earlier quoted context omitted.

A 10x programmer doesn't cost 10 times as much as a regular programmer. 10x programmers are real and drive real business value. The people who insist 10x programmers are a myth simply have not worked with one. Do not conflate brilliant-but-an-asshole or prodigious-output-but-creates-a-mess programmers with 10x programmers.

Yet another comment that uses the phrase 10x but does not provide any way to quantify it. No one is disputing geniuses exist. Calling them 10x, however, is problematic.

How is it a problem?

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

#510
post #487

Earlier quoted context omitted.

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

He didn't misrepresent or disagree with the author. He added extra commentary on something the author brought up.

The lack of context reltated to what the author wrote is a sin of omission -- because anyone reading a top-level comment that begins with a quote (like this) is, to a first approximation, going to imagine the commenter is responding to the position of the author.
Post reply on HN