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.
What I’ve Learned in 45 Years in the Software Industry
171–180 of 371 posts
Re: What I’ve Learned in 45 Years in the Software Industry
#172Re: What I’ve Learned in 45 Years in the Software Industry
#173Something 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…
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
#174Earlier 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…
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
#175Something 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"
Re: What I’ve Learned in 45 Years in the Software Industry
#176But 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
#177This 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.
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
#178A 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
#179Earlier 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!)
Re: What I’ve Learned in 45 Years in the Software Industry
#180Earlier 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.