Live data from Hacker News

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

bti360.com

51–60 of 371 posts

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

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

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…

Agree.

One of the most important skills is the one he describes like this:

>> The more specialized your work, the greater the risk that you will communicate in ways that are incomprehensible to the uninitiated.

In my experience (35 years), this isn't just about knowing the right way to describe things, it's also understanding what things to concentrate on when communicating, and what to ignore. If you are a tech person communicating with a decision maker, they are typically looking to understand options and their implications and risks, not the details of how the options work. They can then decide, based on their (presumably) better knowledge of the wider context, which options to select. If the decision makers are genuinely intelligent and motivated, but their eyes glaze over when you describe something, chances are you have chosen the wrong things to communicate to them.

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

#52

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

Having been employed at Google for about nearly two years, your take doesn't seem accurate at all.

> And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation.

The key feedback/suggestions I see for my own performance review is to define my impact on both the monetary and cultural success of my org. Exactly the opposite of what you are saying.

> being asked to 'level up' and told that this is your mission can lead to an unpleasurable career

I don't see this happening either. I commonly hear others say the opposite and make it known they are no longer trying to level up and that they are happy where they are.

> technical team lead to management or architect

This does not jive at all with the various career ladders I see. There is no ceiling that requires me to move to management in my tech ladder.

> find that you don't enjoy the new responsibilities

To some extent, the promo process levels up employees already working at that n+1. Sure, some may not want to maintain that, but that is ultimately up to the individual.

Disclaimer: I work at Google, opinions are my own.

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

#53

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

Having been employed at Google for about nearly two years, your take doesn't seem accurate at all. > And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation. The key feedback/suggestions I see for my own performance review is to define my impact on both the monetary and cultural success of my org. Exactly the opposite of what you are saying. > being as…

I also work at Google and in my 9 years there I've never had a perf process where monetary or profit-success goals of the company were mentioned once.

EDIT: I guess when I worked in ads, there were ad performance type metrics discussed to some degree. Not much though.

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

#54

Earlier quoted context omitted.

Having been employed at Google for about nearly two years, your take doesn't seem accurate at all. > And that reward / grading structure may not at all correspond to either the monetary or cultural success of a corporation. The key feedback/suggestions I see for my own performance review is to define my impact on both the monetary and cultural success of my org. Exactly the opposite of what you are saying. > being as…

I also work at Google and in my 9 years there I've never had a perf process where monetary or profit-success goals of the company were mentioned once. EDIT: I guess when I worked in ads, there were ad performance type metrics discussed to some degree. Not much though.

Goes to show how diverse a large company can be even with the same underlying processes.

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

#55
I loved the article! Thank you for sharing it.

Even if I am moving my first steps into the industry (I'm a simple trainee at a Tech-StartUp and MSc student) I've already experienced many times the first point. I think trying to keep your feet (and mind) on the ground, even when you have a huge expertise is fundamental in communication, teamwork and goals' chasing.

For example a friend of mine, graduated in one of the top programs in europe at Rotterdham Business School, has a huge expertise in the R language, he is able to manage data promptly at work, efficiently delivering in 2 hours what his colleagues do on Excel in the whole day. However he has big problems in communication here in Italy, he is not able to understand what other people with different background/expertise are asking to him precisely and this is becoming a huge issue in terms of career development.

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

#56

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

First real job I had there was this guy who had one specialization. He was in charge of some software that drove tape drives.

Every outside new manager would come in and in some form or another look down on this guy in some form due to his age and generally not doing "a lot" of tasks and new products.

It took the local VP to come down and regularly high five him after his product git rave reviews from customers (regularly) and make the point every time some manager didn't get it.

That guy's code, documentation, everything was rock solid, and the number of support cases for everything he did was so low that the dude was without a doubt the most productive person as far as income goes. You could sell the product that he worked on and just rake in money with almost no costs after that. Almost everything else had a lot of support costs and etc.

Meanwhile the guys who were doing all the new stuff, sucked at trying to juggle 12 things because it looked good on a resume.

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

#57
post #15

Earlier quoted context omitted.

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.

Not quite the same. I moved away from Django some years ago when I ran into a bug that I traced back to the Django ORM. At the time it was neither obvious to fix nor easy to replace the Django ORM with something like SQL Alchemy.

It’s not necessarily about avoiding rewriting entirely, but rather minimizing the amount of rewrite required if you have to improve, change, or fix something. If your roadblock is in the framework, the bigger the framework, the more you have to rewrite.

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

#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 code that is straightforward to maintain.

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

#59

Earlier quoted context omitted.

I also work at Google and in my 9 years there I've never had a perf process where monetary or profit-success goals of the company were mentioned once. EDIT: I guess when I worked in ads, there were ad performance type metrics discussed to some degree. Not much though.

Goes to show how diverse a large company can be even with the same underlying processes.

I think there are product areas in the company that lend themselves more to this, for sure.

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

#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 speed with how it all worked and so I took the time to add / expand README.md files for each example, explaining what the acronyms meant and the general gist of each example. It was a worthwhile exercise for myself and I figured that it was worth sharing the perspective of a beginner too. My benign pull request remains ignored and unmerged and it makes me feel like a bit of an imposter. I thought nothing of it at the time but now I wonder if this is classic case of “the curse of knowledge”. Perhaps the author just can’t see the value of it.

Post reply on HN