Live data from Hacker News

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

simplethread.com

461–470 of 745 posts

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

#461

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

I think time off is very important, but you don't need to ask it during the interviews. Just wait until they give an offer and then ask for what you want.

Nah, just like salary, I'm getting a ball park range on that topic before bothering to come into the office for an interview. Otherwise, you're wasting other people's time and your own.

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

#462

40+ years of experience here, and I'll tell you the #1 thing I've learned: * Software is a social service. Its for other humans. Incredibly, it doesn't matter how educated the developer, they still seem to have to learn this lesson themselves, over and over, until it sinks in...

The biggest mistake people in our industry make is thinking they are somehow exempt from the rules of society and business just because they can use a computer better than most people.

Heads down genius coder everyone steps around ends up fired or stuck in mid level forever, in reality. Guy who makes friends with the Customer Service department and Sales team with mediocre fixes get promoted, and in reality achieves more with his career.

Software is useless without users.

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

#463
post #429

Earlier quoted context omitted.

Like it or not, when interviewing for a job, you're doing a sales presentation. A good sales presentation doesn't open by saying what you want. It opens by finding out what the customer's problems are, then you demonstrate that you can solve them, then when the customer is sold the price negotiation starts. If you want to vet a company's benefits and culture beforehand, which is a good idea, do the homework first and…

> Like it or not, when interviewing for a job, you're doing a sales presentation Maybe in the 90s. Nowadays it's becoming very balanced in the way that companies are the ones who are doing a sales presentation as well.

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 for the company. I recommended no hire.

After all, what would you think if you went to a car dealership and their salesman would only talk about how much you had to pay and how much the dealership wanted your money, and never talked about what the car would do for you?

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

#464

Earlier quoted context omitted.

I think that depends on the context in which you’re working. Flashes of genius don’t have much place an an enterprise code base. Everything is rigorously standardized and separated into layers. Each layer has a bunch of bookkeeping about dependencies, interfaces, mocks, expectations, and test cases. This is not really brain work; it’s typing. Now maybe if you’re really brilliant, you’ll do much better than average wi…

So the 10x programmer realizes you can accomplish the same goals with 1/10 of the book keeping, dependencies, interfaces etc. etc. etc. In other words, the processes themselves place hard upper limits on the possible productivity.

One could make the argument that skipping the bureaucracy catches up with you in the long run.

Or maybe a small team of 10x programmers could really get away with it, indefinitely. But can you reliably staff enough of them, now and forever, to keep that going? For a business it is often better to have a codebase that scales with arbitrarily many average-quality engineers, than to be dependent on hiring miracles. Even small numbers of them.

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

#465
post #457

"1. I still don’t know very much" I've been in the game for almost 30 years. I often feel like I know less than I thought I did 25 years ago, and that I know less as time goes by. I'd also have this as my #1 on the list because it just feels so surprising. I think most of us start out in our 20s thinking that in 30 years we'll have mastered the field, but it definitely doesn't feel like that, not even close.

The domain of software engineering has almost certainly increased in size and complexity faster than any of us have learned. We must focus on the fundamentals. All of the new languages and architectures are a storm hovering over a bedrock of empirical computer science.

It's not just all the new stuff that's emerged in the last 30 years. I feel like I didn't really understand a lot of the fundamentals like I thought I did back in my 20s and that there were some major holes in my education that only became apparent after some years of experience in the field. Often you don't know what you don't know. I now know there's a lot I didn't (and don't) know and I think that's a valuable thing that mostly only comes with experience.

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

#466
post #313

Earlier quoted context omitted.

This is especially true if the company uses "unlimited"/not-tracked/etc. time. Otherwise, unless you know someone at the place (and even then it can vary by group), you're left with making assumptions about norms that may not be accurate. Personally, I've never not used all my PTO in a given year and would consider being unable to do so a show stopper.

I really like the policy of "minimum mandatory time off" some companies have. That makes a big statement about where their priorities are in terms of care for their employees' well-being.

The company I'm at effectively has that as part of their unlimited PTO policy, though the timing is company-mandated, being the first week of August and the week between Christmas and New Years, which is a week so many people are likely to take off anyways, it just makes things easier to make everyone take it off.

Going into the week off in August, I wasn't sure how seriously they took it, but sure enough, I didn't get a single e-mail that week other than weekly reports from automated tools. I even checked Slack that Friday, and there wasn't a single message except for the channel where people post pictures of fun stuff they do over the weekend.

It was pretty nice.

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

#467

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…

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

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

#469

Earlier quoted context omitted.

I think the "10x programmer" as a term is confusing. In one analogy it could be the 10x bricklayer. One who does a well defined job 10 times faster than the others. I think this is the notion people oppose. Another analogy is the 10x classical composer. A person who produces music that is 10 times better music. But this is much more about creative/artistic capacity than about producing. Nobody oppose this. I that you…

> In one analogy it could be the 10x bricklayer. One who does a well defined job 10 times faster than the others. Software as brick-laying gets a laugh out of me. If someone uses that analogy, that's a red-flag: they don't really understand software (and tech). It's like offshored bodyshops that just keep throwing more warm bodies at a codebase. Truth is, a 10x isn't someone who lays bricks 10 times faster. A 10x is…

I think this is entirely correct. In this framework we wouldn't call it a 10x programmer, but a 10x thinker.

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

#470

Earlier quoted context omitted.

The context is key. First interview . The issue isn’t taking time off, it’s that the prospective employee’s head is up their proverbial ass. First interview is propspecting. If you were selling a product, if the customer is asking about the return policy before even selecting an option, it’s a similar signal. When you’re in a subsequent interview talking about the benefit plan, salary, etc, that’s where that sort of…

I find this line of thinking incredibly bizarre. If PTO is important to the candidate, why should they waste their time spending hours interviewing only to find out that the work-life balance in this position isn't going to work for them? To you that's having their head up their ass ? God that's strange to me. I'm sure glad I don't work for people who make sweeping judgements like that.

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.

Post reply on HN