anyway, let me elaborate on my analogy
The bad programmer
Arguably the average programmer, makes a move without thinking about the side effects, his capacity of analyzing problems is not all that great, there are so many side effects (breaking code, introducing bugs, security, etc) but this guy is not even aware of most of them, he basically relies on the debugger and if it runs on his machine then is good to go; when stuff inevitably breaks he just goes back and makes another move that seems to fix the problem, if you give this guy a large project it is likely that he'll make a stupid move that will just cause Checkmate on the project
The good
Analyzes different paths and choses the one he thinks is best, this player can play a good game, every once in a while his analysis is not that through and makes some mistakes but he can learn from that, this guy usually delivers good quality software with few bugs that he can go back and fix quickly enough to be acceptable
The best
This guy can make a whole bunch of moves all in his head, he's informed about all the latest techniques to defeat the opponent but he doesn't just rush and use them in a game, he tries them first on his own little projects and ends up using the ones that he proves to be useful, the ones that are shorter, quicker and give him the best return, he knows the techniques to use with the small projects and the ones to be used with large projects, and he knows they are very different, this guy knows what the opponent is thinking, he knows what the opponent will respond to every one of his moves so he usually chooses the best move... he knows the side effects; the "works on my machine" is not on this guy's vocabulary.
As you can see the the main two differences in my analogy are the capacity of analysis (selecting the move) and the awareness of the side effects (what happens when you make that move).
The opponent is your software project, the move is writing the code, the side effects are everything else that is affected by that.
When was the last time that you introduced a new bug fixing that other bug or writing some new functionality? or when *they* found bugs of your code right after it went to production? or when it worked on your machine but not on the server?
Every time you make a move, stop and think about the side effects, there are always side effects, if you can't think of them, there are tools that can help you think better, such as Unit Testing, the more you practice it, the better you'll get at it, I promise
7 comments:
I agree on the similarity but the programming rules are not written, and it makes the job harder than a game.
I saw a similar analogy in SICP in section 1.2:
"We have now considered the elements of programming: We have used primitive arithmetic operations, we have combined these operations, and we have abstracted these composite operations by defining them as compound procedures. But that is not enough to enable us to say that we know how to program. Our situation is analogous to that of someone who has learned the rules for how the pieces move in chess but knows nothing of typical openings, tactics, or strategy. Like the novice chess player, we don't yet know the common patterns of usage in the domain. We lack the knowledge of which moves are worth making (which procedures are worth defining). We lack the experience to predict the consequences of making a move (executing a procedure)."
I think your observation is a fragment of a larger picture, captured by the above quote, encompassing topics such as IoC, design patterns and testing.
Hmm, in those terms, many endeavors are like chess. One that's particularly relevant is finance regulation (and other governmental policies). Hastily making one move that seems right (and popular) can have economic side-effects that ultimately cause things to be worse off...
Giorgio - Good point, of course I agree, but I did focus on the required capacity of analysis to *play a better game* (be a better programmer)
Tim - I like it, very well articulated, one could sure extend on this analogy
Anonymous - True, having a better capacity of analysis would help in many areas, just like other abilities and methodologies that programmers use
Boiled down, you make a laughably obvious point: bad programmers do bad things; great programmers are great. So? Your epiphany here is...?
@Anon - You make me ashamed to be anon, anon.
Something I've noticed about novice chess players is how little time they use on the clock because they don't think about the moves (much). I think they become overwhelmed by the sheer number of variations in the game and analyzing them in a general sense. It must be stressful.
Gratefull for sharing this
Post a Comment