Well, I have been thinking about this a lot recently, and it occurs to me that this question is actually one of the keys to being a good programmer. For example, think about that guy that most of us has met at least once - thinks he is God's gift to programming, when in actuality you wouldn't let him touch your code with a 10 foot pole. Programmers like this are severly handicapped by their own mental image of themselves - believing oneself to be God-like prevents you from confronting and overcoming your own limitations.
While this fact is true in other professions as well, in programming it is particularly important because there are concrete methods we can use to improve ourselves. You should constantly be looking at your own development as a programmer, and finding those places where you suck. Rest assured, there is some way in which you suck. Even the greatest programmer in the world sucks in some way. Find your suck, and fix it.
I am hardly the first person to think of this. Jeff Atwood's blog Coding Horror is one of the few blogs that I follow closely. He has a great many posts in this vein:
I think, though, that this can be taken beyond just being aware of your weaknesses. Really, I think, the key to improving as a developer is self honesty. As the Greeks say, Know Thyself. Try to get a good handle on what your strengths are, and what your weaknesses are. In fact, try to actually go so far as to write out a list of your strengths and weaknesses. Make them real weaknesses, too, not those cheesy, strengths-worded-as-weaknesses (i.e. "Sometimes I just work too hard and get too much done" - eck). As an example, I will expose my own lists in this area. Strengths:
- I am quick - I can typically bang out changes at a quicker than expected pace
- I am pretty good at debugging hard to figure out bugs
- I am good at working with legacy systems and retrofitting bad code
- Once I find a solution, I can latch onto it, and have a hard time leaving it for new solutions
- I can be kind of absent minded, and forget things that are not directly part of my attention at the moment
- I can overlook some edge cases when testing a system
Once you have your list, figure out what you are trying to do to overcome them:
- Once I find a solution, I can latch onto it, and have a hard time leaving it for new solutions - so I sometimes, time permitting, try to discard a solution once I find it, and start from scratch, going in a different direction.
- I can be kind of absent minded, and forget things that are not directly part of my attention at the moment - so I make sure to make heavy use of Outlook, both with the calendar and task lists, so that it reminds me to do stuff when I need it.
- I can overlook some edge cases when testing a system - so I always try to spend extra time looking for edge cases, and sometimes ask others for opinions, to try to flush out my testing.
If you are really honest with yourself, and really understand where your strengths and weaknesses lie, you can make use of that both in your current job and in any future job interviews. By understanding yourself, you can know when and where you should volunteer for tasks, and where you should ask for help. And when you are in that interview, and the dreaded question comes up, you can give them one hell of a surprise by actually answering it with a real weakness, paired with your plan for strengthening that weakness - which may actually give you a heads up, as it will set you apart from all of the "I just care too much!" answers.
No comments:
Post a Comment