Live data from Hacker News

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

simplethread.com

701–710 of 745 posts

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

#701
post #353

Earlier quoted context omitted.

What do people gain by arguing over these? Genuinely confused Just to be proud and gain that dopamine?

> What do people gain by arguing over these? Genuinely confused If you assume some arguments (eventually, in some way) lead to people altering their opinions closer to the truth, then people gain more accurate views of the world. This also reduces the spread of misinformation (when the people who have corrected their views no longer spread it), thus having a compounding effect on more people getting closer to the tru…

@VMtest, Personally I think these discussions are interesting as a small part of learning and reading about hiring and recruiting.

@baobabKoodaa

> if you assume people never change their opinions as the result of arguments, then I suppose people gain nothing by arguing

One thing: they can slightly learn how others can react to what they say, and thereafter, in real life, better know what to say, or not.

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

#702

Earlier quoted context omitted.

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

I also regularly give a quick peek to the comments sections before reading the article in order to figure out whether I should bother reading.

Sometimes it works, sometimes it doesn't

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

#703
post #495

Earlier quoted context omitted.

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

If you re-read the comment with the assumption that they were not trying to (mis)represent the author, it still makes sense, so I don't think that was the intention.

There is even a name for that: https://en.m.wikipedia.org/wiki/Principle_of_charity

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

#704

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 think that people should ask whatever they want to ask. If the interviewer doesn't like it, then it's not a good fit.

For example, I would never agree to an interview if I don't know the pay range. I'm not going to sit through 5 interviews to make $30,000-ish when I am expecting $90,000-ish.

I don't want to go to an interview if the company has less than gold level insurance.

No way am I going to wait until the last interview to broach the topic, I don't care what is standard.

If I apply to a job, I call up the department and say that I am considering applying for the job, but I want to know about x,y, and z first, because I don't want to waste either of our time.

If they push back and say that we don't give out that information, then I just say, "I understand. I also don't give away my time, in order to find out after 15 hours of interviewing for your company that you want to pay $40K and I expect $80K. All the travel time, parking, preparation - why do it if there is a complete mismatch of the most basic things? Maybe you can bring this up to management, that your policies are not realistic. Good luck, hope you find a candidate." And then just hang up.

Now, I know this wouldn't work in a huge Fortune 1000 company. I work in small- and mid-sized companies where pretty much I can reach decision makers. I don't know what I'd do in a large enterprise company. I guess that is why I would never apply to one in the first place.

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

#705
post #594

Earlier quoted context omitted.

I imagine it's really hard for employers to balance that, though. A good employer wants employees to take the time off they need without worrying about running out of PTO to do the stuff they want. They don't want an employee to ever have to think "Shit, if I take that day off for a dentist appointment, then I won't have enough PTO for that weeklong trip to Hawaii!" But if you try to avoid this scenario by being extr…

I guess to someone in the US, 8 weeks sounds like a lot. But, especially if you consider holidays and sick time, 6-8 weeks total over the course of a year doesn't seem unreasonable. I've been in that range for total nonweekend days off for much of my recent career.

I don't include holidays in that total.

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

#706

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

I mostly express opinions about things than affect my productivity. I don't care about npm vs yarn. It doesn't affect how I work. But I care a lot about not having excessively firm lint rules because they slow down my coding.

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

#707

Earlier quoted context omitted.

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.

Appreciate this response. Thanks. Totally agree now that I see your perspective.

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

#708

Earlier quoted context omitted.

> It's as if the notion of people being arbitrarily born more or less with a knack for something is evil. The stretch from person A is a better programmer / SW engineer than B to 'thus, person A is innately better' is unnecessary. In my experience, the programmer that spends more time programming is almost always better than the one who does not. You can hate side projects, open-source work, whatever as much as you w…

I’m not sure if you described 10x people or one-track minds. I love programming, I’m good at it, but what I do with my free time isn’t necessarily related to programming but is still definitely productive. I read up on economics, politics, maybe write a few essays or short stories, work out, pick up a new skill or something. Somehow being a holistic person is now considered mediocre?

Those with one track minds tend to excel specifically at the one track they dedicate themselves to while failing at other things. There are also those who are good at many things. Both have valuable skills (and both are actually well compensated and highly necessary for companies, IME). But if you want to be that guy who can just crank out code for any problem, then I believe this ability is based on the amount of time you've spent coding, which, for those who have one-track minds, is naturally going to be a lot more than the average programmer. It takes all types. There is no value judgement in my descriptions.

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

#709

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…

I experienced people who are 10x better than me through Google codejam.

I looked at one of the problems of the final round, looked at the solution, read it for hours, and I couldn't implement it correctly.

Then, there are these top 3 who came up with their own solution and wrote correct code within 20 minutes.

For comparison, I can consistently be in the top 1000 of Google codejam. So, I consider myself a fairly good coder.

I experienced this with topcoder as well. There are some people who are way too smart.

10x programmers and engineers are very much real. It is just rare.

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

#710
post #220

Earlier quoted context omitted.

Realistically, I’ve always found it a weird sentiment more because issues caused by software developers are not of the “this person is 1/10 as productive as this other person” type. A bad developer isn’t a low positive effect on a project, but an active negative effect. As such, you can put literally any Y for a (Y)X programmer, since the scale of how inefficient a programmer can be goes up to infinite. I think the p…

More people should be aware of Comrade Stakhanov, the "10x miner": https://en.wikipedia.org/wiki/Alexey_Stakhanov > In 1988, the Soviet newspaper Komsomolskaya Pravda claimed that the widely cited achievements of Stakhanov were puffery. The paper insisted that Stakhanov had used a number of helpers on support works, while the throughout was tallied for him alone. Still, according to the newspaper, Stakhanov's approac…

Yes attribution can be hard.

At the same time, if one compares shoveling coal and laying bricks with software, then it'd be good to smash and destroy bricks, throw the coal back into the mine, raze houses. (Reducing the amount of code)

Software would be more comparable to designing the coal mining site, or architecturing a city (but not building it). And then maybe it's simpler to see, that individuals sometimes can have much impact.

Post reply on HN