Friday, December 7, 2007

On Technical Proficiency and the Gaining of Such, Pt 2

In my previous post, I began talking about how a Junior Developer might gain technical proficiency in his or her job and become a better developer. In particular, I talked about how a Junior Developer might gain technical proficiency through his or her experiences. I discussed how potent such experience can prove, though I also discussed the most common pitfall: Embarrassing and sometimes catastrophic mistakes. In part two of this series, I'm going to discuss a gentler, kinder, more roundabout method of gaining proficiency: Self education.

Self-education is just as important as experience in gaining technical proficiency, but for altogether different reasons. Firstly, you should always be learning. Period. Computer science and software development change so often and in such sweeping ways that it's easy to lose your place among all the new ways of developing, thinking about, and maintaining software. Though it would be impossible to even tread this kind of water, it is you're responsibility as a Junior Developer to always keep up with the newest methods of software development.

Self-education also keeps your mind in that software-development mindset. When you're reading articles and blogs on database relations, object-oriented design, Ajax, LINQ, or the newest iterations of whatever technology you use, that will keep your mind in the developer mindset. When you come to see problems as objects, solutions to those problems as methods that allow objects to interact with one another, and database tables as ways to save the state of those objects, then you'll find that you become a much more effective programmer. You will learn to quickly assess certain situations and be able to implement them as objects and ultimately code much more quickly. Just as the IDE and RDBMS that you use are tools that allow you to do your job, so is the methodology that you use a tool in allowing you to translate real-world problems into abstract software ideas and later into code. The better you become at this, the better programmer you will be.

Of course, there are downsides to self-education as a way to gain technical proficiency. Unfortunately, not every cool new design methodology that sounds really great on paper (or your monitor) translates very well into real-world usage. Some design concepts may be very novel and unique in their approaches, but that doesn't necessarily mean that they practical. I have recently been toying with LINQ to SQL in my spare time, and while it is certainly new and exciting, it unfortunately does not lead to much practicality, especially if you or your company focuses on the n-tier architecture. It's a great idea, Microsoft, but I think it needs another iteration or two before it's ready for prime time.

Even when you do happen across a new design method or technology that is practical or better than that which you already use, that doesn't mean that you'll actually be able to use it. There are many other restrictions placed on your available tool set other than the practicality of a new method or architecture. For instance, if you work for a company, then chances are that you use whatever methodology, technology, and best practices used there. And if you're a Junior Developer, then your chances of being able to persuade your boss into changing paradigms to a new design methodology or technology remain very small. That isn't to say that you're boss won't let you do something like that on a small side-project or in a non-mission-critical area, but more likely, he'll probably be more concerned about your becoming proficient in the technologies that the company is using so that you can more quickly become a good programmer in areas that are mission-critical. Your boss is certainly not to blame for that, as he is primarily concerned with the practicality of your skill set and the criticality of your tasks.

However, despite these limitations, I believe that self education is probably the more important of the two paths to becoming more technically proficient. Experience only teaches you of methods, practices, and schools of thought that already exist and have probably been around for a while, especially if you work for a company and are developing enterprise-level solutions that require more stability than dependence on bleeding-edge technology. Self education, however, can open your mind to realms of thinking and approaches to software development that you never would have reached on your own. Even if your boss or company would never allow such sweeping changes as whatever the latest development fad may be, you can at least adapt elements of that fad that could make your code more readable, portable, and easily-maintained. If your boss does call you on it, you can explain to him what you're doing and how it makes your code more human-readable, less error-prone, and more easily maintained. What's he going to do, tell you to change it back and make it worse? He actually may very well do that, but at least you'll have a.) tried, and b.) learned a new way of thinking in the process. What's the harm in that?

Of course, the best areas in which to try out such new things is your personal life. Working on personal projects at home is a great risk-free way to expose yourself to new and exciting forays into software development that you'd never get to do at work. This has another side-benefit of improving your performance at work, as well, since you'll be gaining your own personal experience by working on personal projects in your spare time. I'm not telling you to give up the spouse or significant other, of course, just to keep yourself afloat in this ever-changing world of software design by devoting part of your personal life to learning something new related to your field.

So there you have it: Two sure-fire ways of gaining technical proficiency examined. We've learned that experience is great, but has two very large drawbacks: 1.) You can and will make mistakes, and sometimes very costly or embarrassing ones, and 2.) You will only gain experience in the technologies and methodologies to which you are currently exposed, which can be very narrow if you work for a large company. We've also learned that self education is also very important, as it allows you to tread down paths that you never would be able to go in your professional life and will expose you to ever-expanding and exciting techniques in software development.

No comments: