I'm in my 20s and think about this a lot although I already moved to management (with a lot of software development, still) as well.

There's a great article [1] analyzing this problem (quotes from the article: "Professionals with higher cognitive ability drop out of STEM careers earlier and faster", "High-ability workers are faster learners, in all jobs. However, the relative return to ability is higher in careers that change less, because learning gains accumulate").

Knowledge depreciates a lot faster in software development than many other fields. That's why I really think about going into finance or sales (still fast-paced), but attending expensive top business schools and starting as an analyst with a low salary again is pretty rough after already building my current skillset. Currently feel a bit stuck with my career options right now. Money's still good and the work is fun, but working in a field that is set up to be a grinding mill as an IC is not an entertaining thought. High-tech projects will still be fun, I guess, but still definitely something to consider. Specializing early on may mitigate this.

[1]: https://whoisnnamdi.com/never-enough-developers/

For finance: Managing finance and deals is one of the most important aspects in any business. You can make the same money compared to tech without a ceiling and I’m personally interested in economics and financial topics.

Both have a quantifiable aspect (deal/fund size, new revenue/customers) that makes it easier to measure your impact on the business. This means that it’s easier to get a fair compensation - although bad performance will get noticed easily, too. And the knowledge in these areas compound, especially in sales.

On a personal note, I’m interested in psychology and economics and can build connections with others quickly, so these two fit quite well and I'm convinced that sales and finance are important ingredients for any type of work (philanthropic included).

Best of all worlds would be to build a MVP using software development skills until product-market fit is reached, then being able to grow customers using sales skills and then supporting further growth with external capital and managing an exit using finance skills. - In reality, these are all separate roles, but I'd like to be able to work in these other two areas, too.

No.

Once a company grows to a sufficient size the goal stops being delivering products and starts being not ^&*£ing up the product that generates a lot of money. The aim is to hire people who won't get things wrong, either by making errors or by introducing new unproven ideas.

When I was young I also was pretty good at these interviews and loved doing coding contests and such for fun. However when I joined a big company I learned what really is hard about software "engineering".

It's dealing with legacy code, finding and fixing bugs in highly distributed systems, understanding tickets from customers, managing integration of different components, balancing tests to be enough but not to be too much.

In general the hard tasks are very rarely one specific well determined problem such as finding a node in a tree in the most performant way.

Right, if you can't do any of those and can only do leetcode you will get hired as a junior. Do you think that juniors need those things? No, of course not, they need to learn that on the job. So juniors gets leetcode. Now, since all juniors can do leetcode, why shouldn't we require seniors to also know it? Otherwise we would hire seniors who are worse than the seniors we grow ourselves. You can say that seems like an arbitrary requirement, but it makes sense, and there is no lack of senior engineers wanting to get hired at FAANG. And getting X years of experience isn't an accomplishment, even the dumbest software engineer will get there after X years.

Of course you will gain experience anyways over time. But all your leetcode skills will fade into meaningless very fast when you see what the actual problems are.

I have been meaning to go back and grind some of those problems out again. Just to refresh my memory on them. But notice I have to 'refresh my memory'? These problems usually do not come up. You are usually clicking some if conditions together and a few for loops. Nothing fancy. The interesting bits are figuring out someone elses framework using docs written in an afterthought and what 3 other methods do I need to call to fill out param 4 of this method just so I can get this thing to do what I want.

Imagine a math professor would be required to be as fast in answering questions regarding times tables as a child in third class. I bet you wouldn't be able to hire almost any math professors any more because almost all of them would lack this skill!

Nobody would be of course so stupid to judge a math professor by asking them questions about the times table.

Well, but one, and only one, industry is bonkers enough to do exactly this.

As LC itself demonstrates, there typically are multiple ways to solve a problem. Most engineers will do the brute force approach and stop there because it does in fact solve the problem. And for most companies that will be enough.

The issue here is those types of solutions can be catastrophic for these larger tech companies… some algo that’s part of a tiny feature cab cause a massive performance regression.

When it comes to these algos, computer science dictates there is an optimal time and space complexity solution. There are also more clear and more obtuse ways to achieve what is technically an optimal solution from a performance perspective… often these can be found and discussed in the LC discussion sections. The more obtuse… ie trying to get to a minimal LOC, might be fun from a competitive programming perspective, but terrible for production code that needs to be maintained by coworkers.

So there is a craftsmanship aspect to it that goes above and beyond these algos, but ultimately there are optimal time and space complexity approaches that need to be adhered to.

Now no one is perfect. You’re not always going to come to an optimally performing solution. But if you’re good enough at this stuff, and your coworkers are good enough, it’s going to be rare that a PR enters the system that causes some notable bottleneck. And when it does, you should have the mental toolkit to quickly determine what happened.

Making a call to arms avoid this stuff as it stifles creativity is sorta like the folks who say learning music theory can harm someone’s ability to compose music. If you’re a pop songwriter, perhaps. But what if you need to compose a symphony? You’re just not going to luck into it with a basic understanding of music theory and advanced composition.

It’s just one kind of mental toolkit, and somewhat orthogonal to knowing the apis and design patterns of some framework you’re using to build a thins, the idioms of a language, etc.

Then the software industry isn't for you.

I'm definitely not saying it doesn't require dedication and brainpower and (in the right places) formal methods. But the overall creative process, and most especially the end product (and the aesthetics) of what we produce are about as far from a musical symphony ... as anything you could think of.

There's a good Steve Jobs quote about this, which I couldn't easily find, but which completely nails this distinction. Something along the lines of: "No - we're not here to build something that that people will look at in a museum hundreds of years for now. Very little of what we do will last for more than 10 years or so. It's about meeting people's needs in the here and now."

(Or to that that effect; I am horribly mangling the original).

It's a very different thing to bust out a bunch of features for a consumer product w/ relatively minor concerns relating to load/perf and something that operates at bleeding edge scale and complexity.

This is a funny take on it as pop music is 99.9% just some basic music theory put in the shaker and than pressing the random shuffle button. The rest is mostly just dull and boring work.

That's the reason why after people once figured out how to actually do it are able to produce constantly hits for decades thereafter.

No it's not. No more than writing a successful novel is a matter pressing the random shuffle button on all the distribution of plotlines and clichés you've seen before.

Sometimes the best answer is the one that maintains an API that was introduced in a beta that one customer is using. Sometimes the best answer involves breaking a 15 year old API that the entire country's electrical grid requires. But in both cases we're always looking for a single answer, a One Ring to Rule them All. The end-point or approach-point trade off considerations are IMHO, the real issue.

And thereby distract us from the very central fact you have articulated.

The problem is that this almost inevitably leads to a decline of the company.

I'd say it's more like a "Yes and no." But it's definitely not a binary. Your "No" characterization is partially valid. But only partially.

And what's a great what to introduce mistakes and fuck up an existing product or team? By being overly confident about one's binary "No" answers.

Oh look...a googler ;)

So… the industry is apparently working fine for you, right?

> But if I was in my 20s or early 30s, I'd be looking to leave tech entirely and go into something else where experience is actually appreciated and valued.

Yeah, sure. Not for everyone. It’s unfortunate.