Live data from Hacker News

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

simplethread.com

681–690 of 745 posts

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

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

It depends a lot on the company in the US.

If we're including holidays, I've seen plenty of companies that do 4 weeks PTO + 8-9 holidays which is just shy of 6 weeks, and there some that do 5-6 weeks PTO after you've been there for a number of years.

But there are also ones where you basically get no PTO. Presumably (hopefully?) you get paid more money to work at these places, but I've never found them worth investigating.

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

#682
> Good written communication is one of the most important skills for any software engineer to master.

But there is no "mastery" -- lifelong effort is required from all of us, especially to avoid falling into fashionable bad habits of the moment propagated so vigorously by our social media.

> ... good of a team member ...

"The word 'of' often intrudes where it does not belong, as in 'not that big of a deal'"

- Garner's Modern English Usage, 4th edition, page 647.

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

#684
post #184

Earlier quoted context omitted.

I do a lot of dev work with non-profits and such. About a year ago I was working on an extremely difficult project as a volunteer where I was insistent that a specific part was vitally important to getting the project to move forward (generalizing tables extraction from scanned OCR docs) and I was spending a lot of time on it. One of the devs I worked with, with 40+ years of experience, basically told me this exact t…

Predicting the future is hard. You were both right. You only have the outcome to judge the decision, not the full probability distribution.

This is so important - it's so hard to gauge what another person's mental model of a scenario is compared to yours.

As in - perhaps OP and 40+ year person had the same, accurate mental model of the probability distribution of success, but OP and 40+ had different attitudes towards risk/reward.

Or perhaps the OP happened to have a much more realistic picture of the probability of success, and 40+ was unnecessarily pessimistic.

So hard to evaluate these things, and to internalise the fact that other people don't have the information you have all the time.

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

#685
post #6

This is a very insightful list. But there is one thing I'd quibble with: while it's inherently a super-subjective metric, I would say that 10x programmers do exist. Both in the "can support a company by themselves" sense and the "mad lone genius" sense. Not all the 10x programmers are good at working with other people or on other people's ideas. 0.1x programmers are often lost or afraid, although they may just be uni…

Maybe 0.4x and 3x programmers exist, and so when you introduce a little noise it's easy to perceive as a 10x difference at certain points in time.

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

#686
post #269

Earlier quoted context omitted.

A corollary-ish observation of my own: * If coders could write useful documentation (starting w/inline comments) they probably wouldn't be coders.

What would they be instead?

Communicators. (Writers, marketers, teachers, ...)

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

#687
post #617

Earlier quoted context omitted.

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

Even if they have "no input", if the interviewee did or said something really extreme it would be reported back.

Maybe, but taking the time to talk to hr means it would be awful before someone would go through the effort.

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

#688
Thanks, love the post. I agree with everything you said. Recently, I was in an interview for a company and they gave me three requirements for a versioning tool I should design conceptually. I started with the data models and then the backend / frontend communication. I wasn't told who this versioning tool should be for, how many people would use it and other important domain related things, so I said I'll concept a simple solution that would work fine for a group of people but would have to be refactored if we'd want to scale up and support thousands or more connections simultaneously, I was told "sure, go for it".. Once I finished I said that I was confident that a versioning tool has way more complexity and requirements than described initially within those three sentences and that 60 minutes to design such system in a stable way is optimistic.

A week after the interview I was told that they don't want to continue with me because I didn't ask enough questions and that my solution wouldn't work if millions of people would use the system at the same time. I think I avoided a bullet

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

#689

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 also put off from the article by the quote, but that's on me, not you. The article was great and I agree with everything in it.

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

#690
post #195

Earlier quoted context omitted.

To clarify, you're saying that you vire that that being technical and observing natural/physical phenomena are important parts of selling clothing at retail, being a novelist and working as a receptionist? I think those are important jobs, and completely disagree with you. I'm trying to understand if those are jobs you weren't considering, or if we view each the responsibilities of those jobs very differently.

No. I'm saying that retail, much like being a novelist or a receptionist or a software programmer or indeed any job is, as the OP puts it, a "social service". That being one of the defining charactetistics of a job.

You're saying you're agreeing with OP, but your statements contradict.

OP calls out 3 categories of jobs. Mainly natural/technical, mainly social, and those which sit in the middle and require both. Finally OP says engineering sits in the middle and requires both.

You said it's not just engineering (that requires both), but all jobs.

Both I and OP disagree with that statement.

Post reply on HN