The One Thing All Newcomers Can Offer: Enthusiasm

The one thing that just about any recent college graduate has to offer a prospective employer is enthusiasm. While enthusiasm may help with getting in the door somewhere, once starting out on a new team of experienced developers the newcomer may be less willing to express that same enthusiasm. Although it may sound juvenile, the desire to fit in applies just as much in the workplace. This desire may prevent a newcomer from sharing valuable excitement and new perspectives with the team. Overcoming this fear of and sharing your excitement and creative ideas will be far more beneficial in increasing learning and value throughout your apprenticeship. In Apprenticeship Patterns, Hoover and Oshineye cover this topic under the Unleash Your Enthusiasm pattern.

If there is one thing that I am sure about, it is my desire to make a real difference through software development. I am passionate about making a difference and excited to begin this journey. I will admit, however, that I would be a bit hesitant to express this eagerness if other members of the team seemed to be skeptical of me. It would be far easier to take the conservative approach and try to match the excitement level of the team. Taking this approach is not the most effective strategy in these situations. It would be far more valuable to both the team and to the apprentice to fully embrace that enthusiasm and use it to inspire and motivate the team. Rather than viewing your excitement as an annoyance to the team, you should view it as an asset that will help the team.

When first starting out, it may be difficult to find ways to make any meaningful contributions to the team. You will need to earn the trust of the team before taking on risky tasks that may jeopardize the integrity of the work as a whole. One way to make contributions while also gaining the respect and trust of the team is to ask questions and unleash your enthusiasm. If you’ve found the right mentor, your enthusiasm for the craft of software development will be rewarded. This mentor will guide you, and you will give him or her a renewed excitement for the craft.

Starting out by Sweeping the Floor

As I will soon be starting out in a new position at an unfamiliar company, I was more than happy to look to Apprenticeship Patterns for help in making the most of my apprenticeship. While the position may not be exactly what Hoover and Oshineye had in mind when they wrote the pattern, I found the Sweep the Floor pattern to be almost universally applicable to any entry-level position. When you are just starting out, you may not feel comfortable taking on some of the more complex tasks. You may be unsure of where you fit in as part of the team, and the team may be unsure of you. The Sweep the Floor pattern offers advice on how to contribute to and earn the team’s trust as well as growing professionally when you are just starting out as an apprentice.

I found the inclusion of the story from Paul Pagal to be comical and also informative. As mentioned, there are certain less glamorous tasks that simply need to get done in order for the team to be able to function. While they may not be glamorous, they provide an opportunity to make yourself useful and appear motivated. This most certainly will not go unnoticed, and should lead to progressively more interesting and complex tasks. As your skill level as well as comfort level increases, you will begin to take on riskier tasks.

Hoover and Oshineye follow the story by saying that having to do less glamorous work to get your foot in the door may be tough to swallow for some apprentices who feel they’ve already paid their dues. While I’m not trying to discount the value that I feel my formal education has, I’m not sure that I agree that this counts as paying your dues. Until you’re part of an actual team facing real-world problems, you haven’t paid your dues. This is part of the reason that I feel completely content starting off with more menial tasks. I am more than happy to begin proving my worth and showing my team that I am ready for bigger challenges by starting off with some of the less glamorous tasks. After all, somebody has to do it.

Looking Back on Sprint 1

The first sprint contained a lot of small tasks for setting up the environment and getting familiar with the ng2-amrs system. While some of these tasks were simple, others that originally seemed simple became difficult and took more time than the team and I originally expected. Overall, I feel that the team worked well together and that we were able to complete the bulk of the story items for this sprint. There were a few areas where I think we could improve for the next sprint, and these topics were discussed during our retrospective meeting in class.

One of the first tasks that was completed for the sprint was to Create a GitHub organization for your team. Dominique assigned herself to this task, and created the organization. She invited all of the other team members to the organization during a class work day and ensured that we were all able to access the organization.

Another task that was completed quickly due to its relative simplicity was the Choose a label color for your team. Matt assigned himself to this task and changed the label color on the appropriate card on the Class Scrum Board.

I assigned myself to the Fork ‘ng2-amrs’ from CS-Worcester-CS-448-SP-2018 to your organization task. I was able to complete this task only because Dominique had already created an organization for our team and gave me the necessary permissions.

The Read README.md and Read CONTRIBUTING.md tasks were relatively simple, and all members of the team completed these tasks early in the sprint.

The Decide how you want to manage your team’s GitHub repository was completed as a class rather than as a team, so little effort was required on the part of our team.

Everyone on the team was able to complete the Clone ng2-amrs to your computer task, as Dominique gave all of the members of the team access to the organization’s fork of the project.

Some of the tasks that gave the team a little more difficulty were the Learn how tests work for AngularBuild ng2-amrs on your computer, and Connect your ng2-amrs to the server. While the team members that had the project built and connected to the server attempted to help other team members get up and running, there were a few different and unique problems that gave people trouble in building and connecting ng2-amrs to the server.

Matt was able to fix one of the most severe of these problems, namely that of the ladda module complaining about missing files. Matt shared his solution with the team and the rest of the class, and was able to help many people in successfully building the project.

We were initially waiting on the Ampath Informatics team to provide us with a link to a server that we could connect to. When this link was provided midway through the sprint, we chose to add the task to our sprint backlog as some members of the team were ready to accept more tasks. For this reason, it was not a concern that the entire team was unable to complete this task.

The final task that was not completed by everyone in the team was to learn about tests in Angular. Once again, this task was not of critical concern because we likely won’t be using testing heavily early on in the development process.

I think that the team worked well together, and that members supported one another throughout the sprint. One thing that we may be able to improve upon is communicating when we are having difficulty so that others are able to offer assistance. Or, on the flip side, asking and offering assistance when another member of the team seems to be struggling. I am looking forward to working with my team and getting into some of the more technical parts of the Ampath project.

Constructing a Curriculum

After recently completing a difficult, humbling and valuable phone interview for a position that I thought I was well qualified for, I decided to make a renewed effort in educating myself outside of the classroom. The discussion helped me to realize the areas where my skill set was lacking, and where to focus my educational efforts. While some classes offer information of a specific, desirable topic, I often find that I cannot find the exact topic that I want to learn as part of a course. I perform a quick search on Amazon, which reveals multiple books on the topic, and I quickly order one according to user reviews and ratings. This is the process that has occured time and time again, leading to a bookshelf full of books on varying programming topics. For many of these books, I have only just begun reading (or I got halfway through and was distracted by something else), and never fully gained an understanding of the topic that I set out to learn.

For these reasons, I found the problem statement of the Reading List pattern in Hoover and Oshineye’s Apprenticeship Patterns to be especially applicable to my current situation. The problem statement says, “The number of books you need to read is increasing faster than you can read them.” While I am constantly increasing my understanding of certain topics, new and improved methods are constantly being developed. Keeping up with the rapid pace at which software development changes is difficult, but following the advice of Hoover and Oshineye will undoubtedly give me a leg up on the competition. I like that the Reading List that they propose is essentially a priority queue, with the books that are most important at the top of the list and the ones that may not be as important towards the bottom.

It was reassuring to me to know that I was not alone in feeling overwhelmed by the amount of information that I need to attempt to gain an understanding of. The strategies in the Reading List pattern are sure to help me in organizing and creating a plan for learning new software development techniques and improving my skill set. Setting goals and prioritizing what I read will allow me to use books as a tool rather than simply being overwhelmed by what I don’t yet know.

 

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.

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.