Until I can obtain a job, I will be working by myself most the time. This will inevitably impact my learning because working with others allows shared knowledge and experience for the parties to teach each other. The “Rubbing Elbows” pattern from Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman discusses the benefits of collaborating with others.

The pattern mentions “Pair Programming,” a technique where developers code side-by-side. I have not coded in this manner in a long time. When I took my first computer programming class my best friend and college roommate was also taking that class. Given the circumstances, we often collaborated on assignments. While we did collaborate, we often coded the assignments solo and discussed our methods and problems. I cannot count the times that one of us would get stuck with an issue that the other had no problem with. I learned then that different programmers will find multiple solutions and methods while developing. These diverse techniques are worth examining and potentially adopting.

“Pair Programming” is not the only way to practice “Rubbing Elbows.”

“The goal is to find ways to expose yourself to the daily working habits of other skilled people, and observe the ways in which they gradually refine those habits into even greater skill. These habits extend beyond coding and into all aspects of software development.”

This statement from the pattern shows the type of knowledge the pattern will provide. “Rubbing Elbows” is not necessarily about learning new coding methods but about observing the small, often unmentioned details of a developer’s work habits. Because of this, developers can rub elbows by working on any part of the development process, including presentations or papers.

Working in LFP’s update module team provided plenty of learning opportunities for me. Some opportunities were coding related, while others were about project management.

I have a couple ways planned for practicing this pattern. Now that I am graduating, I think this would be a great time to collaborate on a project with my friend again. We have not worked together in years and this seems like an opportune time. He has been working in development for awhile and I am sure he has a lot for me to learn. I also plan on participating in the LFP spike-a-thon this summer. This will let me work on something familiar while presenting opportunities to work with other developers.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

I will hopefully be starting my software development career soon, and with that I will be joining a new team. Dave Hoover’s and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman’s pattern “Sweep the Floor” suggests “volunteer[ing] for simple, unglamorous, yet necessary, tasks” to contribute to the team. I will be one of the least experienced members in the team, so I’ll need to be proactive working on the more tedious work. Doing these tasks is more than just gaining trust from the team but also showing respect for the more experienced members. The experienced members should be focused on the work that requires their experience and not bogged down by simple chores.

“Examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.”

While it may not be fun work, these tasks are still important, and the team will be grateful for the effort. To practice this pattern, “Sweep the Floor” suggests finding the tasks that the team has been putting off and do them. The pattern however warns of the potentiality of being perceived as incapable of more vital work. This can be averted by working on more complicated issues or personal projects alongside the simple chores.

When reading through the list of example tasks, I could see the tasks that often held up work during our LFP sprints with code review being the biggest culprit. I can see how completing these tasks would be good to focus on when joining a new team. Not only will the team benefit from these tasks being done but completing these tasks will also give valuable insight into the project. With code reviewing, the opportunity to study the unfamiliar parts of a project is presented. Work on the documentation was also often put off or forgotten.

I think this pattern makes sense having the inexperienced members handling the simpler tasks. These tasks are chores to the experienced members of the team but are learning experiences for the inexperienced.

The pattern includes an experience of a developer working in a formal software apprenticeship. The important part of the story is when the apprentice watches Uncle Bob Martin, a master craftsman, take out the trash. The apprentice’s mentor then scolds the apprentice for allowing the job to go undone and having a master craftsman take care of it.

“It is not the job of the master craftsman to take out the garbage.”

This pattern has made clear what I will need to focus on when entering a new team as an inexperienced developer. I will need to find the simple, more tedious jobs and work on them while furthering my learning. “Sweep[ing] the Floor” will help with my integration into a team by familiarizing myself with the code base and team practices. I will also build trust with the other members of the team. Once I gain enough experience and trust, I can then start to work with more complex, interesting work.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

I have no professional developer experience yet, and that can make starting a career difficult. To make up for the lack of experience, I will need to procure and maintain some concrete skills. Concrete skills demonstrate the ability to utilize knowledge. The apprentice pattern “Concrete Skills” from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye, addresses the usefulness of concrete skills when seeking a career.

“If we hire you today, what can you do on Monday morning that will benefit us?”

This question from the pattern makes clear what a concrete skill is. Businesses are not looking for someone with just knowledge, they are looking for someone who can do the job. It is important to practice some concrete skills with current technologies and frameworks so I can hit the ground running when I start a job. The pattern lists several examples of skills to explore: basic web design, JavaScript, open source frameworks, build files, and a language’s standard libraries.

The pattern suggests collecting CVs, Curriculum Vitae, for respected developers to find out what kind of skills to practice. The CVs will contain the concrete skills of those developers. With this knowledge, I would only need to choose which skills that would be immediately useful for my desired career path. The pattern then suggests creating toy implementations of the chosen skills for practice, which then can be used as examples in interviews.

 “Concrete Skills” advises going through one’s own CV and find all the discrete skills. These skills are the only information many hiring managers will look at, according to “Concrete Skills.” This makes having demonstrable skills a necessity when looking for a job.

The pattern, “Concrete Skills,” seems like common sense, but I think it is an important point that needs to be stated. It is easy to lose yourself in the studying of development techniques and forget to polish the skills you already possess. The lesson this pattern is trying to teach is summed up nicely by a quote from Pete McBreen’s Software Craftmanship: The New Imperative:

“Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications. This is where craftsmanship comes in.”

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

My work over the semester has required me to explain what I have learned to my teammates. My explanatory skills are not great, but I have been able to make do with the help of live examples. Chances are likely that I will need to do this continuously throughout the future. Since this is an important skill, I will need to practice my instructive capabilities. Luckily, the pattern “Share What You Learn” from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, by Dave Hoover and Adewale Oshineye, addresses this problem.

“Up until now, you have focused exclusively on your own improvement as a craftsman. To become a journeyman you will need the ability to communicate effectively and bring other people up to speed quickly.”

“Share What You Learn” discusses the reasons for passing your knowledge to others. Ethically, it is wrong to only receive knowledge from the community and never give any in return. Being able to capably communicate your knowledge will make you a better developer. Teaching knowledge requires a deeper understanding of the knowledge than just using it. Also, other apprentices may appreciate an explanation from someone with the same level of abilities.

The pattern warns to be sure that the knowledge being shared, can be shared. It is common for companies to keep trade secrets, including software development information, so be careful.

There are a few ways listed for practicing “Share What You Learn.” One way is to write blogs about projects you are working on. The act of writing down your methods will make it easier to remember the details later. Another is to try writing a tutorial for a topic, presented in a way that you wished the topic had been presented to you. Lastly, imagine preparing for a workshop at a conference and how you would prepare for presenting your work.

I must agree with this pattern’s assertions, I believe being able to pass along knowledge quickly and clearly is an essential skill for software developers. As I have experienced this semester, I am not skilled with this pattern and I feel it has impacted our work to some degree. As such, I will need to practice “Share What You Learn” to be a better teammate and developer.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

With the final sprint of the semester underway, I have had to learn several new technologies for our LFP microservice over the semester. This has led me to obtain only the necessary knowledge to move forward in the project. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman,by Dave Hoover and Adewale Oshineye, has a pattern that addresses this problem: “Dig Deeper.”

“When you read a tutorial, you should not be looking for code to copy but for a mental structure in which to place your new knowledge. Your goal should be to understand the historical context of the concept and whether it is a special instance of something else.”

The apprenticeship pattern, “Dig Deeper,” discusses the downfalls of having a shallow knowledge base and the need for obtaining a deep knowledge of how the tools and technologies work. There are several advantages to having this level of understanding, including: improving confidence, providing a starting point when joining a new team, and improving interview skills. The pattern refers to programmers with this knowledge as “cathedral builders.” These “cathedral builders” can debug, decompile, and reverse-engineer code. The best way to obtain this knowledge is to read specifications and familiarize yourself with debuggers.

The need for this pattern’s practice is like the need to learn history. Learning the history of a tool or technology will prevent repetition of previous mistakes and illuminate the reasons for the inner working’s current state. In addition to learning the history, it is important to dive into the different layers behind the tech and learning how the system works as a unit.

I realize my current understanding of the technologies I have been using for our LFP microservice is shallow and now, I have a direction I had not thought of looking into yet, debuggers.

A problem I have with this pattern is deciding where to start, as any time used to dig deeper is time that cannot be used for learning a new tech. This problem will likely resolve itself, though, once I decide upon a career path. For now, I can just dig deeper into our LFP microservice’s technologies: MongoDb, Node.js and its packages, angular, docker, and all the testing frameworks.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

“Use the Source” is a pattern from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern focuses on the need for reading code written by other developers. Some good sources of code to examine are open source projects. By examining source code, a programmer can see what their bad habits are and adopt new, better habits. Another benefit from code reading is learning new algorithms to solve different kinds of problems. Expanding one’s collection of code solutions allows a programmer to be flexible and able to solve more problems.

I found this pattern particularly interesting. Since programmers are constantly required to work with other’s code, it is imperative that they learn to read code efficiently with practice. I do not have much experience with this myself and this pattern has made clear how important reviewing other’s code is. Regardless of what career I pursue after graduation, it will be important to read code effectively. I will need to start looking into some open source projects so I can improve my skills. Now I just need to find some projects that I contribute to and am interested in.

“Use the Source” suggests contributing to open source projects for software you already use. This is very helpful advice to me; I use a lot open source software.

• Atom: text editor
• Eclipse: IDE
• Insomnia: REST client
• GIMP: image editor
• Several different game system emulators

I briefly examined some of GIMP’s source code. GIMP has a label on issues for newcomers, allowing for quick access to simpler issues.  After reading through some of the code, I realized that it would take a great deal of time to get an idea of the project architecture.

I looked at this issue, (https://gitlab.gnome.org/GNOME/gimp/issues/4128), and thought it seemed simple enough problem to start with. While the problem seemed simple, I could not navigate the repository and locate where the problem may be. GIMP is significantly more complex than any project I have worked on before. Ultimately, I was not able to make any headway on the issue. I was, however, able to read through portions of the code and begin to see some of the structure behind the it. Though I did not find what I was looking for, I did get a basic feel of the code’s flow.

As stated in Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, developers read far more code than they write. With that being the case, “Use the Source” is an excellent way to grow your code reading skills.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.