Live data from Hacker News

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

bti360.com

31–40 of 371 posts

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

#31

This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…

Yes. The challenge is how to measure individual contributors. It’s easy in Sales, which is why salespeople can do very well without being managers. Harder with engineers, whose work is very interconnected.

For sure. And it's why frankly in my opinion it's very hard to scale software development effectively beyond 25-50 engineers. After that politics and faux-meritocracies take over as people lose personal touch with each other.

Not that small companies can't be hell, too.

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

#32

This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…

Expecting a talented software engineer to "upgrade" to become a manager of a development team makes exactly the same amount of sense as expecting a talented accountant to gain a bit more skill and suddenly become a lawyer.

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

#33

This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…

Expecting a talented software engineer to "upgrade" to become a manager of a development team makes exactly the same amount of sense as expecting a talented accountant to gain a bit more skill and suddenly become a lawyer.

It might be closer to a pro athlete retiring from playing and going into coaching, but not so many would be good in that role.

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

#34
post #23

Stuff I'd add that I think is crucial, and all related to one topic: good writing! 1. Learn to write specs Call it an RFC, call it a PRD, call it whatever. Writing out a plan for any project taking around a week or more is always worth it. Use it to establish scope and priorities. Keep a "Questions" section that you whittle away at as you seek out feedback. Make the body a hierarchy of design tasks and implementation…

Do you happen to know of a properly written (publicly available) spec? I'd love to see a good example.

I've always found the OAuth 2.0 spec [0] to be well written.

[0] https://tools.ietf.org/html/rfc6749

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

#35

Earlier quoted context omitted.

professional interview sign seen at the "interview desk" for work placement at an expensive school for digital creatives: "sit up straight; look the interviewer in the eye; wear presentable clothing; answer the questions asked of you" .. I believe the sign was there because that was not occuring in many cases !

My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality. Maybe it's different when you interview at a FAANG company though? I imagine FAANG recruitment is a merciless sausage machine.

> My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality.

I'm growing further and further away from this mentality in hiring because the sad truth is most of those folks who come in with "quirks" lack maturity. To me, quirks are "yellow flags" in the interview stage because it means that you're not able to put your own weirdness aside to fit socially when you arguably need to the most. Invariably these same "quirks" come up down the road in the employment with output problems, copping attitude with superiors, weirdness in internal/external meetings, and just general antisocial behavior.

I get that we're all in hella demand right now but I'm starting to go back on my, "I'm just hiring for the engineering skill/talent" as an excuse to overlook yellow flags.

The other thing is contextually, what are the quirks? If the "quirk" is someone being super shy/timid it doesn't even register on my radar as a problem unless it's extreme... I'm talking about the stereotypical "oh so cute dev quirks" like: not dressing appropriately for an interview, interrupting me/talking over me, talking down to me, comparing their last junior position to being Steve Jobs, being sing-songy, inappropriate jokes in any way/shape/form, getting in arguments with themselves... etc etc.

I'm at a point that if you can't act 95% professional in your first interview you're done as you're not capable of being "on".

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

#36
post #15
post #8

> Computer Assisted Software Engineering (CASE) tools, COTS, Enterprise Resource Planning products like Peoplesoft and SAP and, yes, even Ruby. They claim amazing reductions in cost and time if you buy into their holistic development philosophy. What is not always as obvious is the significant up-front costs or the constraints you may be committing yourself to. Lock-in used to primarily happen with vendors, but now i…

Is it not? Even if it's open source, I would view monolith frameworks as a form of ecosystem lock-in. We use Spring at work and I would certainly describe us as suffering from "lock-in" to the Spring ecosystem.

In which case are you not going to lock in building something like that?

Even if you opt to go framework-less you are now locked in to whatever you are building.

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

#37

Earlier quoted context omitted.

professional interview sign seen at the "interview desk" for work placement at an expensive school for digital creatives: "sit up straight; look the interviewer in the eye; wear presentable clothing; answer the questions asked of you" .. I believe the sign was there because that was not occuring in many cases !

My experience from being on both sides of the desk has been that devteams are relatively tolerant of candidates exhibiting personality quirks during the interview process - it's the candidate's skills that are in demand, not their winning personality. Maybe it's different when you interview at a FAANG company though? I imagine FAANG recruitment is a merciless sausage machine.

I would agree although sometimes this is a little too much. I have seen instances where they solely focus on the skills and end up hiring jerk. Ultimately, that causes way more trouble than a weak skillset.

An interesting experience I had at a previous company was that they really put culture almost above all else. It sounds great, but in all honesty it was actually depressing and horrible after a while. It almost always came down to, "Well we don't want to hire X person, because it's not a good culture fit." The real issue was that they wanted to hire people they could hang out with / mold into their way of thinking. No new ideas, and everything pretty much stagnated. If that's what you were looking for, then it was great, but people who think like that aren't typically the ones that can hit the homerun when you need to.

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

#38

This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…

Expecting a talented software engineer to "upgrade" to become a manager of a development team makes exactly the same amount of sense as expecting a talented accountant to gain a bit more skill and suddenly become a lawyer.

There are other paths at Google than upgrading to mgmt, but all of them involve "cross-team collaboration" and other quasi-political (with a small-p) aspects.

Actually just writing code at Google is, from my experience, a small part of the job and not rewarded. The faster you get out of writing code and get into designing and delegating it, the better you're off. Sucks if you don't like it.

Coming up with a way to reward and improve nose to the grindstone technical contribution seems to me key to having an effective organization.

EDIT: also consider, doing management or team lead at a company like Google is so different from, say, a small company, that the trajectory may make no sense for somebody. Before I came to Google I felt myself on a career track that was team-lead/architect focused, mgmt interest, etc. Once I got there, that evaporated. I just couldn't imagine myself doing that kind of work in this large of a company.

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

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

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

#40
post #9

Cool article. That suit...that hair... He doesn’t really deliver any “wise mountaintop guru” stuff, though. Just shows that good old-fashioned common sense is timeless (and distressingly rare).

I have gotten a lot of advice but sage wisdom is rare. The closest I can think of is: “Expertise isn’t coming up with the perfect solution, expertise is knowing you can get a good enough solution on time.” Frequently you have a fast but risky option and a slow but guaranteed one. It’s fine to work on the fast option, just remember to abandon early enough to still finish in time.

i can't remember where i read it but "engineering is the science of good enough" has always stuck with me.

I'm reading Algorithms to Live By and the section on explore/exploit feels relevant here. At what point do you stop looking for new things and rely on the things you already know. lol I feel like i lack the IQ to connect all the dots but there's something applicable in that section to this discussion. maybe i should re-read it...

Post reply on HN