Unless you live in a cave, you know that in the last few days another Object Oriented (OO) vs. procedural debate has flared up. I thought this would be a great opportunity to discuss an attitude I have seen from some developers that mirrors the attitude I saw in quite a few people in my previous career.
For those who do not know, before becoming a developer, I spent 14 years as a paramedic. One similarity I have noticed between my former and current careers is that you can never know enough. There is always something new you can learn to make you better at your job. Another similarity is that if you ever stop learning, well, then the job has passed you by.
I found that the best medics are the ones who would critique a call when it was done and try to find where they could have performed better and work on improving those skills. I would like to think I was one of those medics. Regardless of the outcome of the call, I always found at least one area where I did not preform as well as I may have wanted. Its easy to look at the patient outcome as the sole indicator of how the call went, but rarely was that a true portrayal of how the call went.
I have also found that the best developers are the ones who critique a project when it was done and try to find where they could have performed better and work on improving those skills. I would like to think I am one of those developers. Regardless of the outcome of the project, I always found at least one area where I did not preform as well as I may have wanted. Its easy to look at the project outcome as the sole indicator of how the project went, but rarely is that a true portrayal of how the project went.
When I was medic, I always wanted to learn more. I always wanted to do what I could to become a better medic. As a developer, I always want to learn more. I always want to do what I can to become a better developer.
For me, becoming a better developer means learning new ways to solve problems. Whether this was from learning (or continuing to learn) OO, learning how to use frameworks or even new technologies (such as Flex) I gained new tools I could use to solve problems. Sometimes, what I learned is that, for me, the new tool might not be such a great fit, but, I still learned something.
With each new tool I can add to my toolbox, the better I can become as a developer and, more importantly, the more valuable I become as a developer. I say ‘become’ in that sentence is because just having the tool does not make you better, you need to consider these new tools and learn when is the best time to use them. A carpenter can have every tool under the sun, but if all he ever uses is a hammer, without considering using any of his other tools, he’s not going to be a very good carpenter. Another way of saying this is, if all you know how to use is a hammer, everything looks like a nail.
While I have never been one to shy away from learning new stuff, recently my desire to learn new stuff has not been as fierce as I would like. That changes today. I am issuing a challenge. A challenge to become a better developer. A challenge to everyone reading this, myself included, to pick a new tool – be it a new application framework, new concept (such as OO), new process (such as unit testing or using code repositories such as SVN or Git) or a new technology (such as Flex or Groovy) – and sit down and learn how and when to use it. Learn the advantages you gain and any possible negative effects of using this tool. Then keep the tool in your toolbox until the time comes that you need to use it. Finally, when you feel comfortable with that tool, go pick another one and start the process all over again.
I challenge you to become a better developer and not let the job pass you by.