Category Archives: Week 4

Reflection on the Craft over Art Apprenticeship Pattern

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.

Apprenticeship pattern: Being the Worst

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.

Apprenticeship Pattern: Nuture Your Passion

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.

Find Mentors- blog 4

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.

Apprenticeship Pattern “Unleash Your Enthusiasm”

What I have found interesting is about this apprenticeship pattern is that those who are enthusiastic about the work they do might not fit into their future team. It is a worrisome thing and that although there are ways to nurture your skills outside of work, most people tend to look at work as a way to work with others and expand their knowledge in software engineering. I had never thought that being enthusiastic could be detrimental to a team, but it makes sense that already existing teams probably do want to deliver on projects and their work instead of helping someone new out. It was nice to read that teams that are comfortable with themselves do beneficial from a fresh new mind and injecting them with excitement and questions will be beneficial to the team.

What I found most interesting when reading about this pattern is that as a soon to be graduate, we have the most excitement about the future of growing in our careers and that this pattern tells us that it is time in our careers to take the most risk and to speak our mind. We have very little to lose staring out and our ideas and passion will be more beneficial than detrimental to our team. As an apprentice, expressing ourselves is what we should be doing and it’s healthier for us to grow as a person that way. Instead of worrying about fitting into a future team, we should worry about being that spark that brings new ways of improving the team.

I as a person am very enthusiastic about everything I do. It does worry me that I might not fit into the team I work with in the future, but I hope that everything that I bring to the table is something that can help everyone. This pattern does make me thing about how important it is to work with my team and that hopefully my enthusiasm as a new graduate can help elevate my team to the next level. I also have experienced times where I have brought up ideas to engineers and then they shoot me down, but I had never thought about asking about how to improve my suggestion instead of just letting it go. This solution is a great way to figure out how to do better instead of thinking that your ideas are not good enough.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Post #2 for Apprenticeship Patterns: Perpetual Learning: Breaking Toys

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.

Expose Your Ignorance

Next week, my second Sprint will start. My team worked really well last Sprint that we met all the initial objectives; however, the context was we reimplemented something that we’ve already known or heard about, which only needs a bit more searching in order to fully commit the work. This second Sprint we are going to have lots more “abstract” topics, materials that we weren’t familiar with, so I expect we might get frustrated, overwhelmed when we come to it.

This situation might somewhat be similar to what I’ve read in the “Expose Your Ignorance” section, the only difference is that I’m not in a nine to five working environment. Per description from the book, we have been brought in some projects that we are unfamiliar with some of the required technologies; but team members believe that we can deliver because we have a deep understanding of the business domain or some other aspect of the technology stack being used in a team, or perhaps we are the only person available to do the job. In my view, learning and implementing what the team needs while carrying their expectations is difficult, especially when it is something that we have no experience in.

Finding myself falling into this issue in no time, I might consider taking the solution written in the book which is to show my teammates that the learning process is part of delivering software. Therefore, knowing how to learn the technology effectively is important because I should know which part of my current project will need this and go straight to documentation with relevant information on it. Furthermore, asking questions, instead of hiding our issues, exposes it to everyone in the team because no one will be annoyed when we show them what we cannot do, instead, not telling them that you are having problems is what keeps the team behind.

Luckily, I consider myself a bit “figurative” when it comes to asking questions since I don’t mind asking anything that I didn’t understand. Compared to myself 3 years ago, it’s a huge difference as I was that shy guy hiding my weaknesses, I find learning is much more efficient when I can ask everyone what I don’t know, of course, after a period of time thinking and testing and implementing. Having questions is a good practice, but it doesn’t mean that we should ask without already researching it.

From the blog CS@Worcester – Vien's Blog by Vien Hua and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Kindred Spirits”

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.

Apprenticeship Patterns: Breakable Toys

                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.

Craftsmanship Log #2 – Recording What I Learn

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.