This was one of my most popular tweets ever:
the complexity created by a programmer is in inverse proportion to their ability to handle complexity
I wanted to follow up a little, since some of the responses suggested that I wasn't perfectly clear (in a tweet. imagine that.)
The original thought was triggered by doing a code review with a programmer who was having trouble getting his system to work. The first thing I noticed was that he clearly wasn't as skilled as the programmers I am used to working with. He had trouble articulating the purpose of his actions. He had trouble abstracting away from details.
He showed me some code he had written to check whether data satisfied some criterion. The function returned a float between 0.0 and 1.0 to indicate the goodness of fit. However, the only possible return values at the moment were exactly 0.0 and 1.0. I thought, "Most programmers I know would return a boolean here." And that's when it hit me.
This programmer's lack of skill led him to choose a more complicated solution than necessary (the code was riddled with similar choices at all scales). At the same time, his lack of skill made him less capable of handling that additional complexity. Hence the irony: a more skilled programmer would choose a simpler solution, even though he would be able to make the more complicated solution work. The programmer least likely to be able to handle the extra complexity is exactly the one most likely to create it. Seems a little unfair.
I'm interested in how to break this cycle, and whether it is even possible to break this cycle. I'm certain that this programmer knew about booleans. For some reason, though, he thought he would need something more complicated, or he thought he should look impressive, or he thought the extra complexity wasn't significant, or something. How can someone with ineffective beliefs about programming be helped to believe differently?
wooooooow wooooooow woooooooow