Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bti360.com

Post reply on HN
Print view View original

71–80 of 371 posts

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

#71

Post by noisy_boy »

davidhyde wrote: post #60

> “ When you know something it is almost impossible to imagine what it is like not to know that thing. This is the curse of knowledge, and it is the root of countless misunderstandings and inefficiencies.” A few months ago I came across an interesting actively developed project in embedded rust which was very technical. Full of acronyms and concepts that I was not familiar with. It took quite some time to get up to s…

I think they are doing themselves a disservice by ignoring something that elevates overall understanding, ease of onboarding/troubleshooting and generally, the polish, of the project. I love documentation and usually manage to set aside time to add details in the README/wiki etc. It is a great way to share details with others and myself, six months down the line, because I don't have a super sharp memory.

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

#72

Post by mathattack »

cmrdporcupine wrote: post #31
mathattack wrote: post #29

Earlier quoted context omitted.

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.

Yes. Most good people know who the other good people are, but it’s hard to turn that into a plan fit for large companies.

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

#73

Post by mr-wendel »

e-_pusher wrote: post #65
yarinr wrote: post #23

Earlier quoted context omitted.

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

The operation manual of the original IBM PC from 1981 is a very good example. Personal plug: I wrote an article about writing specs a while back. I use the IBM PC spec as an example, so you might find my article useful. https://iskender.ee/2020/06/18/EE-Specs.html

"What even is a good specification, or the Huaqiangbei test"

Those three points are pure gold!

I'd also add that you don't need to be working on a major project to benefit from standing back to writing it out first. Much of what I write is just a few pages, but it's still useful. It saves time overall, helps others get up-to-speed fast, and is fun!

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

#74

Post by lrossi »

marcinzm wrote: post #21
lrossi wrote: 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…

>Not much real advice on the behavioral side, to the point that people often take trainings for behavioral interviews and memorize “leadership principles” and other nonsense. This is what FAANG interview generally look for so why is it a surprise that potential hires focus on it? Amazon literally says that you need to highlight all the leadership principles in the stories you tell when answering behavioral questions.…

Do you know why Amazon is focusing so much on the Leadership Principles questions, yet there seem to be so many horror stories from people who work there? I am genuinely curious why they don’t manage to filter out the jerks.

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

#75

Post by kmclean »

yarinr wrote: post #23
mr-wendel wrote: post #16

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.

Not sure this is exactly what the commenter had in mind, but I think of Clojure's "design rationale" documents as good examples of thinking through a problem before executing. This is one for the language itself, but there are loads of others out there for other sub-projects.

https://clojure.org/about/rationale

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

#76

Post by cletus »

cmrdporcupine wrote: post #19

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

> As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs.

So I have to ask: do you or have you worked at a FAANG with these systems? I may be wrong but I suspect you haven't, particularly if you're equating them with more traditional hierarchies.

The whole point of a system like this (and I have direct experience at Google and Facebook) is so you can go pretty far as purely as an IC. You're not forced to become a manager.

So at Google for example, new hires start as a T3 (T4 for PhDs). There is an expectation for growth up to T5, meaning technically you are meant to progress over time. When I was there this wasn't strictly enforced (eg I knew people who had been T4 for 5+ years) but it may vary from PA to PA or manager to manager and it may well have become stricter.

IIRC the general guidance was 2-3 years T3 to T4 another 2-3 years for T4 to T5.

At that point you can sit at T5 forever if that's what you want to do. People's desire to get promoted leads them to becoming managers because it is demonstrably easier to promoted from M1 (T5 equivalent) to M2 as en EM than it is from T5 to T6 as an IC.

These higher levels are really an indication of your organizational and technical impact and for this you really have to influence others. This is not being a people manager however.

But the point is that there's no "up or out" (beyond T5) like you may find at IBM or KPMG.

Now there are definite issues with Google's approach here and that's really a whole other topic. I just don't think your observations here adequately describe the FAANG career paths (IMHO).

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

#77

Post by skrtskrt »

karmakaze wrote: post #64
bradstewart wrote: post #50

Earlier quoted context omitted.

I wonder if team size has anything to do with that. Football teams are much larger than those in other sports.

Also the division of roles is far more specialized than say basketball. Only the QB might have a near/full picture.

Linebackers, as the captain of the defense, which requires a deep understanding of the offense as well, tend to end up coaching as well.

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

#78

Post by cmrdporcupine »

mcguire wrote: post #68
cmrdporcupine wrote: post #38

Earlier quoted context omitted.

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

Over the course of a number of years and a few jobs at IBM starting in the early 90s, I knew 2 people on their "technical track". Their jobs involved huge numbers of airline miles, continual meetings, and essentially no technical work. That was one of the primary reasons I stayed a contractor most of my career.

Interesting that your contractor jobs haven't also filled with non-technical, biz type work? Lack of desire to deal with accounting, client meetings, all the organizational aspects of running a business have kept me away from contracting or consulting.

Might be time for me to revisit that, this being the year when I really think I need to start something new. I have no idea how to make that switch though.

Are you contracting through your own business, or someone else's?

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

#79

Post by cmrdporcupine »

cletus wrote: post #76
cmrdporcupine wrote: post #19

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

> As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. So I have to ask: do you or have you worked at a FAANG with these systems? I may be wrong but I suspect you haven't, particularly if you're equating them with more traditional hierarchies. The whole point of a system like this (and I have direct experience at Google and Facebook) is so you can go pretty far as purely a…

> So I have to ask: do you or have you worked at a FAANG with these systems?

Yes, 9 years at Google. But yes, not experience beyond the L4/L5 tier.

It is true that the IBM type structure isn't the same, and yes, Google is fine with you staying around L5 forever (well, L4 now). But the matrix of things to get beyond L4 really is, in the grand scheme of things, about moving beyond development and into delegation, or at least ownership. It's not management, but it is about leadership/cross-team collaboration and "demonstrating impact" to others. So, like I said elsewhere, small-p political.

At least that's my experience from seeing the L4 to L5 transition. But it may also be a product of my smaller office, where the number of projects is smaller, team size is smaller, and larger technical contributions of impact are harder to find.

EDIT: Also I've seen a lot of change in the 9 years, in terms of how the organization as a whole behaves, and it is becoming more and more like a traditional BigCorp. I just checked percent/ and within engineering 86.43473% full-time employees are newer than me. And a lot more if you count non-engineering. It is a way larger company than I started in.

EDIT2: I should underline, that the perf/promo process obviously works for a large, perhaps the majority, number of people. But it doesn't for all. It requires adapting to an organizational model that not everybody accords with. And I think that's in the spirit of the original topic: organizational structures / procedures that become your career goals may not make you happy, so find a company whose process matches what you want to get out of life. Or try.

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

#80

Post by mattmcknight »

lrossi wrote: 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…

> they tend to focus on which stacks matter

This is not just a junior problem. A lot of "people problems" seem to come from fighting over which stack to use. (and most people fight for whichever stack they are best at, to maximize their own personal contribution). I always spend a lot of time asking people what technology they would use to solve a particular problem, what technology they really don't like, etc. It saves a lot of trouble fighting over things if you get a team that is willing to go with a particular technical approach and is more important than most "cultural fit" issues.

Post reply on HN