For a long time I have believed that software development is just like a Chess game, but apparently not many people have thought about it this way, just *bing* it and you'll see less than a page of results (Google is no better), of course this is about to change as I write this post and everybody sees the light... or not
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
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
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