The Codewright's Tale is a place to discuss the craft of software development. The focus is more about the human aspect of programming, there are plenty of sites which post the latest and greatest tools or blocks of 'how to' code. All the tools, methodologies, or languages in the world won't help if the primary obstacle of quality software is human nature and not a human invention.

Contributors

Monday, July 06, 2009

In my career as a developer, I reached a point where the amount of work that needed to be done was much greater than I had time to do myself. Budget realities aside, there was a lot of coding tasks like writing more unit tests or keeping various diagrams up-to-date that would be tedious but easy to accomplish as long as a basic understanding of development was present. Wouldn't it be nice to be able to afford to hire your own apprentice? Someone maybe still in college who had some exposure to coding but was still wet behind the ears enough to keep quiet and learn by osmosis.

At the time, I had visions of a helper who could take rough UML diagrams, like from scratch paper or from a white-board session, and update the project documentation. As each change came through, they would create new versions and archive old ones like a file clerk from decades ago.

First off, a fresh-from-college developer might consider that type of work as beneath him or her. I'd argue that learning the processes is just as valuable as learning how to code. Did they learn about version control, shared builds or managing a large code-base in school? Of course not, but experience with those types of processes are what most junior developers lack.

Secondly, if your job is consistently repeatable enough to explain to an apprentice, why are you there in the first place? The apprentice is much cheaper and easier to replace. More than likely, you job is one of those ones which is hard to explain because it relies on your experience and training to understand how to approach the problem and the possible/practical solutions.

Usually I stay away from comparing software with construction but in this respect, iron workers have a similar problem: how to bring on new blood without getting anyone hurt or jeopardizing the project. Even the most junior iron worker needs to understand how to do his small part and stay safe. The head iron worker needs to trust that his men won't need explicit instructions for every task and that when a crisis erupts, they'll understand what the priorities are without having to stop and have a meeting.

So, what you end up needing is someone who wants to learn, has the patience to listen, the intelligence to follow directions, the determination to keep doing hard work even when they don't know the importance of their contribution, and the wisdom to understand that not all knowledge comes from a book. The next step is to think about how to carve up your work so someone can help you with it. That will have to wait for another day.