Hacker News Reader

I think you do benefit, and I think having at least a grasp of the concepts does make you a better programmer.

However, I don't believe every programmer does need to understand complexity theory from a formalized perspective. I'll tie a loose analogy to a musician who cannot read sheet music, yet can still be a maestro. I think that sometimes some people just think a certain way, even if they (or others) cannot really explain it.

But I think that merely scratches the surface of a deeper issue. Bob (in his analogy) can be a perfectly serviceable programmer for many years and create many good things. But Bob may never reach his true potential because he didn't take the time to grasp the fundamental concepts about what he was telling the computer to do, or how the computer behaved when he did them.

Because Bob never truly understands computational complexity, maybe Bob never reaches his true potential.

> I certainly feel like I benefit from understanding how the typical algorithms used to solve those problems scale with the size of their inputs.

Spot on. Not only that, having that kind of understanding has prevented me from making some really stupid programming mistakes in the past.

One may not need that to write a CRUD (or let your framework of choice do it for you) but if one goes beyond the trivial, it's good to know where one is going.

Having said that, the specific enchantments, peculiarities, poor decisions and sadistic, inconsistent choices of the different tools I use for my work take up much more time and brain power than complexity theory. The inherently complex stuff is relatively rare. What's left is the stuff that's complicated for no good reason.

> Simpler: any time you select a binary tree instead of a hash table for your lookup table because you realize you need range queries or sorted traversal, aren't you leaning on complexity theory?

Only a nominal amount. You probably only need to spend a few hours watching YouTube videos to make these sorts of decisions, or pass a phone screen. Whereas there are entire classes and textbooks that cover only complexity theory.

Software is a weird industry because the best and most famous developers tend to be the ones who make software for other developers. And those folks tend to know a ton about software engineering. But the actual folks using those tools don't need to know all that much, and they're generally the ones making all the money.

That goes for anything. A carpenter needs to know wood theory, but doesn't need to know how to genetic engineer new species of trees.

The author is correct, you don't need to know complexity theory to be a programmer. But you do need to know it to become a good programmer.

That rather depends on your definition of 'good', no? Which is a whole can of worms we probably shouldn't open.

A developer will hit complexity theory the minute he or she starts to ask the question of "How can I make this process go faster".

But for a high percentage of developers, they'll likely never need to ask that question. The world isn't Facebook and Google and WhatsApp - it's chuggy little Java apps running on crappy PCs shoehorned into server roles outputting horrible HTML for IE7 users to check their trades once a day. If slow code brings in money, it can stay slow as far as I'm concerned.

I believe that the author is basically right.

More precisely, I think that there are three types of programmers. Those who don't know the formal theory. Those who know it but don't think in terms of complexity except when they have to. And those for whom big-O is second nature.

I believe that there is great value from having someone around who falls into the third group. (That's where I'd rate myself.) But they are rare. And there is little difference in practice between people in the first and second groups. Exactly how little difference is demonstrated by the fact that people who once took CS and then work as programmers find their memories of big-O fading over time because they aren't using it.

As for where the slippery slope ends, given the choice of having a new developer be a typical CS grad versus a beginning programmer who has mastered everything in Code Complete, I'd go for the second one every time. Obviously this isn't true if you're in an area that requires CS knowledge. But for most working developers, I think it is.