Live data from Hacker News

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

bti360.com

171–180 of 371 posts

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

#171
post #139

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'm about where you are, but when I read the word of veterans like this it just galvanizes my desire to leave the tech industry.

Don't get me wrong, me too. I just want to retire and write code for fun.

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

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

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 never rock this boat, because their career KPI is the number of people they manage.

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

#174
post #68

Earlier quoted context omitted.

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

I've moved into contracting after being a software engineer/developer/team lead.

Essentially since you are contracting, you are outside of the "bubble" where decisions regarding business get made. So while you may have important work on the project, you are not there when they are deciding on business aspects of it, you are usually not invited to any type of sales meetings or meetings with the clients. This is reserved for company people.

Another aspect you can do is that you can outright reject that type of work or slowly move away toward a client that is not requiring that type of work. When you are working in a company, you usually do not have power to do that. Your only option in a company is usually to quit and then hope next company doesn't pull you into that meatgrinder.

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

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

"Psychology is eating the world"

Well Zuckerberg’s major was psych so you might be onto something there ...

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

#176
Most of this is perfectly archetypical "hindsight says it's all about the little things", exactly what we expect our elders to say.

But consider no 100 year old dying in 1950 would bother impart:

> At the end of the day, sweaping the barn really is how all my children made it to age 5

> A rust-free butterchurn keeps those fingers attached, don't rest though there's a wall of glass

Good Timeless advice is a function of stagnation.

> Fighting complexity is a never-ending cause.

> Beware of Lock-In

These ones, though, I like. We should strive to understand problems in full generality, which may increase simplicity. But our current cloud-and-Docker-snakeoil trend is either epicycles, not ellipses, or lock-in, never neither.

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

#177

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.

The only difference between a manager and the other on-the-ground engineers is that the manager works more closely with the stakeholders to understand their requirements in more detail than the other engineers have time to. With that additional knowledge in hand, the manager helps guide the other engineers to make the right tradeoffs. It is still engineering, just at a different level. A level not everyone enjoys working at, granted.

I guess if there is an accounting analogy, it would be selecting one accountant to work closely with the government to ensure that the tax law is fully understood and to watch the other accountants to ensure that they are following that tax law, reducing the inefficiencies of all the accountants in a firm needing to spend their days acquiring a perfect understanding of the tax law and not spending their days doing the practical accounting work.

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

#178
Great advice!

A correction:

Ruby the language is not really a lock-in problem.

It’s specifically DSLs, and the concept is non-Ruby specific.

People that got bit by Chef (which is still great, but it can get unwieldy) may blame Ruby, but the problem there was things getting much too far away from the actual CLI commands, so it was a DSL lock-in problem.

The warning against DSL lock-in may be founded.

But, when it’s kept simple, DSL lock-in may not be there as much. If you can quickly translate it to something else, you’re good.

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

#179

Earlier quoted context omitted.

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

Yup. I agree with you (and your pragmatic approach to helping the raptors!)

Thank you! (Actually the raptor conservancy [0] is interesting from this perspective as well. I'm a newbie / junior in that context, but I can see standard employee patterns that I recognise from the tech industry, e.g. in terms of people who know to report and / or delegate well, or to make effective decisions vs. be indecisive. Perhaps I'll have to see if I can document my observations on what I've learned in my career).

[o] https://news.ycombinator.com/item?id=25650535

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

#180
post #114

Earlier quoted context omitted.

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.

Almost all football managers are ex players.

Well, only 1/3 of them played Pro before going into coaching. The rest were college players (and two only played in High School) who switched to coaching, mostly because they didn't get drafted.
Post reply on HN