I think this post has good intentions. There's some truth to it and there's definitely value in plumping yourself up from time to time. No one should be worryin

I think this post has good intentions. There's some truth to it and there's definitely value in plumping yourself up from time to time. No one should be worrying about whether they're a "Real Programmer" or not. I agree that there's no value in beating yourself up or beating up your work. That said, I think the post takes it too far, and veers off into self-congratulatory back-patting that I think is not valuable, at all. I also think the author is wrong about hard problems, or at least managed to come up with a tautology that's not very interesting. Sure, many (and perhaps all) hard problems can be decomposed into smaller, simpler problems. But that's often not trivial, and the decomposition step often requires a lot of hard work. Even if hard problems can be broken down into smaller pieces, that doesn't always make the problems easier, even if it makes them more manageable. They still might require tremendous effort. The example given isn't a very good one; that sum just isn't that advanced mathematics. Now that's not to say it's not Greek to some programmers, and not to pooh-pooh people who have a hard time with math; I have struggled with it a lot. But there's a lot of math that really is hard to grasp, and isn't just a question of learning the notation, which is what the sum example is really about. The challenge sets up a straw man, IMHO. "Tell us that complex problem that is too difficult for the rest of us to possibly understand." It's asking the reader to be an arrogant ass. "I’ve just never seen a problem that couldn’t be broken down into simple to understand components, yet." Again, I think this just isn't a useful criteria. Broken down into simple to understand components doesn't make things easy. Here's an example, from my own dabblings: I am absolutely fascinated by programming language theory and compilers. Recently, I've been trying to get at the heart of two sub topics: parsers and types. I've been struggling to find presentations of parsers and parsing that really peels back the magic and shows how everything works, without just punting and letting Lex and Yacc do the dirty work (btw if you know of a compiler text that doesn't do this, let me know!) Yes, you can break parsing into a lexing step built up from regular expressions. Yes, you can translate regular expressions into NFAs and convert those into DFAs... and so on. But putting this together into a lexer generator is non-trivial. It's not easy, even if the components are simple. It's the same with type theory. You can write simple syntax directed type checkers and they might fit in your hand, but if you really want to understand type theory, it turns out there's a lot of math, and proofs to get through. Sure, you can decompose that into topics from set theory and so on, but this doesn't make it easier. More and more, I think his core argument is just really flawed. There's some connection here with Rich Hickey's "Simple made easy" talk, where he argues that simplicity can be hard to come by, and how easy and simple are different... but I've written too much and will leave that as an exercise :)