Live data from Hacker News

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

bti360.com

81–90 of 371 posts

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

#81
What I'd be really interested in is how tech churn is perceived by people older than me. I'm only 30 years in, so I tend to defend my generation's choices such as POSIX, SQL, XML, SOA, Java, and C/C++ before that (plus special-purpose pet peeves of mine such as markup/SGML and logic programming which came before) though I'm also claiming to be proficient in and generally open towards new tech. I consider most of supposedly new tech as rehashes of things past rather than real progress, and to be just lock-in schemes and sucking in another way compared to the tech that it is supposed to replace. But I'm really uncertain if I'm just falling victim to generational effects, like, say, the proverbial COBOL programmer being ridiculed by younger devs to instinctively grow their own tech career. Still, for me, there's a moment around 2006-2012 when the industry went all-in on "the Cloud" and consumerisation of IT, when before I saw canon, progress, and consensus through standardization.

I guess this is something that can't be objectively measured; but I can say that initiatives for standardization have almost dropped to zero compared to the 1990s and 2000s.

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

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

If it's anything like my experience hiring contractors, it's definitely that they get the most "fun" part of the work. Most companies use contractors (in engineering) precisely for a well-defined tech work. They don't have to manage people or sit in meetings that are not relevant. We pay them by the hour and we try to get them to work on the stuff they can contribute the most - dealing with politics is expensive.

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

#83

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

When new collegues are joining our team or people start working on a subsystem unfamiliar to them, I usually tell them that this is a great opportunity for us as an organization and that they should be very vocal about everything that appears strange. Their lack of knowledge is a valuable asset that must be exploited as long as it's fresh. Unfortunately, often it fades within a few days when their mental mode adapts to our quirks.

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

#84

One of the tenets though, "6. Be Honest and Acknowledge When You Don’t Fit the Role" only is fair to the person if the team/company also follows that advice. If a team or company does not value, or cannot tell, or does not act if someone is incompetent and unfit for a role, then this advice penalizes those who are honest, and rewards those who are good at faking competence. You need to have a structure of integrity w…

It's clear doesn't say "acknowledge it loudly to everyone around you so you get kicked out of the role". He says there is more than one solution (e.g. grow to fit the role), and that it's about having the self-knowledge not to stay in a bad place.

If an organization pervasively rewards competence fakers, where will that whole organization be in ten years anyway?

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

#85
post #74

Earlier quoted context omitted.

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

As I see it, the Amazon leadership principles are designed to select for jerks. Specifically jerks who make money. Just look at them. One or two out of fourteen indicate to not be a jerk (Earn Trust, maybe Hire and Develop the Best) while multiple other ones rewards you for being a jerk if you succeed (Disagree and Commit, Bias for Action, Insist on the Highest Standards, Are Right A Lot, Ownership, Deliver Results, etc.).

edit: Amazon's goal isn't to be a nice place to work, it's to make a lot of money and everything else is secondary to that. They are so far succeeding splendidly at that goal across multiple verticals so arguably their approach works. I wouldn't want to work there myself but you can't argue with results.

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

#86

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.

In my mind its not that far fetched, depending on the person. The transition from experienced dev, to mentor to leadership doesn't seem all that unnatural.

Not everyone wants that though.

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

#87

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.

This is interesting I did a bit of Googling, I guess it varies by sport quite a bit. https://www.post-gazette.com/sports/around-the-league-nfl/20... Some sports, most coaches came from players, but the NFL notably does not.

"Most coaches came fro players" is very different from "players are expected to become coaches".

I can't think of any sport where players are expected to become coaches.

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

#88

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

This is true but the “curse of knowledge” from the article explains why this can happen. It is easy for outsiders like you and me to see the value of such things but as an insider you can become blinded by your knowledge.

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

#89

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 came here to say the exact same thing, but I want to extend it a bit more.

I've seen some developers, including myself, looking at some code and complaining "who the hell wrote this mess!", only to find out in repository history it was themselves. lol.

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

#90
post #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 (regu…

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 over time is hugely valuable, doubly so when what they do is the bedrock of many other things.

Of course the unhurried, thoughtful person looks like they are slacking and the hurried, frantically working person looks like they are a hard worker.

Fundamentally it's because impact is harder to measure than perception.

Post reply on HN