"Deliver commercial products" includes the part of continuing to deliver those products over many years and many releases, without any regressions. It's part of the job.
OK, but it's a different set of skills. Leetcode challenges optimize for finding devs that believe there's One True Way to do things, and that creatively deviating or using a mathematically non-optimal solution for reasons outside of the code itself is Bad and Wrong. If you want to continue delivering a successful product without breaking things those are good things to look for.
If you don't want to break things you simply don't alter the state of being. If you want a successful product over time it requires innovation. These goals are at odds with each other.
We’re generally talking about large complex distributed systems with tons of throughput.
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.
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).
That's not the point I'm making. Symphony as in complexity of the overall problem and synchronicity of so many moving parts (ie. so many instruments, multiple melody lines working w/ a far more advanced ruleset).
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.
OT: > learning music theory can harm someone’s ability to compose music. If you’re a pop songwriter, perhaps
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.
As pop music is 99.9% just some basic music theory put in the shaker and than pressing the random shuffle button.
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.
They're the same skill. The difference becomes implementation. When delivering consistently what you're also doing is critically examining when or if the trade off value exists.
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.
