The Craft over Art Apprenticeship Pattern describes how despite us as software developers wanting to make artistic code, we must always prioritize utility over artistry. It is important to make code that serves its purpose over code that is technically challenging or code that has extra features. If we aren’t meeting what our customers want then we are no longer craftsmen.

I think that this pattern is pretty important to keep in mind. I often find myself trying to make code that is interesting or that I think will do a better job than what I am being asked to do, but this sort of over-engineering is not what isn’t what I am being asked to do. Despite wanting to do what I find more fun, the needs of the assignment or customer come first. Function over form. Most of my friends are artists, and my dad is an artisan over being a craftsman, so to me, this isn’t something that comes naturally. Moving forward, I need to make sure to keep in mind that what the customer is asking for is what they want, not what I think would be better. I really liked the emphasis that they put on utility as being paramount. Something that is technologically brilliant but has no utility is ultimately not the job of a craftsman, and not really what we should be looking for as software apprentices. They aren’t saying that we shouldn’t still strive for beauty though, which I am sure I will never quite be able to shake, but just that we need to prioritize the function. I think that this mindset will serve anyone well, especially in this profession. People that can’t listen to what the customer wants won’t last long in any professional field.

I do disagree with the idea that all software must be crafted for utility though. Technologically brilliant software, beautiful software, has a place and is ultimately important to the future of this profession. If developers never thought out of the box to create something truly amazing, we’d still be living in the dark ages. But I do agree with the overall point of function over form. Even in that mindset, however, I think that we should take creative liberties when it is appropriate, and allow ourselves to be shown in our work. Much like the world without art, code without beauty is miserable.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

The pattern I have chosen this week is the pattern about being the worst. This pattern is all about the situation you are in and the mentality you have. The idea is that you shouldn’t find yourself in a position where your learning is stagnated due to how good your team and that you don’t push yourself to learn because of this. You should instead always have that mentality of where you need to learn and continuously improve or else there will be problems down the line.

The pattern of being the worst was quite an interesting and relatable read to me. The idea of staying in the mentality of “being the worst” in which one is always trying to catch up to their peers around them. I usually like to see myself as the worst one in the team and that I have a ton of work to do to catch up and to improve myself. This does have its risk if you are actually the worst one in the team and causing issues to the team and yourself as it says in the reading. The pressure of being the person holding the team back sometimes look unsurmountable in which one just needs to keep a cool head and keep working hard on improving. In my current team, I have the same feeling of needing to improve to make sure that I am not holding them down.

The action of willingly joining a team to be the worst member instead another team that you might provide better benefit to right out of the gate is an interesting idea to think about. It can be hard to keep such a mentality up for every team you join and other people around you might be skeptical on your process and just try to put you on a different team you they think fits you in better. It’s as it says in the book being a selfish decision in which you might be bringing the team down for your own gain so it is important to contribute as much as you can to help mitigate this.

From the blog CS@Worcester – kbcoding by kennybui986 and used with permission of the author. All other rights reserved by the author.

The pattern I decided to read is titled “Nurture Your Passion” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that I think best summarizes this pattern is the one that states, “The people who walk The Long Road are not the heroes who sprint for a few years and burn out—they are the people moving at a sustainable pace for decades.” I really liked this quote because I’ve heard so many stories of young software developers who do amazing work at their first couple of jobs, but suddenly stop working because they are not feeling fulfilled. I think part of the reason for that is because many software developers enter the field and work themselves to the bone without really thinking about the “why” behind their work.

The reading adds that the jobs can foster a highly competitive, fast paced, and toxic work environment that further leads to developers burning out. The reading provides some potential solutions to this problem:
1. work on something you like
2. seek out kindred spirits
3. study the classics
4. draw your own map
5. set boundaries

One of the most thought-provoking things I took away from this reading was how by setting boundaries in my first job as a developer, I may get passed over for pay raises, promotions, kudos, or popularity. But on the other hand, by taking care of myself I am less likely to burn out and have a more sustainable career.

Therefore, I would say this pattern has indeed caused me to change the way I think I will work in my profession. While I want to be seen and known as a hard worker, I also think it is important for me to be mindful of how I am working and find balance.

Overall, there isn’t anything that stands out that I strongly disagree with. In fact, this pattern alluded to some other patterns that I am now more interested in learning and reading about to help me make sure I nurture my passion as I enter the software development field.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

This week, I read a pattern called Find Mentors. This pattern may occur with every apprentice when they have no ideas of what to do during walking on their own paths. So, finding a mentor is a good solution to help apprentices become more confident to walk on their paths. It is because you can easily learn a lot of knowledge or experience from your mentor who have gone ahead of you. However, this pattern also emphasizes that everybody have to walk on different long roads, so apprentices should know that “no one knows everything”. When you have a mentor, you need to resist the temptation of expecting your mentor to be a master of everything. Instead, you should  have a proper behavior to show your respect or appreciation for what you have been taught by your mentors.

Furthermore, there are many different types of mentors. One of the luckiest case is that you can find a mentor who can watch your development, talk to you and teach you face-to-face. On the other hand, there are many cases where your mentor is not physically available. However, you can certainly gain knowledge by reading their books; or you can also get inspired by their achievements, their stories, or their speeches. Furthermore, besides finding a mentor, an apprentice can also become a mentor to other apprentices at a lower level. That’s how an apprentice performs his transition to a journeyman.

In my opinion, Find Mentor is one of the best shortcuts when it comes to your long road because an apprentice can inherit many lessons that are available without him having to fail as many times as his mentor to get it. However, I agree with the author that it is very difficult to find a mentor that fits what you want to learn and is also willing to guide you. So not many people are lucky enough to find a truly mentor to take a shortcut. On the other hand, I also agree with the author on the point that apprentices can also find their mentors who are not physically available. I believe that, through this concept, the author suggests many other easier ways for apprentices to find a mentor. As for myself, I want things to be easy, so I choose to learn from people who are willing to teach me or give me advice to solve my problems. Furthermore, watching tutorial videos on social media is another way that I find my favorite mentors.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

The Breakable Toys describes how to set up a situation where you can continue to learn and make progress with your career without unduly affecting your performance as a developer on your “day job”. The idea is to create a home-based work environment where you can develop product to enhance your skill set by making small products on your own. If these fail, or turn out to be flawed in some way, there is no downside, because you are expected to have learned lessons on your own. Although most work-paces are reasonable when your coding doesn’t come out perfect the first time, it certainly is much better for your career if you develop working, useful, optimal code in a reasonable time frame.

Many developers don’t have the time or inclination to do this, and turn out to be productive employees, but those who guide their own career by making their own products on the side are much more likely to succeed both intellectually and financially.

Throughout my career, I have always been motivated to keep up with the current journals, attend classes and conferences, and to always have a product I was developing on my own. In the 1990’s I developed a music-based utility program for guitarists called “Guitar Companion”. It’s most impressive component was a notation editor, but it also had a metronome, tuning fork, band manager component, and 3 CD’s with Video Guitar Lessons. I wrote it in Visual C++. But over the years, converted it to new technologies, and sold it through a website I had constructed fo4r this purpose.

From 2010 to 2015, I developed a number of Android applications for musicians. The one that turned out the best I sold on Google Play and had over 20,000 downloads.

This was all great for my career growth, but I would have never done this if I were not passionate enough to put in the time and effort. I highly recommend this approach to anyone who really loves to code. You are your own CEO. You call all the shots. You become sought after by companies, because you have developed depth in your code base that few can attain working under the strict protocol of working for someone else.

It also works in reverse. I would incorporate functionality into my “Toy” products that I learned at job-sites, as well as using things I wrote at home into my work products. It is pretty great when a boss asks during a scrum “who knows how to do X”, and you raise your hand. “ I do”.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

For this week’s blog post, I decided to review a chapter about a topic that I have thought about a lot. The topic that I am reviewing this week is the importance of mentors and finding kindred spirits. For those of you who does not know what a kindred spirit is, a kindred spirit is someone who shares your interests or attitude about a topic. I find this topic interesting because it is a topic that I have thought a lot about. In the past, when I was a Mathematics major, I felt like I had found a lot of kindred spirits. I used to spend a lot of time in the math lab and center solving math problems with these people. When I think back about those days, I view it as some of my most productive years in my undergraduate career. I used to be very studious and was very motivated to be in school. As people within the group graduated one by one, I found myself at a loss and became very unmotivated. This is why I found the first segment of the section interesting because it talks about the importance of finding kindred spirits in order to stay motivated. One line from that section that stuck to me was the line about the impact of having a relationship with a kindred spirit. Some relationships may be short but may make a major impact in a person’s life. This was how I felt about the relationships I formed when I was a math major. The time I spent with those people may have been brief but the time we did spend together did feel meaningful and I would not have had it any other way. One thing this chapter has changed is how I thought finding new kindred spirits. After the last of the group graduated, I tried finding other kindred spirits in those who were still there, but I did not feel that same connection. So, I have always tried finding kindred spirits by physical vicinity. I have always thought of myself as a follower so one thing that the chapter brought up that I never really thought is why don’t I just a start a group of my own. This thought was something that went over my head and is something I think I may consider some time in the future.

Another topic that the chapter talked about is the topic of group thought. I think this is a very relative issue that needs to be addressed when thinking about creating a group and I think there should be precautions in place to ensure that the group can still have healthy debates.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

                We all grew up with a favorite toy at some point or another weather that be a doll, a car, bike, computer, lego, etc. At one point or another they may have broken in some way and when that happened you could either throw it out and be done with it or attempt to fix it or find another use for it. This is exactly the idea behind the breakable toy pattern described in ‘Apprenticeship Patterns’. As a software craftsman many workplaces will leave little room for failure and thus little room to learn from those failures. Many of us in today’s workplace are expected to know how to use tools given to us without time to experiment and fail to use those tools.

This aversion to failure often stunts the learning process in many people as failure is one of the best teachers there is. Being able to safely fail in a private space where you can learn from and fix your mistakes at your own pace is healthy to the learning experience. Breakable toys are essentially an implementation of a commonly used tool that you may be inexperienced with. This toy can be simple as long as it applies to your work, your life, and is pleasing to work on. As Hoover and Oshineye describe in ‘Apprenticeship Patterns’ you can create anything from a wiki page, to games, to even a calendar or even blogging software.

Creating a breakable piece of software that won’t affect anyone should it break gives you the opportunity to experiment without worrying about failure while reinforcing what you do or do not know about a certain tool, giving you a sandbox to play with to deepen your knowledge of said tool. Our toolsets are always changing as software craftsmen and being able to keep up with this quickly evolving trade is arguably the most important part of being a software craftsmen. I whole heartedly believe this to be a great place to create breakable toys as I have with my own website.

If you are turning up few ideas of what you can do then consider the idea left at the end of this chapter by Hoover and Oshineye. Create a wiki page for yourself, it can be about whatever you want and start as simple as being able to edit plane text documents. Over time as you learn more about Web Design, HTML, and other tools involved you may add features that will distinguish it from other wiki pages. Keep this breakable toy or create new ones as you learn, so long as you allow yourself to fail you can take advantage of it and enrich your own experience.

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

I feel the need to underline that the patterns discussed in the book “Apprenticeship Patterns” do not exist in a vacuum, though conceptually they can be considered as independent concepts. In fact, it is possible, in one way or another, to utilize multiple apprenticeship patterns at once without realizing it. In my latest post, I briefly went over the apprenticeship pattern related to a programmer’s first language, aptly named as “Your First Language”. Looking back on my learning approach to C (my first programming language), I notice that my learning process included a combination of this pattern with other patterns named “Record What You Learn” and “Breakable Toys”, which former pattern I mentioned briefly in my first post about the book “Apprenticeship Patterns”.

As the name of the pattern suggests, “Record What You Learn” is a pattern that is mean to address a software developer’s (or a learner’s, regardless of the subject) potential negligence of making sure to keep a record of the concept’s that they may encounter during the learning process. Such negligence brings the risk of the developer losing important knowledge, thus facing issues when they encounter a problem, they need to solve for which they have an extremely vague idea, at best, of how to find and implement solutions.  In this case, a helpful solution to this problem is for the learner to begin developing and maintain the habit of keeping records of anything that they learn as they learn it, either on a blog or wiki. However, it is important for anyone who records their learning process in such a way to make sure that they actually utilize what they record continuously rather than simply dump their thoughts in a blog post and immediately forget what they were supposed to be learning in the first place.

In my own experience, recording what I learn either in the way of making private journals or code repositories has helped me in my learning process tremendously. On one hand, keeping an organized archive of concepts I have learnt, along with specific sources and examples (not too different from this blog), has made it easier for me to quickly go back and refresh myself on knowledge that I feel I can use for problem-solving. Moreover, going through the process of writing a journal of the things I learn helps me internalize new concepts much better, especially with respect to code. Perhaps this pattern is especially helpful for people like me, who need to write down what they learn since it is a much more helpful way of learning.  

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.