Ask HN: Thoughts on Rich Hickey's advice on becoming a better developer?

So here's the thing: you believed in something, were living by this and felt just fine. Now you've heard some other guy with famous name disagrees with that and you feel down and confused. Isn't that funny? To be blunt, I think it's simply ridiculous. Having "a hero" in the strong sense of it is a problem by itself, but whatever, here you're discussing a practical issue. You think there's some goal you'd like to achieve, there are some practical advises from several people on how to achieve it, some are contradictory, as always. If you have confirmed, that something works, what's the problem? If you didn't confirm anything and you don't know how to solve it analytically, the only option you have (well, at least in this case) is following some of the advices and see what works.

But I'll go as far as saying that even that indecisiveness isn't your problem. The problem is, as it often happens, that you don't know what you want. You believe there's something you'd like to achieve, but you don't really know what. You never really formalized it, and hence you cannot judge if some advice would be helpful or not. Yet you strongly believe you want this "something", but as you don't know what is that, you cannot really decide on direction and it worries you. In that case only meaningful advice you can get is the one Cheshire Cat has given Alice, IYKWIM.

For what it's worth, I also have an opinion on that matter. I don't really believe in "mastery". I believe there's world full of things you can interact with and state of some things is different from that you'd like it to be, which produces a notion of problem, which you are willing to solve. Solving some specific problem may require skill, domain knowledge, physical strength or something else. Telling me that learning to make good sushi takes 70 years will only make me yawn or chuckle, depending on my mood, but sure it takes a lot of practice. And, generally, to be able to solve skill-related problems you need to practice. However it is quite likely that subset of problems you'd like to be able to solve in some domain (even skill-related) requires very little to none practice, as you can resort to using better tools (maybe humans), some clever trick or getting the essence of it is in fact pretty easy, when you have a good teacher.

So, as I don't believe in "mastery" both Hickey's and Norvig's advices mean pretty much nothing to me, and I partly agree and partly disagree with both. Specifically, I almost completely disregard the notion of "being not my domain", as I've repeatedly found that learning seemingly unrelated fields can improve my understanding of others and sometimes happens to be just handy (kinda point to Norvig). However I feel that as long as you have many enough options to cover all range of problems you'd like to solve, the less tools you use — the better it is for you, as it removes mental clutter and helps concentrate on actually solving the problem, not thinking too much about "what is better option to solve it" (point to Hickey). The famous presentation, where Hickey compares programmers to musician, I find compelling, but completely ridiculous when you actually think about that, as being a programmer has almost nothing to do with being guitar player. I disregard popular saying about programming being an art. There're more strong opinions of mine, which I can support with arguments, but that isn't really on topic and I doubt it would be of any interest to you as my surname isn't Norvig nor Hickey.

But, yeah, well, that's just, like, my opinion, man.

At it's simplest you have things like checking for existence using linear scans of arrays. Anyone with experience sees that as a bad thing to do because they understand that it's inefficient for any sort of sizeable array. But those who don't understand algorithms or data structures won't even know there's an issue. And that's the simplest case really.

When you have a list and you need to efficiently add and remove items from both ends - then you want some sort of double-ended queue. I know where to find the one in my std lib and I know when I need to use it - which it turns out is almost never - I thought I did the other day, then I found a simpler way, which was actually a bit disappointing :)

Then, as you say, you have things like A* or R-trees. The more of these you have an handle on - even just to know they exist, the better position you'll be in when you need them.

But I don't even think that's the most important part of knowing data structures and algorithms (and really, I'm sure none of that's news to you if you're implementing A* searching). For me it's more about understanding efficient patterns for data access. So much of the work I do is about efficiently pushing data around in different forms. Often having a core chunk of data and then a couple of different indexing structures to allow me to interrogate it depending on the info I need.

No, I mean knowing what algorithms/data-structures are available, what their characteristics are, and how to tweak them. This way you can say stuff like: with those data access patterns, we'll need a B+-tree with links for concurrency, modified to not delete depleted nodes until such-and-such. Or, something like: doing that efficiently requires an optimization that's NP-hard because the problem reduces to graph partitioning, but we can use an approximate solution that should work well-enough in this case.