Live data from Hacker News

What I’ve Learned in 45 Years in the Software Industry

bti360.com

271–280 of 371 posts

Re: What I’ve Learned in 45 Years in the Software Industry

#271

Earlier quoted context omitted.

What you're saying is important for everyone to internalize. I'll spin it like this: Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage. If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure y…

This is the party line. It misses that “a day’s worth of code” is highly unequal across individuals. The people whose “day’s worth of code” are most valuable, quickly get pulled off of spending their days that way. It appears that they key skill is coordinating a lot of developers, because the ones left developing are the ones you need a lot of (and who need close supervision) to get anything done. Managers will neve…

That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks.

Which is not to say they're doing everything right.

Re: What I’ve Learned in 45 Years in the Software Industry

#272

Earlier quoted context omitted.

It sounds like you're making assumptions in bad faith. I'm a SWE (i.e., not a manager) and I didn't read the comment at all like you did. On the contrary, I quite agree with it.

Well, as someone who has saved my company's ass multiple times to the tune of millions of dollars I think technical solutions are orders of magnitude more impactful and foofoo talk bullshit is incredibly limited. So I guess we will have to agree to disagree. Maybe noob coders "produce a day's worth of code" and that's all they can do, that's your perspective. I've sat through dumb two hour meetings about deciding whi…

> Well, as someone who has saved my company's ass multiple times to the tune of millions of dollars

Even though it sounds good, this is actually a bad measure because all coding consists of constantly making new zillion-dollar mistakes and then fixing them as you go. You can always do a worse job, and if we're supposed to be impressed by you visibly fixing something, then mess up and fix you will.

Re: What I’ve Learned in 45 Years in the Software Industry

#273

Earlier quoted context omitted.

I think what you're missing here is that the original comment isn't suggesting code doesn't solve problems when it counts. The thing is, developers often code things they never needed to. Or they code things off spec. Or they code things outside of the convention of what's appropriate for their immediate team or long-term needs of the product. The list goes on. Output could seem good for a long time before it becomes…

You have a very noob view of software engineering. You make a lot of generalizations about coders to support the theory that coding is low impact because coders fuck up a lot. Noob coders fuck up a lot. When I saved my company's ass those times, no non-technical people were present and it was wholly technical knowledge that solved it. I could have and probably should have ignored the problems and let the talkers try…

a) I never said coding is low impact, although I do believe software engineers make a lot of mistakes b) my generalizations are very common in software c) saving companies’ asses with code is not common d) I will never not be a noob

Re: What I’ve Learned in 45 Years in the Software Industry

#274

Earlier quoted context omitted.

This is the party line. It misses that “a day’s worth of code” is highly unequal across individuals. The people whose “day’s worth of code” are most valuable, quickly get pulled off of spending their days that way. It appears that they key skill is coordinating a lot of developers, because the ones left developing are the ones you need a lot of (and who need close supervision) to get anything done. Managers will neve…

That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks. Which is not to say they're doing everything right.

Having a tech track is the right direction.

Having no track even better. Some people like what they are doing and the field is constantly changing. You want your best surgeons doing operations not managing other doctors.

Re: What I’ve Learned in 45 Years in the Software Industry

#275

Earlier quoted context omitted.

L5 / "Senior Software Engineer" expectations are such that you have to have "influence beyond yourself", own some area of work, set technical direction for some other engineers. You're either a team lead or an "exceptionally strong individual contributor". It's not really that chill, and if you don't continue to do those things (lead or be exceptionally strong) that will show on your perf and therefore your compensat…

So are you basically describing stack ranking here? It's just impossible for everyone in a company to be a team lead, so not everyone can become that to become an L5. Which leaves the other option, to become an L5, which is to be an "exceptionally strong individual contributor" and being that "on an ongoing basis". Not everyone in a company can be an "exceptionally" strong person, otherwise it wouldn't be exceptional…

Two years is a long time to stay in one job. Two years is an eternity for a team's headcount not to grow. It's virtually certain that you'll be a mentor to several new hires in that time. You'll also have a long head start on understanding the codebase and tools relative to many others who will be working with them. If you're not some kind of leader at that point, something's wrong.

Unless you found one of those rare teams that stays together for the long haul, but the experience with such a special phenomenon should make it more than worth your while.

If L4s are not getting opportunity to lead, they are on a sinking ship anyway and the smart ones are LeetCoding.

(Obviously this all reflects the crazy economic moment of the last 10 years in Silicon Valley, but so does the level system you're critiquing).

Re: What I’ve Learned in 45 Years in the Software Industry

#276
post #274

Earlier quoted context omitted.

That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks. Which is not to say they're doing everything right.

Having a tech track is the right direction. Having no track even better. Some people like what they are doing and the field is constantly changing. You want your best surgeons doing operations not managing other doctors.

I think that would encourage not getting raises.

You need some kind of title so people can feel responsible for career growth and so you can calibrate against other companies' pay at least; it doesn't need to control what kind of work you're allowed to do.

Re: What I’ve Learned in 45 Years in the Software Industry

#277
post #39
post #6

Something that I find interesting is that career advice coming from professionals having many years of experience focuses almost exclusively on the people aspects and not the technology: communication, trust, teamwork, documentation, clarity. The advice is clear, precise and honest. This is the opposite of what you get from new hires/juniors: they tend to focus on which stacks matter, what to learn, how to develop, d…

Hum... maybe it's because they have so much technical expertise that they are able to have insights into other things? Technical knowledge is still very important, and it's the basic foundation of being a software engineer, and maaaaannyyyyyy people out there don't even know the basics.

plus, the people that feel the need to give advice are ones that are the ones that value [their own] soft skills more highly.

technical mastery advice doesn’t really need to be given at all.

i’m not saying the advice isn’t good, but also you have to read it like a self help book. it is a point of information, don’t take it literally.

Re: What I’ve Learned in 45 Years in the Software Industry

#278

Earlier quoted context omitted.

It's similar to the systems administrator dilemma. Do your job well, it looks you are not doing very much, why are we paying you? Everything is on fire, it looks you are not doing your job properly, why are we paying you? I've worked with a few engineers over my career like the person you described and frankly they are worth their weight in gold, been able to bank on their output working reliably and consistently ove…

> Fundamentally it's because impact is harder to measure than perception. Absolutely. Another nontrivial variable is the tendency for managers/team leads to get the "credit" for successful work, even if they aren't trying to. I've had managers before that did nothing but impede a high performing team. Luckily we delivered despite this. But it never failed, the manager would get accolades (often very public) for succe…

More important than any of the advice in TFA is: know when to leave. Most of my regrets are for staying someplace longer than was wise.

More about this: https://news.ycombinator.com/item?id=25663767

Re: What I’ve Learned in 45 Years in the Software Industry

#279

Earlier quoted context omitted.

This is the party line. It misses that “a day’s worth of code” is highly unequal across individuals. The people whose “day’s worth of code” are most valuable, quickly get pulled off of spending their days that way. It appears that they key skill is coordinating a lot of developers, because the ones left developing are the ones you need a lot of (and who need close supervision) to get anything done. Managers will neve…

That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks. Which is not to say they're doing everything right.

[deleted]

Re: What I’ve Learned in 45 Years in the Software Industry

#280
post #165

Earlier quoted context omitted.

It just occurred to me a sysadmin log would be very valuable: Installed update X to prevent risk Y Wrote script to advance process Z on input A Etc...

I ask my junior sysadmins / new hires to write a daily log for their first year or so. What did you do today? What do you need help with? What went well? What was frustrating? What should we change or fix? When we get together to talk about their day or their week, these logs are extremely useful. Sometimes they generate tickets, sometimes book or course recommendations, people to talk to, sometimes just conversation…

Nice. Seems like you are doing the work needed to bring them into things right.

I had a good mentor when I was doing sysadmin. Not quite as formal as this, but the conversations were similar.

Post reply on HN