Software Apprenticeship: Becoming More Than Proficient

Reading the first chapter of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye made me feel both anxious and optimistic about entering the software development field upon graduating this spring. As the authors very clearly point out, there is now an overabundance of developers but a scarcity of good developers in the workforce. In an effort to become one of the good developers, I have in the past kept up with many of the so-called masters referenced in Apprenticeship Patterns including Uncle Bob and Martin Fowler. I hope that by following the advice of Hoover and Oshineye I am able to make begin a career where I will make a difference as a software developer, and that someday I am able to pass along my experiences to future generations in an effort to continue the advancement of the industry.

What I found perhaps most¬†interesting and important about the first chapter were the disclaimers that the authors gave. Statements like, “These tools are not algorithms that guarantee the same results on every execution,” really helped to reinforce the idea that there is no magic recipe for success. The truth that Hoover and Oshineye are trying to convey to new developers is that being successful is not easy. The path to becoming a great developer has many hurdles, it takes more than simply following an apprenticeship pattern or any other set of instructions. What the apprenticeship patterns hope to offer, rather, is assistance in beginning a software development career and advice on how to become outstanding rather than simply proficient.

As a new developer trying to make it, motivation and drive are key. Perhaps most important, however, is a willingness to learn. Not being afraid to make mistakes, and being able to turn mistakes into learning experiences is crucial to personal and professional growth. It is also important to share your experiences with others, rather than hoarding them. Just as apprentices learn from journeymen, so too can one apprentice learn from another. This collaborative scheme was especially interesting to me. Far too often, especially as a student, I feel that individuals are selfish about sharing information with one another. While this is certainly understandable in situations where only one party benefits, collaboration can be an extremely powerful tool. I feel lucky to be entering a field that places such a high value on teamwork and collaborative success. Working together is what most often leads to the most profound or impactful discoveries and advancements.

Although the first chapter of Apprenticeship Patterns did not go into much detail on any particular subject, I am looking forward to discovering how to improve my chances of a beginning a successful and rewarding career as a software developer.

Why Repeatedly Repeating Code is Bad Programming Practice

After a discussion with a friend about the recent eclipse, the subject of the apocalyptic end of the world came up. I was reminded of Y2K, and decided that it may be worth some research, as I was too young at the time to really understand what was truly going on. As a student of computer science, perhaps it would provide me with some important examples of things not to do in my own coding. On a blog post written by Steve Rowe for Microsoft Developer, he shares what he learned from an instructor about the true cause of the Y2K scare, a lack of implementation of the DRY, or the Don’t Repeat Yourself principle. Y2K was caused not by mistakenly representing a four-digit year with too few digits, but by making this error over and over throughout and across multiple files. Unless absolutely necessary, code with identical or near-identical functionality should not be duplicated. Following the DRY principle makes maintaining and repairing code easier and simpler; it is important that those striving to become excellent programmers follow this principle.

While my mistakes are not going to cause the same devastation as the mistakes of the developers that caused the Y2K scare (yet), they have certainly caused me a great deal of frustration while programming for assignments or personal projects. On more than one occasion, I’ve found myself repeatedly trying to remedy a certain piece of code, only to find out later that the error was caused by similar code that was implemented elsewhere. It was this duplicated code that was actually responsible for the error, not the unused or irrelevant piece that I had been wasting time attempting to correct. My failure to follow (or even be aware of) the DRY principle, which I was unfamiliar with before looking over the syllabus for Software Construction, Design and Architecture has resulted in countless hours of wasted time and energy. Any programmer, no matter how good he or she may think they are, could always stand to improve. Not only will following the DRY principle allow your code to be more easily understood by others, it will make writing documentation and performing any maintenance much simpler. Steve Rowe makes an interesting comment before closing his post, stating that, if duplicating code is deemed necessary, “It might not be a bad idea to put a comment in the code to let future maintainers know that there’s similar code elsewhere that they should fix.” If we all attempt to better follow DRY and Rowe’s advice, maybe we can avoid future Y2K-esque scares.