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.

On Technical Proficiency and The Gaining of Such, Pt 1

This is going to be a two-parter about how Junior Developers gain technical proficiency and the advantages and disadvantages of each method. For this part, I'll talk about gaining technical proficiency through experience. In my next post, I'll talk about gaining technical proficiency through self education.

As Junior Developers, often our number one enemy is lack of technical proficiency. Our lack of technical proficiency is often the key reason that we make mistakes, that we feel dumb, and that we aren't as productive as the more experienced programmers. These side-effects of our lack of technical proficiency directly result in our not always working on the most exciting projects or with the most cutting-edge technologies.

While at times, most Junior Developers may bristle at the idea of not being at the forefront of their companies' projects, as a Junior Developer, you must view the situation from your boss' perspective. The more important the project, the more likely the chances that your lack of technical proficiency may lead to any number of mistakes. This mistake could simply be writing bad code or could result in the loss of absolutely critical user data. With that in mind, you can see that it's more time- and cost-effective for your boss to put you on smaller, less mission-critical projects or to have you doing routine maintenance on current projects. Your boss likely hopes that through working on smaller side projects you will gain the technical proficiency needed to work on the bigger and more exciting projects.

So now you ask the very obvious question: How can I get me some of that technical proficiency?! Very simply, there are two ways to gain technical proficiency: Experience and self-education. In this article, I will discuss the advantages and disadvantages of learning through experience. Next time I'll hash out self education.

Experience arguably produces the most gains in a Junior Developer's technical proficiency, and for good reason. Experience can teach lessons that self-education cannot. Experience reveals whether or not those high-level theories you learned in college or read in other developers' blogs are truly practical and usable in the real world. Experience teaches a Junior Developer which tools work best for a certain job and how to better use those tools. Experience can even be second-hand, as talking to a senior developer can yield some of the best advice and practices that the Junior Developer has ever come across.

There exists, however, one very ugly side to experience, and probably the chief cause of instantaneous bowel-emptying: Mistakes. A Junior Developer's lack of experience will very often cause him to make mistakes. The mistakes are usually benign in nature and are expected of someone with his level of experience. For example, maybe the Junior Developer wrote inefficient code that called the database too many times, or perhaps introduced a logic flaw into a piece of code he was maintaining, or left a WHERE clause out of an UPDATE statement. These problems can easily be fixed with a little guidance (and a visit to the transaction log!).

Unfortunately, not all experience-related mistakes are fixed so easily. Many times have Junior Developers caused major problems that may have cost the company thousands or even tens of thousands of dollars. Such mistakes not only damage the company financially, but they severely damage the Junior Developer's confidence. In a perfect world, the boss would remain calm and realize that such problems result from the Junior Developer's lack of technical proficiency and experience, but in the real world, ass-chewings, finger-pointing, and even being sent home for the day are possible end-games for such serious mistakes.

The making of such mistakes can not only cost the company lots of money and seriously shake the confidence of the Junior Developer, but they put a large strain on the boss-employee relationship held between the Junior Developer and the Team Lead (or Project Manager, or whatever title is used at your company). By making such a huge mistake, the Junior Developer violates the trust of the Team Lead, since the Team Lead in essence delegates the programming jobs for which he does not have time to his developers and Junior Developers. When anyone messes up, that trust is violated, but when a Junior Developer messes up, the effects are more profound, since there's not much trust there to begin with.

The best advice I can give about gaining technical proficiency from experience consists of one central tenet: Always be able to undo whatever you're doing. Just as importantly, be sure that you know how to undo it. If you can sort of cushion yourself against your own mistakes by always knowing that you could undo your last goof-up, then you'll be able to experiment a little more freely and program with a little more peace of mind. Be weary when you begin working in an area where you're not particularly knowledgeable about how to undo your own mistakes.

There exist many other facets of experience and its effects on technical proficiency that I will visit throughout many posts, but those are the chief pros and cons, at least in my mind. Next time, I'll talk about self education, that double-edged sword that can offer great gains in technical proficiency, at least if you find some some that's actually applicable in your real-world situations.