3 ms·
I've been paid to write code for 20 years or so and can't remember any of those friggin algorithms. Being able to understand a problem enough to successfully g
by ClayM 10y ago
I've been paid to write code for 20 years or so and can't remember any of those friggin algorithms.
Being able to understand a problem enough to successfully google an answer is the most valuable skill for a programmer.
- jackmott 10y agoHow do you know the answer you find is a good one? Say you think you need a binary tree, so you can get Log(n) lookup, you look it up, implement it, it works, great. Not bad. Then a lady comes along who actually understands the problem domain, and knows that cache locality will be a big win in this case, and she uses a sorted array with a binary search. Latency is cut in half and the company makes a brazillon dollars. Better.
- subatomic 10y agoFor 99% of situations in normal software dev, just being able to find X in collection is enough.
- rabidrat 10y agoAnd then along comes a 10x programmer who realizes that you can avoid the lookup entirely if you partition your data along this other axis. Latency goes negative and your company makes a few more brazillions off time travel. But the 10x programmer is a misogynistic asshole who can't balance a binary tree on a whiteboard. Now I have no idea which completely fictional character to hire.
- BurningFrog 10y agoNobody ever needs to code binary trees, outside of interviews and a few library developers.
- arsenide 10y agoAs a single point of data, this is not the case at my job
- BurningFrog 10y agoYeah, I kinda knew I was being overly categorical... Binary trees have been around for decades, and I assume there are solid libraries for all useful variants of them, and that everyone can use them. I'm probably wrong, but in what way?
- gaza3g 10y agoCare to share with us the nature of the work or maybe some examples? I'm kind of sick of doing CRUD apps. Maybe hearing about what you do would inspire me to explore something new.
- lyricalpanda 10y agoYour argument is flawed and represents what's wrong with our industry's interviewing process. Respectfully, of course. For most developers we don't need to even consider these trade-offs. It really depends what stack you're working with. Are you a front-end engineer? Then this doesn't even make sense because you wouldn't be putting that much into storage anyways that O() is going to matter. I'm an iOS developer and quite frankly you shouldn't be doing that much business logic on the phone. We implemented an algorithm that had a O(n^4) runtime without optimizing it because the dataset was so small it wasn't worth the time to over optimize. You're looking for an extremely rare case and discrediting 95-99% of the time we're programming. Sure we can do speed-ups but do you really have to filter every single developer for those criteria? You really don't. Guess what? Unicorns are built off the backs of medicore developers. The codebases once they start expanding are highly unoptimized. Slack was built from contractors. Twitch apparently is still having growing pains on their iOS app because the original developer wasn't very skilled. I was turned down from thumbtack even though I knew more about iOS than the iOS team lead that interviewed me because they valued CTCI more. The iOS team lead was taking advice from me about system design. What would you rather have? Someone that knows system design or someone that memorized how to serialize an n-ary tree? What is actually going to make you the bazillion dollars? A functioning app that can scale, or someone maybe helping you serialize a data structure (with a very known solution) on an iOS app which is completely useless? It's simply an illusion that you need to have developers who have memorized useless problems in the case that they may one day possibly might see an issue they could optimize 1% better by introducing more complicated code.