There is a saying that “if you love what you are doing, you will never work one day in your life”. Software engineer/developer is a job that requires patience and passion. Without passion, people would easily give up their work.
As I mentioned in “Sweep the Floor”, we need to willingly work the job that no one else would do as we first start to learn and to improve our knowledge. But there is a side effect to that. The side effect is that we work in an environment that stifles our passion for the craft.
In whatever situation, we would always need to look back, take a moment to think of our true passion for software craftsmanship. To become an excellent developer, we will need to have a tremendous passion for what we are doing. However, under some circumstances such as deadlines, corporate hierarchies, or bad management. It is hard for developers to grow under those conditions.
Finding something at work that interests you where you pour time and effort into it. Considering some extra time outside of work to build some Breakable Toys to help expand the knowledge. As Paul Graham said: “The key to being a great hacker may be to work on what you like…To do something well you have to love it. So to the extent that you can preserve hacking as something you love, you’re likely to do it well”. If we do something with love, eventually things turn out really. We build better software with great quality.
Start a weblog and read blogs. Write about the topic that interests you. Doing that also not only helps you to learn new techniques and technologies but also could become your side hustle. Participate in online forums such as Stack-overflow by answering questions that others might have. Read thoroughly others’ answers to learn more about the material with different approaches.
To grow your passion, set clear boundaries that define the sort of environment you are willing to work in. This means in some situations you leave work early, walk out of a meeting that becomes abusive, adjust your attitude, and refuse to distribute your code if it does not meet your minimum. Eventually, the result could be bad for pay raises, promotions, kudos, or popularity. But keeping these boundaries helps to keep your passion strong.
Needless to recite what I have said in the beginning about passion. In my opinion, passion is the only thing that keeps you moving forward, eager to learn, and the desire to explore. You would not need to work a day in your life if you work with passion.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

This Apprenticeship Pattern is about constantly reading books pertaining to the subject of computer science as to supplement your real-world hands-on experience and as to not stagnate your learning. By not only learning through on-the-job experience or personal project experience, and having a few different routes of learning, you enhance your overall knowledge of the subject. This way, you also avoid stagnating your knowledge, because if for your job you are repeating the same or many similar tasks, then you aren’t really learning anything, or are just learning very little. This is because when you do the same thing over and over, you don’t really have to think about it anymore, and a lot of it is just automatic for you.

By reading constantly, you are actively engaging your brain to focus on new material. The great thing about reading is that you can do it anywhere, and at any time. Anytime you have spare time in the day, it is easy to just read for a few minutes and learn something. Also, by not reading it for very long periods of time, you avoid losing focus on the material, and instead can focus on the material in shorter, more manageable bursts.

I really like this suggestion because I have a lot of trouble sitting down and reading something for long periods of time. With your phone, computer, tv, etc. there are many distractions that draw your attention away from whatever you’re trying to focus on. This can make actively trying to read very difficult, but by doing it in whatever free time you have, you can avoid the distractions and help focus on the reading. I much prefer reading, or anything that requires sustained attention, in short bursts rather than long marathons. In short bursts I can ensure that I keep my attention on topic, but the longer I do it the more my attention dwindles.

The only thing I disagreed with was the suggestion to only read books, and not blogs or other resources. While I do think that maybe being online and not having a physical book may increase distractions, I also think that there are many great educational resources online that are invaluable. In my opinion, the thought that some things must be learned from books is outdated and could maybe even hinder learning. Everyone learns in different ways, so by suggesting that everyone try to learn from books doesn’t make sense to me.  

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

Everyone starts from somewhere. Nobody knows what they are supposed to do when they first start to do something at their new jobs. They start from small tasks with little experience to more challenging tasks with better experiences in knowing what they should be doing. Gradually, they become an expert and do their job better. “Sweep the Floor” shows us how developers should lower their expectations when they’re fresh out of college and take on simple tasks rather than picking up experiment ones.
The problem shown in this section is we are pretty much unsure of our place in the new team and the team would not know what to expect from us. This might cause bad consequences due to under-performance and bad communication. The solution for this problem is to willingly take on volunteer work. This does not mean taking on any kind of work but should be the work that improves our understanding of the team, the work, and gain experiences. A great method is to show that we could do a high-quality job even it does not seem to matter in some way. An example of this is one famous for his work as Uncle Bob Martin who volunteered to come into a room and took out the trash. The task seemed unfair and jaw-dropping for such a developer, but this job brought him admiration and devotion. However, acquiring an easy task does not mean that we should skimp on quality which might lead to trouble later.
Another problem is that some people think they are better than others due to their educational background. The hard truth is at the workplace, that does not seem to matter much. Workplace and school are contrasting when it comes to real life. You might do good in school but it does not guarantee you would do as well at your job. Having better education means higher expectations for you on the first day.
Yet, there are consequences for taking on an easy job. We might become the team’s gopher who get assigned the tasks that no one else would do. From that, we are unable to take on more challenging assignments. The better way is to advocate for yourself and look for every opportunity to prove yourself worthy with higher-level work.
After all, we should take on the tasks that everyone complains about, do it and do it well. Because that is the only way to show people that the can-do attitude and exceed people’s expectations.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

In breakable toys of Apprenticeship Patterns, the authors clarify that developers should have room for failure, and failure makes greatness. Good experience is built upon failure as much as success like in the saying “Rome was not built in a day” which means there is no overnight success. Mistakes are made, but learning from mistakes is a way to help us gather deeper knowledge and also aid us in collecting further experiences.
What was interesting in Breakable Toys was the close bridge between learning and failing. Failure is part of a software developer and without failure, there would not be a great developer as well as great software. What I agree is developers should be given space where they can seek out failure to train their mindset and to develop their practical involvement. The example was Steve Baker (a teenager working in Nova Scotia), people looked upon him as a leader and an expert within his small development organization. Thus, he could not afford to be wrong and obviously could not walk away from his people who were depending on him. The solution that he later found out was using a breakable toy. Breakable toys were the tools that he used to help him learn by failing.
What I have learned is that when implementing the breakable toys pattern, I should make the system relevant and useful to my life as an apprentice. The examples were building my projects such as a to-do list or expense tracker. At first, the solution would somehow be overengineered and failed. Yet, these are the type of projects that were designed to be backslid without any bothersome. They are used to develop my ideas and techniques and could be a disaster but that is a part of learning. By building these projects, they give me a deeper understanding of designs, data structure, and language. Furthermore, not giving up on problems would help me eventually get them right. Beyond constructing things myself, consider team efforts as one of the alternative ways of learning.
The point that the authors try to make in this chapter is by building things will help developers learn better than listening to plain lectures. Allowing space for failures is a way of improving and expanding knowledge as well as experimenting to learn deeper and to understand thoroughly.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

The most significant part of the learning process as a software developer is putting the knowledge that I have acquired over time into actual, practical use and create something tangible that is a good representation of what I have learned. While it is important to have a good grasp in the theoretical aspect of my craft, it will do me absolutely no good if I do not actually exercise the skills I have acquired, especially when I need to use them in a professional environment. However, it is not just the act of simply practicing any acquired skills that is important. What is also important is to know how to properly apply the skills in real situations. For example, simply knowing how to code in theory is simply not enough on its own, it is also important to experiment with the acquired skills as part of their learning process. In this case, the pattern of “Breakable Toys” is introduced.

When a developer chooses to utilize “breakable toys” as part of their learning process, it means that they are working on personal projects that, although they are detached enough from a professional environment so as to minimize the risk of failure, they have enough functionality so as to maintain the realism of working on an actual project that needs to be delivered. Essentially, a developer creates a functional project on which they can experiment on and use any potential mistakes that may occur along the way as valuable ways of reflecting on or enhancing their learning process. The developer gets to reap the benefits of hands-on experience with none of the risks of  that would come up if their inexperience were to result in failure while working in a professional space. However, it is important to note that “breakable toys” in programming does not mean that the practice that you put on is discarded immediately after a developer has a better understanding of the problem they practiced on. Rather, “breakable toys” that are broken should also be recorded with the same importance as spike solutions that work flawlessly.

This particular pattern is a favourite of mine as it combines the pattern of “Practice, Practice, Practice”, which I always enforce in my own working career ad-nauseum, as well as the pattern of “Record What You Learn” since even small projects that were made on a whim may still be valuable enough to return to later. However, a significant aspect of this post’s pattern that aligns with me is the focus that it puts on actual hands-on experience, which is more valuable to me than endlessly reading documentations that I may never utilize.

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

The pattern I decided to read is titled “Expose Your Ignorance” from chapter 2 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts with throwing out a hypothetical problem where the reader is working for an employer that is expecting the reader to deliver a product but the reader is unfamiliar with the required technologies. The solution to this problem is in giving an honest response and building a reputation on your ability to learn rather building a reputation on what you know. This pattern also mentions how asking questions is a great way to expose your ignorance because you show what you are learning to your teammates. The pattern ends by discussing how exposing your ignorance is a trait of walking the long road because it means you are open to learning unfamiliar technologies and new domains. Whereas, experts tend to narrow their scope of learning, practice, and projects by specializing in specific things.

There were two instantly helpful pieces of information I gathered from reading this pattern. The first useful piece of information was how as I work on becoming a software craftsman, it is more useful to be known for my ability to learn things instead of being known for the specific technologies I am already familiar with. This piece of advice immediately affects how I think and how I will speak about future projects.

The second thought-provoking piece I read was how becoming an expert is a by-product of the long road I am on. This absolutely blew my mind but also humbled me because I should have known this already since I use a similar perspective for exercising in the gym. My goal of living a long and healthy life means that as a result I will have strong muscles if I am regularly going to the gym. I think one of the reasons this was so striking to me is because I feel like I have such a long way to go before I feel confident enough to call myself an expert in something. Therefore, hearing that becoming an expert is a by-product of the long road showed me how long this long road really is for me.

Lastly, there isn’t anything significant in this pattern that I disagree with. It was an enjoyable pattern to read and one where I learned some valuable information.

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

Malcolm Gladwell published a book about him analyzing how the practice has helped successful people succeed with the 10,000 hours rule. One of the sections in Apprenticeship Pattern Guide for Aspiring Software Craftsman ensures the similar point that practicing is an essential key in making a software engineer become better.
What I found interesting about this is the connection between some of the points in this section and Malcolm Gladwell’s in the “Outliers” are Malcolm shows that practicing was among the factors that led to the Beatle’s success and Bill Gates himself. These people had been able to manage practicing days and nights to the point that they were quite comfortable with the materials similar tools no matter what or where.
Taking the time to practice your craft without interruptions which means to the point where the mistakes are what we are comfortable with as it is mentioned in the Apprenticeship Pattern Guidance . I found it very interesting of how these two authors have the same perspective of spending more time practicing and confronting the problems. Ultimately at a critical time, we might run into those problems again, and being able to solve them would save us time and sources.
To be honest, I’m not a fan of lectures therefore sitting over a lecture in college is somewhat an achievement to me and I’m more like a hands-on person. Fortunately, that is one of the good ways to learn as a Software Engineer.As it was referred to in the book, a beginner should learn by doing rather than reading and sitting through lectures. Besides that, doing and repeating exercises helps us sharpen our skills, our minds, and our bodies to react to the disciplines. Another excellent point in this section that I found helpful is writing a lot and writing code often would help us develop neurons reactions in a good way.
Open to feedback is introduced in this section as well which I completely agree with. Being able to get feedback helps us determine whether we are on the right track. But part of me finds this odd because not everyone could get a good mentor and not everyone can give you good feedback. This also often is hard for people with small circle of relationships and connections. Relying on someone else feedback without knowing ours own issues is not a wise choice.
What I learned from this is finding an exercise and sticking with it until I could solve the problem on my own and then observing the solution that I have made over time as a programmer would have a measurable impact on my abilities to solve any problem later in my career.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.