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

191–200 of 371 posts

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

#191

Post by watwut »

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…

If you are junior you would make mistake to ignore technical aspects of work (stacks, what to learn, how to develop, deploy and maintain) in order to focus on communication, trust, teamwork, documentation, clarity. While communication is somewhat important for juniors, but usually the technical aspects are even more missing. It is when you have technical aspects down when the other aspects start to matter more.

Also, juniors are not in political situations where the other aspects matter all that much. Generally, they find themselves in simply political situations. As long as they are not downright toxic, it is ok.

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

#192

Post by closeparen »

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…

The senior IC ladder saves you from being responsible for people, their job satisfaction, their career progression. But it is still a kind of management.

Facilitating meetings, reviewing documents, tracking schedules, reporting progress, convincing teams to prioritize the work, negotiating with those challenging the technical decisions, securing credit, deflecting blame, getting resources, etc. The model of an effective L6 or L7 IC is part secretary, part Frank Underwood.

You're right that you don't have to pursue L6/L7, but L5 is attainable in < 4 years. No 46 year old wants to be doing the same thing for the same pay as a 26 year old.

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

#193

Post by withinboredom »

kstenerud wrote: post #129
noir_lord wrote: post #90

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…

I've been bitten by this. I once worked at a place where the development process for the Windows version of their product was GLACIAL because there was no way to run the CI scripts locally or even set up a dev environment that could build the product. People actually edited code in a text editor and then submitted it to github and waited an hour for the CI job to build a virtual Windows instance, run updates, install…

I lived almost the exact same story. Except when I was fired I was told to go work at a bigger company. So I did.

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

#194

Post by closeparen »

wool_gather wrote: post #111
cletus wrote: post #76

Earlier quoted context omitted.

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

> new hires start as a T3 This makes me curious about what T1 and T2 would mean.

Blue collar IT. Racking and stacking, help desk, event space A/V, wrangling desktops and phones, installing WiFi access points in the office, etc.

Tech companies don't pay particularly well for these things, but their benefits packages are very competitive.

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

#195

Post by ncmncm »

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…

Before you put a lot of work into something, it is a good idea to check if it is welcome. Nothing sucks up enthusiasm quite like blank rejection.

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

#196

Post by astrobe_ »

trentnix wrote: post #58

3. Simplicity Fighting complexity is a never-ending cause. Solutions should be as simple as possible. Assume the next person to maintain your code won’t be as smart as you. When you can use fewer technologies, do so. This is the one I appreciate more and more as I age. Because frequently, I'm the next person looking at my own code. And there's no better gift to your future self than well-written, easy-to-understand c…

I somewhat disagree with the way he connects simplicity and cleverness.

I once had to explain the behavior of a particular subsystem. It was governed by a bunch of simple rules, but their combination created a complex behavior. This was similar to social insect colonies, where components (eg. ants) are driven by relatively simple rules, but the whole system exhibits remarkable "emergent behavior".

What takes cleverness is to anticipate, predict, understand,explain the global complex behavior from the simple rules. If someone can predict what comes out from cellular automatons like in the game of life, I am amazed. Simple is not easy (no, sorry Rich, following your simple advice is not that easy either). Simple is not always easy to understand, even less so easy to do. That's why complexity tends to accumulate.

At the risk of being wronged, I would say that being comfortable with complexity is a form laziness. I belong to the messy type of person. I believe I am that way because I can rely on a good long term memory: because of that, I can yield to laziness and not put away things where they belong when I should. Being able to handle complexity is a great quality, but not being discomforted by complexity is like not being ashamed by your messy home.

When you make the effort to really simplify, under the favorable circumstances (like in hobby projects, where you can afford to move goalposts a bit), you can make complexity collapse - not by its own weight, for once. I understand that the author emphasis teamwork and communication so he gives this kind of John Wood's "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live" justification for fighting complexity, but preventing complexity from collapsing by its own weight, crushing a product in the process, is to me on equal grounds.

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

#197

Post by cletus »

wool_gather wrote: post #111
cletus wrote: post #76

Earlier quoted context omitted.

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

> new hires start as a T3 This makes me curious about what T1 and T2 would mean.

The SWE (Software Engineer) ladder doesn't have levels below 3 (AFAIK). Other ladders do.

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

#198

Post by ralphc »

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

I was 33 years in the industry, as a developer. Some times I considered going into management, and was asked about it, but fairly early on I realized I would hate it and it would hate me.

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

#199

Post by Viliam1234 »

mattmcknight wrote: post #80
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 sa…

In my experience, this mostly happens with people who only know one technology. Many juniors are like this. On the other hand, when this happens with a senior, they fight extra hard.

I suppose it also depends on company culture. What happens if a technology you have never seen before is selected for your project? Are you given some time to learn and is it expected that your initial contributions will be smaller, or are you supposed to be just as fast as people who used it for last ten years and get negative reviews otherwise?

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

#200

Post by cletus »

mosdave wrote: post #133
wool_gather wrote: post #111

Earlier quoted context omitted.

> new hires start as a T3 This makes me curious about what T1 and T2 would mean.

I'm more curious about why a new hire with 20 years of experience starts at T3.

Yes, sorry, I worded that poorly. I really mean "new graduates (non-PhD)" not "new hires". Apologies for the confusion.
Post reply on HN