“Craft over Art” was a great apprenticeship pattern to read about and I found myself relating to the ideas with my own work. A craft is an art that has functionality – a painting you can look at and hang on the wall, but a table or couch provides you with functionality. Good software should be written so it looks good and performs is purpose.

When constructing a piece of software it’s important to look at the tools we are going to use. A programming language, a laptop or PC, a good IDE, Unit Tests, and an outline of what the system should look like. No one starts a craft such as furniture building by grabbing a piece of wood and one by one assembling the project. They first create a blueprint with measurements, a model, and gather all necessary materials before they begin following their blueprint. I enjoy this analogy because I’ve made this mistake in the past when writing code. I would usually go line by line and fix mistakes one by one as I find them. This way of writing code is quite slow and it can be easy to drop a project because it seems too large or difficult. Now I follow a plan when I write my code and even if a method I’m working on has issues, I’ll move on to the next method. I’ll also create my methods before hand and leave them empty until I begin working on one to ensure I’m still following the system I designed for the project.

Art is also an important factor of crafting. If my code is messy, unorganized, and does not have good flow it will be incredibly difficult to refactor the code later on. When we enter the workforce it’s unlikely we will be writing a piece of software completely on our own. Your code will be combined with dozens and hundreds of other programmers work and it’s important that the system works well together.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

This week I really enjoyed reading “The Long Road” from the apprenticeship patterns. In computer science, often many of us feel like we need to learn as much as we can in the four years we are getting our degree and then go out and apply that in a full time position. The reality is that we only learn the basics in our undergraduate degree – enough to gain strong logic and critical thinking skills and enough to get that first job. The real learning comes from actually working as a software developer and there is no “end” to how much you can learn in software engineering.

The tech industry is constantly evolving and every two years it seems like there is a shift in how technologies are used or new technologies are introduced. A software engineer cannot stop learning once they have learned everything it takes to perform their programming job well. Skills they learn in that job will always carry over, however they may end up working with completely different or newer frameworks and they have to start the process of learning again. That’s why as software engineers we should have the mindset of “always learning” rather than “learning something new when needed to”.

From the blog CS@Worcester – Site Title by lenagviaz and used with permission of the author. All other rights reserved by the author.

I had the opportunity to participate in a formal summer program to learn how to make simple websites. When I was twenty-two years old, I was hired and brought me back every summer and winter vacation during college. I didn’t know anything about how to make a website when I started my first project. For fun, I wrote some code to make small programs and scripts. There were few places where I could add value to the company’s operations when I first started my website for that program. I couldn’t build a website, and I couldn’t possibly teach people how to do so.

Many of the successful Programming leaders were hired by the company to teach a PHP course at the time. Since I was not good enough, I decided to start working on other tasks. I’d also set up the computers, install the appropriate software for the exercises, and clean up the space. These duties helped me gain confidence in my ability to contribute to the team and the firm. Even though I was having difficulty learning to code, I was still able to contribute with specialized talents and duties that required less competence.

As I was continuing working on the program, I was gradually given more technically difficult jobs. They were, however, frequently the ones you’d allocate to the lowest man on the totem pole. Moving servers, setting out backup methods, and updating material on the website are all tasks that need to be completed. These assignments allowed me to achieve little triumphs at a time when it was difficult to achieve them by creating code.
Playing the part of a typical program taught me humility and respect for experienced trainees. I decided to choose to sweep the flooring partner because it resonates with everything in my previous job experience.

It’s true when Paul Pagel described young apprentice like One of the pillars of a successful apprenticeship is humility. Humility, when combined with ambition, will keep you focused and moving in the right route. You risk prematurely declaring your apprenticeship complete and missing out on critical lessons if you don’t have them. Perhaps you’re pleased with a large project or subsystem you’ve completed and believe it demonstrates that you’ve progressed to the level of journeyman. Perhaps. Have you, on the other hand, delivered something important across several platforms? How much more would you learn if you attempted to learn a new language? The natural tendency of any ambitious apprentice is to attempt to beat the clock and become a journeyman as soon as feasible.

From the blog CS@Worcester – Site Title by proctech21 and used with permission of the author. All other rights reserved by the author.

According to Atul Gawande, Software is not a product, it’s a medium for storing knowledge. Therefore, software development is not a product-producing activity, it is a knowledge acquiring activity. Knowledge is just the other side of the coin of ignorance, therefore software development is an ignorance-reduction activity.

The value of failure-based learning is undeniable. Organizations that excel at it, however, are extremely rare. This disparity is not due to a lack of desire to study. Managers in the vast majority of the companies such as pharmaceutical, financial services, product design, telecommunications, and construction firms; hospitals; and NASA’s space shuttle program, to name a few—were genuinely interested in helping their companies learn from failures and improve future performance. They and their teams had spent many hours on after-action evaluations, postmortems, and other similar activities in certain circumstances. But, time after time, we noticed that arduous efforts yielded no tangible results. The reason for this is that those managers were approaching failure incorrectly. 

As a former manager myself, I always thought about what my boss would say if I did not meet all the requirements left out for me to accomplish in a tiny window. I overstress myself to succeed, and by trying too hard, I kept getting crashed over and over until I realized that was not the best approach. I never got the results that I was looking for with that mindset. Failure is hard to accept because we usually associate it with a negative aspect instead using it to learn and produce success for tomorrow. As I was told if you never fail, you don’t know what success is. 

As Phillip Armour, in his paper “The Five Orders of Ignorance,” As I paraphrase it; Continuous learning can either be a blessing or a curse. Learning a new skill may be excruciating, especially when done under duress and with no supervision. However, the software developer, like the athlete who must deal with bodily fatigue after intense workouts, must deal with the mental dissonance that comes with learning something new. That discord might be viewed as a positive indicator of growth. On the surface, self-reflection, detecting failure through feedback loops, and discovering your deficiencies all appear unpleasant, yet these patterns are helping you lessen your ignorance. The alternative is to concentrate solely on what you already know, but this is not the path to mastering software craftsmanship; rather, it is the path to specializing in a single field. 

From the blog CS@Worcester – Site Title by proctech21 and used with permission of the author. All other rights reserved by the author.