The first question that interviewers ask candidates these days is about team experiences. They look at many different factors but working as a team is always an important one. If that person cannot work with a team, that is going to be a red flag. There is a saying that “if you want to go fast, go alone. If you want to go far, go together”. Team work gives people the ability to improve their communication skills, to be more efficient in building products and also to motivate each others.

We may have mentors and kindred spirits that we meet along the way, but people tend to think that software developers usually work independently. The problem is what if the product has reached its limit, the learning is struggling and the feeling that there are superior techniques and approaches to the craft that are eluding us.

The best solution is to find a way to sit down, have a talk with colleagues, and work together on a project. There is always something that we could learn from each other. The case that was mentioned in this “Rubbing Elbows” is Dave, who found an ally in Roman and then literally rubbed elbows over lunch as they learned together about technologies like the Ruby programming language and Eclipse plug-in development. Even though Roman could have not been that kindred spirit but Dave would still have benefited by working next to a talented programmer. There is always a certain technique that we could learn from others because we are not perfect. Therefore, it’s critical for us to be open to learning and willing to take it in. While paring programming can be an excellent technique for learning, it’s a complex activity and is not always an inherently positive experience. And sometimes it is a pain. If we feel chronic behind, week after week, and we’re beginning to despair, then it’s time for a change. The rotation may help jiggle us out of trouble. Ping-Pong programming to increase our participation is also a good way.

The final thought is to find someone we know who has already expressed an interest in starting an open-source project. Spend one day or an evening a week working together on that project. See how things would go, and seek motivation from each other. If motivation never return, it is up to us to seek new partnership where we can learn new thing. Because the best way to stay in workforce of this industry is to keep up with new technology.

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

During the job interview that I have had. There is one question that I ask most recruiters which I believe is essential for job seekers who are looking for their first job. Deciding whether to work at that company, the question about the culture of a company is important. I think that if a company with a toxic culture and working environment, it would discourage the employees. There is this saying by Paul Graham “Nothing is more powerful than a community of talented people working on related problems”. In this “Kindred Spirits”, the author thinks that organizations’ cultures that encourage software craftsmanship are rare which I also think is true. Every day, tech workers complain about the working culture in big tech, that it’s not how they think it was when they first applied for the jobs, and that their jobs demand more time than just 9 to 5. So, I think that having a good culture is not only good for employees but also makes sure having better productivity.
The solution for those people who work in toxic culture is to be in frequent contact with people who are walking a similar road. Therefore, we should be able to seek out people like ourselves who are also looking to excel. The long road is not a road that anyone walks alone and especially in our early career, we should have a mentor. On the other hand, the culture encourages a safe environment for exploration and learning, a culture that does not limit its employees in what they should learn and that they can feel free to show each other what they’re learning to tend to attract more talents. Having no obligation to follow others’ lead would interest workers to explore and not be afraid of risk-taking. However, despite the benefits of a community of like-minded folk, we should be aware of groupthink. Avoid the questions that shock our community. Try to be respectful and use intellectual thinking to keep the community healthy. The culture and the community around us can be measured in the way it reacts to new ideas. Whether it embrace the idea after the intensive debate and experimentation? Or the ideas are quickly rejected? The most value we can provide service is defending it against those who believe that marching in lockstep is the price of membership.
To be able to do so we need to join the community where the people we work with, the blog we read, and the ideas we are intrigued by are respected. We can create our community but don’t be too strict on the ideas and topics too early. Advertise anywhere that software developers in our area might see it. Over time, these would pay off, as the group becomes larger and energetic enough, it will sustain itself even when we are not there. That’s when we have a community, good culture, and a non-toxic environment.

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

There is always a good teacher behind a good student and a good engineer needs a good mentor who will help sharpen the skills and knowledge of that person. There is a saying “if you want to go fast, go alone. If you want to go far, go together”. Together with the mentorship, the engineer will become skilled at his job and has solid fundamental knowledge in this field.

By learning from the best, we learn how to become one of them. The apprenticeship will be supervised by a series of mentors who possess varying degrees of mastery. Every master used to be a student and no one is perfect. So keeping in mind that a master must be perfect is a misconception. It can be tempting to feel that way because they know so much more than we do. We must resist the temptation because we would not want to disillusion our mentor’s inevitable weaknesses.

The story about Dave finding his mentor shows us his journey. By sending out a random email to his mentor, Wyatt, he initially did not expect Wyatt’s response however Wyatt did. The effort was a payoff and he earned himself a mentor. What we could learn from this story is that we should not afraid to ask for help because sometimes what the other is waiting for is us asking.

Good mentors are not easy to find and not everyone is willing to open their arms and welcome us as amateurs. Plus, reaching out to someone that we do not know feels intimidating. However, the risk of being rejected is low but the payoff would be huge. Even though that person does not want to become our master but if we are consistent enough, what we could get back is a good friend. Besides taking in, passing along what we have learned from our mentors is one of the ways in which we can begin the transition to journeyman status.

How could we do that? One must wonder

Choose a tool, library, or community that has an active mailing list. Start small by signing up for the list but do not post any messages yet. Gradually, we will understand the values of the community and learn which of the subscribers are patient teachers. Seek out the members of this list the next time we see them and ask if they would be interested in providing us with some advice about the lesson they have learned. As I said above, we might get rejected but the valuable gift that one might earn is a good friend.

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

Warren Buffett once said: “The stock market is a device for transferring money from impatient to the patient”. However, I’m not going to discuss stock trading or how the stock market work. This post will concentrate on the similarity between the stock market and software craftsman is patience.

The world that we are living in focuses on overnight celebrity and ephemeral success. The majority of people these days talk about quick rich schemes. Developers back in old days were passionate workers who loved their jobs and dedicate to them. Developers nowadays get into this field because of the tremendous total compensation at big tech like Amazon pays their engineers up to 200 thousand, Netflix is 400 and Roblox is 1 million.

The problem is developers aspire to become master software craftsmen, yet the aspiration conflicts with what people expect from them. We are blinded by the money and promotion package. The job once was to deliver quality and secured pieces of software. But now we tend to distribute soon enough to secure that bonus or to meet the deadlines which allow us to have those bonuses. We sometimes sleep on the job and forget our purposes.

So, what is the solution? Be an outsider. Thinking outside of the box. Focus on the long term rather than get rich quick scheme. Value learning and long-term growth opportunities over salary and traditional notions of leadership. The outcome would be better with a rich set of abilities. We eventually become skillful at learning, problem-solving, and developing healthy relationships. We should keep in mind that it would be a long journey hence we should have low expectations and let them influence the jobs we take and drive the ambitious. Have a strong mindset and “can do” attitude.

With the entire career devoted to the craft, it becomes realistic rather than vain to think about surpassing Bill Gates or Steve Jobs. The opportunities will open as the time comes and we should make sure that when it comes, we will be ready. And the important thing is to love the work that we do, do it with our heart and passion.

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

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.

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.

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.