For this week’s blog post, I have decided to look at the apprenticeship pattern “Unleash your Enthusiasm”. 11this chapter is all about you as a programmer being very excited about the craft of software development. However, you find that you are holding back and being more enthusiastic about the work your colleagues are doing. Fear not, as your enthusiasm and love for the craft does not go unnoticed. Because of your inexperience, it brings some unique attributes to the team, including that infectious enthusiasm and an unfettered imagination. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“In any group setting, there is a tendency to conform to the norm, particularly for newcomers. Most teams are not hyper-passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain. Therefore, enthusiastic apprentices can often succumb to the urge to fly under the radar. They either repress their enthusiasm altogether or allow it to manifest only outside of their day jobs.” (Dave H. Hoover, Adewale Oshineye Pg. 22).

Essentially because of you being a newcomer you tend to try and acclimate to the rest of the group and start to lose that newcomer enthusiasm and begin to try and become unnoticed. The yare risks however that come from unleashing your enthusiasm. One of these risks are that if the morale is low or the team is not welcoming, you will likely get some eye rolling from your enthusiasm.  Another risk that could come from unleashing your enthusiasm is depending on the team, they may not enjoy that you are exposing your ignorance and where your knowledge stands.

From reading this chapter I found it to be an interesting take on when you begin working in a job setting with a new team. I liked that in the chapter it talks about both the positives and negatives of unleashing your enthusiasm. Although this chapter did not really change the way that I think about programming and my enthusiasm when I would get a new job. Knowing who I am as a person and my personality, I am not one to “unleash” my enthusiasm on a new group of individuals, so I don’t see this chapter as being helpful in that sense. However, if I were to train a newcomer and they brought this enthusiasm to the table, I now know what they could bring to the table, and I will not disregard it now.

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

There are many critical systems that have no room for failures, such as banking software or a hospital’s patient management system. It is difficult to experiment with new features or try a new approach when a piece of software is heavily relied upon. In order to experiment with new things, you need to have a test environment where you can try out features. If these features turn out to be harmful or cause problems down the line, they will not affect the current user version of the software. Creating a playground environment allows you to not worry about breaking changes or failures cousin headaches for program users and other developers. Software that is a breakable toy means it is that something can be played with, broken, and replaced without impacting anyone else. It is a way to learn, test new workflows, and ideas.

It is hard to clone and play around with code when there is a complex system that requires a database, client, server, and other resources for its operation. Because of the work and resources to create a clone of an existing system, I would not have created a second replica of the system in the past. However, this pattern makes a strong enough argument for me to put in the effort to make a breakable system for testing. I thought it was interesting a breakable toy can also be a personal project where you are the only one who uses it. I thought of this almost like a programmer’s diary where you program your ideas in private and you are the only one who sees them.

I currently program with a pattern similar to breakable toys but on a smaller scale. When I want to add a new feature into a codebase, I make a testing branch where I can execute that idea. In my ‘toy’ branches, I do not have any intention of merging the code into the main branch, I only use it to play around with an idea to see how it might be executed. I do not disagree with any aspect of this pattern, although it is good to also be comfortable working in an environment where you have to be careful about the programming you do could have a major effect.

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

Chapter Two’s is themed around growing your knowledge. The pattern “Confront Your Ignorance” follows this theme and focuses on working with projects that are outside of your expertise. When you feel as if each project you are working on is like the previous one, it means you are applying your existing knowledge. There is truly little chance to grow as a developer when you work strictly within the areas you are knowledgeable about. The ideal scenario is one where you are working outside of your area of expertise to maximize the amount of new experience you engage with.

In the future, I will be more willing to work on projects where I dive into a topic that I do not fully understand. I also feel that the action for this pattern, to map your projects in a timeline, is a useful way to track your personal development over time. A timeline is a terrific way to see if your learning has stagnated and it is time to jump into something new. This method is also a great way to see where you want to take your professional career and give you an opportunity to map into the future.

I found it interesting how large of a risk the author suggests taking regarding a project outside of your knowledge. It is suggested to work on projects where the possibility of failure to complete them is high. In a private setting, I would gladly challenge myself by deep-diving into a project that I do not feel confident I can complete. In a professional setting, I personally am a bit too risk-averse to immediately want to take on a task where the chance of failure is greater than my chance of success. However, I appreciate that it is a gamble where if I do succeed it will boost my portfolio and whether I succeed or fail I will walk away with more knowledge than I started with. I believe it is human nature to be frightened of failure. This pattern is a great reminder that the journey that led to failure was along the way a great learning experience and the following attempt will be a success based on what you had learned.

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

Back when I was a kid (actually until now), I have been really into playing video games. It could be the reason why I chose Computer Science in order to be able to create games, a popular reason just as many of my colleagues. I somehow was able to land a spot at Ho Chi Minh City University of Technology, a flagship in technology teaching and research activities in Vietnam, after the high school graduate exam.

By the start of the school year, I had nothing but excitement, my only experience was some rough foundations of Pascal taught in high school and I barely remember anything from it. On the other hand, my colleagues were students from the very top high schools with a program concentrating in what they desire, which were mostly computers and the others had extra programming courses outside the class. Besides, the program was designed for students who already had experience with programming since the syllabus of my programming introduction class is a C++ class consisting of both functional and OOP methods with two huge projects. As a result, I was totally “destroyed” in this intro class while my colleagues, having a hard time, but managed to get through it.

Since my excitement was demolished, I had a hard time thinking about my major choice. I did not have any problem doing the required calculus, linear algebra, physics classes but my computer introduction class was a disaster. I was not able to unleash my enthusiasm, I did not know what it was, what I did at that time was grinding myself painfully to be “better”. In my opinion, we tend to be afraid of discussing or expressing something we are not familiar with, and for my case, I cannot show my professor my problem because of it.

After a few years since then, I would say that the syllabus for that intro class was still overwhelming for new students. However, for students who already had their based knowledge before taking that “intro” class, it’s a good opportunity for them to review before going into the main courses. If only I knew how to inject my excitement into my work to ask my professor about my problem, my learning would have been much better, wouldn’t 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.

For this week, I read the pattern of Craft over Art. This pattern occurs when beauty takes precedence over utility. However, as a craftsman, you need to make your crafts become useful instead of beautiful.  One of the most important factors of being a craftsman is accepting that you are not an artist. Your job is not to create beautiful and fantastic things to satisfy your artistic creations. Your job is to create a craft which can serve the needs of others and meet the minimum standards of quality. The higher the quality, the more time it takes. Each level of quality always require the trade-off between beauty and utility. So, you have to know what to do with the customers’ requests; and you must be able to balance their desire on the products by telling them what to prioritize in a particular period of time. Moreover, as a craftsman, you need to ensure that you are always willing to deliver the best products to satisfy your customers’ needs. That willingness does not depend on your current feelings or inspiration because you are not an artist, you are “supposed to earn a living at your craft”.

In my opinion, I totally agree with the idea of this pattern, Craft over Art. I like this pattern because it is practical, it tells me what I have to do to create value as a craftsman, which is to make my crafts useful, not beautiful. If you are an artist, you have to create beautiful things for people to admire your creations; but if you are a software developer, who will admire your creations, but useless? When your code does not even work, how will people know the beauty of your creations.

Therefore, I always prefer a simple program, “fifty-line game that makes someone smile”, over a complex program, a million-line game but unplayable. I have also used this pattern when starting to learn something new. My real life example is that when I learned to write a game in python language, I chose the simplest game to imitate and learn from. That is because I know exactly what my goals are. I just want to understand all the basic steps to write a game. The simpler the game, the easier it is to learn. I chose to learn the basic but useful for my understanding instead of the complicated stuff but I learned nothing from it.

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 apprenticeship pattern Expose Your Ignorance is about the importance of feeling comfortable with showing your ignorance. Asking questions is how you learn and shows that you are good at understanding. The difference between an expert and a craftsman is someone who broadens their range of knowledge rather than only sticking to digging deeper into a single domain. The action the author recommends is to write down your

The quote included in this pattern from David H. Hoover was thought-provoking. “I actually had grown attached to feeling ignorant on a daily basis; it let me know I was in the right place. I was growing.” The quote reminded me of the Daoist view of yin-yang where on one side there is chaos and on the other side, there is order. To grow as an individual, you need to be in the middle of the two. As Hoover’s quote says, feeling ignorant means that you’re exposing yourself to new material and are learning. If you never feel challenged, then you are not doing anything new and therefore not gaining new experiences. If you are uncomfortable with feeling the unknown, then it means you are uncomfortable exposing yourself to new things.

This pattern made me realize it is not only okay to be in the presence of the unknown but that it is also necessary for personal development. Personally, I do not act as if I know everything or that my solution is always the best option. I make what I know heard but leave plenty of room for others’ opinions. There are times when what I recommended is ignored and then later those recommendations are then incorporated into the project. It is better for that to happen naturally than for me to force my ideas into the project without the full acceptance of the other people involved. I do not disagree with anything in this pattern, I agree with the author fully on his opinion.

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

Continuing from last week, “Confront Your Ignorance” is also the next section in the book where I find some similar patterns to my current state with the context of identifying gaps in my skill set.

According to what was written

“There are tools and techniques that you need to master, but you do not know how to begin. Some of these are things that everyone around you already seems to know, and there is an expectation that you already have this knowledge”. 

The only difference is not everyone around me seems to know it, except the YouTube algorithm, but I should meet the team’s “expectation” to have my part working on time. The situation can be described as I currently have a sample to refer to my work, but I do not want to abuse it because if I do so, I learn nothing from it. It feels like I can understand everything in the sample, I’m still curious on how it was done and since the programming language is too versatile, is there other way that I can do it without “copying” the sample?! Since the sample has a good structure and is written in a comprehensive manner, I would happily learn it, but the code, I don’t think I can write it that good just by looking at the documentation.

I consider myself a competitive person and sometimes my curiosity makes me feel unsatisfied in many cases. I always want to be as good as that “person” in a particular situation and when I can’t, the feeling is quite uncomfortable. Hence, I think my biggest ignorance is trying to achieve too many things but not concentrating on a certain topic. A solution was given in the book, it’s also obviously the only way for me to get rid of my bad habit, which is to strive to learn each one, maybe in important order.

In conclusion, I think it’s not bad at all to have so many interests at the same time, but I should figure out which one I should prioritize learning it first. Back to my current problem, I think I would go over the commit history to see how it was initially done and proceed from there.

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.

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.