Live data from Hacker News

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

simplethread.com

541–550 of 745 posts

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

#541

Earlier quoted context omitted.

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

I don’t have to maintain a facade. Most companies don’t actually give a hoot if you buy into the CEOs blabberings. They care if I can get my tasks done on time and with decent quality. It’s all a part of the Gervais principle

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

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

> sometimes Any rule of wisdom, followed blindly, leads to disaster. Don't substitute rules for good judgement.

If we take your first statement to be a "rule of wisdom" then it is either false, or all roads lead to disaster anyway.

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

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

That is not how quotation marks are designed to work.

The words offered up as a quote are meant to represent the views of the person being quoted. In this instance that is clearly not the case.

This is a perfect example of how quotes can be used to misrepresented a view.

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

#544

Earlier quoted context omitted.

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…

> 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 wrong, they would still mention it to someone. So I stuck to really superficial topics.

Then I got hired and later served as a lunch escort. Now knowing the process and knowing there truly is no input, I tried to convince the interviewee, and he didn't seem to believe me just like I didn't when I was in his shoes.

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

#545

Earlier quoted context omitted.

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

I pretty much hate policies that require you to take PTO at specific times. They're almost never the times I would choose to take on my own and are often at times it's difficult to combine into a longer trip.

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

#546
post #487

Earlier quoted context omitted.

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.

A sin or lie by omission requires intent, and the OP stated their intent was not to misrepresent the author.

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

#547

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

Very few recent programs i've seen were socially useful. Some might find comedy in this but the app my current gig uses:

- is un ergonomic and redundant (typing the same thing over and over, no keyboard shortcut jquery era procedural code)

- the overall design is useless, it produces libreoffice templates that takes ages to be badly filled

- secretaries go faster using fucking paper and filling everything by hand

- the application has all the data at hand but nobody has access to stats or complex queries, people have to also write down stats with stick marks on paper so the hierarchy knows what's going on

alas

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

#548

Earlier quoted context omitted.

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

I don’t have to maintain a facade. Most companies don’t actually give a hoot if you buy into the CEOs blabberings. They care if I can get my tasks done on time and with decent quality. It’s all a part of the Gervais principle

You're right, but people know that someone interested in the work is likely to do a better job. Also, my point is about selling your ability to solve the company's problems rather than focusing on "what do I get".

Besides, why not pick a career that interests you? It makes for a better life.

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

#549
post #184

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

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…

minuscule anecdote: my most cherished lines of code were an 8 lines vba excel macro to count duplicates for a non tech colleague.

Turned her day from hell to cool (she had to filter duplicates by hand and quadratic formulas over 2000+ lines spreadsheet.

That's what computers are for.

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

#550

Earlier quoted context omitted.

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…

You are misunderstanding the definition. A 10x developer does not write code ten times faster than average. They have ten times higher impact on the results of an organization than average. And that's not far-fetched at all. This does not magically happen. There are individuals behind it, often a surprisingly small number doing the critical work that visibly brings the world forward.

It's not about writing a regular boring CRUD app that no one cares about as fast as 10 regular developers. It's about choosing the right problems to solve on their own initiative, building the foundation of a technology organization that can sustainably & quickly grow in scope and users, being the first to solve a problem no one else has understood such that the organization crushes their competition and so on.

Leading the development of web software that scales to 100 million users in 2003. Planning novel computer vision algorithms to a vehicle fleet of millions of vehicles, running on custom hardware they've also made contributions towards. Realizing that consumer VR headsets are now _just barely possible_ if you do everything right, and bringing it to market. Etc.

This is the difference between a small organization being capable of solving a difficult business problem and achieving profitability, and not.

Post reply on HN