Mastery as a Lifelong Endeavor

While I think that it is relatively straightforward to begin the software development journey, it is another thing entirely to become a master. Mastery is nearly impossible to measure and may require a lifetime of dedication to the craft to achieve. While these facts may be almost universally applied to any craft, I think that when applied to software development in particular they are especially telling. In Hoover and Oshineye’s Apprenticeship Patterns, they discuss a pattern termed The Long Road. It is this Long Road that is representative of the lifelong journey that is mastering the craft of developing software.

Hoover and Oshineye urge that the true value of mastery lies not in making more money or gaining status and power, but in, “comprehend[ing] and appreciat[ing] the deeper truths of software development.” This focus on the craft rather than on typical indicators of success such as promotions or high salaries is what sets truly great software craftsmen apart from the mediocre. I found it both inspiring and a bit comedic that Hoover and Oshineye included the parts about surpassing legendary software craftsmen such as Donald Knuth or Linus Torvalds. When you think about it, however, such feats do not seem entirely unrealistic considering that anyone truly hoping to become a master software craftsman will likely dedicate over forty years to that end.

I feel that this pattern would likely be offensive to developers who chose computer programming simply because of the abundance of jobs or relatively high starting salaries, not because of a genuine appreciation of the craft. These software developer posers would have no desire to become masters of the craft, and would jump ship at the first opportunity for a promotion or raise. This is also where the lack of knowledge transfer between generations of developers mentioned in the pattern’s introduction originates. If developers are waiting for any opportunity to move on, then the void that they leave is constantly being filled with new developers, leaving few veterans to show them the ropes.

I can certainly appreciate why a promotion to project lead or some executive position would be a tempting opportunity for career advancement. These roles, however, often require giving up the very things that make software development such an exciting and rewarding job to begin with. The feelings of pride and excitement after finally figuring out a difficult piece of a program or passing every test case is something that software craftsmen on their journeys to becoming masters will continually experience.

Choosing a CMS

When choosing a content management system (CMS) to begin developing a website for myself or someone else, there are a few important considerations that must be made:

1. Who will be maintaining the website after development is finished?

I think that possibly the most important consideration that needs to be made when choosing a CMS for website development is who will be the one responsible for maintaining and updating the website once development is complete. Nothing is more frustrating than going on a beautifully designed website only to be faced with outdated and/or broken content. It does not matter how beautiful or complex the original design is if there is a need for dynamically updated content and nobody around who possesses the skill set required to make the changes or update the content.

2. What type of website is being built?

Another important consideration is the type of content that the website will serve. While many CMSs have support for multiple types of websites such as blogs, ecommerce stores, and static content sites, one may be better suited to a particular task than another. Choosing the right CMS for the job can make both the developer’s life easier and also create a more efficient, polished finished product.

3. How is the website being deployed?

In addition to considering how the website will be hosted and deployed, it is important to consider what the expected volume of traffic will be when choosing a CMS. If the expected volume is extremely high, then perhaps a cloud-based SaaS CMS is the best option. A cloud-based solution would allow for much easier load distribution and balancing and may be automatically handled by the platform itself. If volume is expected to be relatively light or the site is to be hosted locally, considerations must be made for the hardware/software support of the systems on which the site will be running.

4. Does the website need to integrate with existing infrastructure?

In addition to hardware/software considerations for deployment, another factor to think about is what types of IT infrastructure is already in place that will need to be integrated into the website. If there are already databases in existence, ensuring that the website will be able to integrate with them will save significant time and cost over having to migrate data between systems.

5. What kind of support is available for the CMS?

Whether it is for the developer, or for the client after development has been completed, what types of support and how easily accessible it is can be an important factor in deciding on a CMS. Are security patches regularly released so that the site will not be vulnerable? Is there a community that releases plugins, themes or other types of time-saving customizations for the CMS?

In deciding on which CMS to use for the development of the Massachusetts HOSA website, I considered these five points and decided on WordPress. My experience with WordPress as a CMS has been very positive, and I feel that choosing such a user-friendly CMS will allow for straightforward updating and maintaining of the website for many years to come. WordPress is flexible, powerful, and will be easy to scale should the needs of the organization change in the future.

Staying Open to New Ideas

After a few years of using mainly one language to accomplish programming assignments, I will certainly admit to becoming complacent with Java. If I was asked to write pseudocode, my mind immediately begins object orientation and even begins running through some of the Java syntax. While this can be helpful, as I feel my ability to think in Java means that I may be well on my way to becoming bilingual, there are also many drawbacks to complacency.

Applying this Java-like thinking to problems in other languages or under other frameworks is where problems may arise. Rather than being open to discovering and developing new skills, the existing knowledge becomes a hindrance to learning. Attempting to apply existing knowledge to problems of a different sort or in a different language may slow progress, and make learning even more difficult and frustrating.

The solution offered by Hoover and Oshineye in Apprenticeship Patterns is to put on The White Belt and allow oneself to be ignorant by putting aside accumulated knowledge and experience, leaving no choice but to learn the way through trial, error and reflection. Treating new learning opportunities in this way allows for more deeper understanding and helps to create more smooth communications with members of the existing community.

I recently decided to expand my software development experience by studying JavaScript. While I feel confident that I have stumbled over the most difficult learning hurdles at this point, I wish that I had read this apprenticeship pattern before my attempt. I feel that I had a difficult time initially overcoming how fundamentally different JavaScript is, and often found myself grasping for the comfort of Java. It wasn’t until I took a step back from what I was doing that I realized I needed to open my mind to fully understand and appreciate JavaScript for what it was rather than how it was different from or similar to Java. The example that Apprenticeship Patterns uses, a lottery program written in three languages (Java, Io and J) is especially telling of this fact.

While I would have previously described myself as open minded and always willing to learn, I believe that The White Belt pattern has helped me see a more valuable way to approach new learning. I will certainly be using the ideas of Hoover and Oshineye the next time I attempt to learn a new programming paradigm.

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.