The Learn How to Fail Apprenticeship Pattern is a relatively simple, and yet extremely important pattern to keep in mind at all stages of your professional journey. It states that we should learn what we are not good at, learn where it is that we fail, and learn what parts of that failure are worth learning how to fix and what failure we must just accept as something that we aren’t good at and move on to improve the things that are worth improving. It is about learning what behaviors, conditions, or habits lead us to failure, and learning how to get around them or just accept them for what they are.

I really liked the idea that they brought up about keeping a list of your skillset in your own personal wiki, that way you can always see what skills you have, and what skills you are losing over time. This way you can choose what is worth continuing to work on, and which skills are no longer useful to you. This is such a pivotal step to continuous self-improvement and learning that is a common thread throughout all the apprenticeship patterns. We need to be able to identify our weaknesses and learn why they happen so we can improve, and I think this is a really good way of going about it. I also really liked their action plan, writing code in a simple text editor, writing tests for it, and revising it without ever compiling or running it until it is perfect. I thought this was a really good way of testing yourself and finding the weak points that will follow you throughout every project you work on. I know that I have some weaknesses in my knowledge base, and some habits that will lead me to failure and moving forward I would like to take note of them and work on them as they come up in the future. I accept that failure is inevitable, but continually working on those failures and allowing myself to learn from my mistakes will make me a better developer.

If I disagree with anything in this pattern, it would be that you should drop things that would take a disproportionate investment of time and effort to accomplish. I think that sometimes, even for a little improvement, it is necessary to sink way too much time and effort into certain things that are fundamental or are extremely important to a project. Not all the time, but it is important to be able to make that distinction for yourself and figure out what is really needed to improve, regardless of the cost.

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.

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.

Rubbing Elbows is very closely related to Kindred Spirits. The idea is to actively observe the way people around you work, and to seek out people you can learn from. Most of the pattern is centered around pair programming, and it is certainly a very good example of Rubbing Elbows. When pair programming you want to find someone more and/or differently experienced from you. This will give you the greatest opportunity to learn; if you only stick with what you know and are good at, you will never grow as a developer.

This is actually something I am very excited to do. When talking to my classmate about potential job prospects, he suggested to me that I should do a remote job. I am very against this idea. I want my first job to be one where I am physically in the office surrounded by other developers who can help me out if I need the help. Pair programming is something that really appeals to me, especially if my partner is more experienced than me.

I worked at an internship where I was the only programmer. There was one other older guy who did programming, but he was mainly an engineer. I tried my best to learn from him, but the environment was not a professional development one. Working alone, I was not able to consult other people and could not determine if what I was doing was correct.

I cannot wait to enter the workplace and learn from other people. Rubbing Elbows is a great pattern, but honestly did not do much for me. I already wanted to meet people and learn from more experienced developers. In fact, when I wasn’t able to collaborate with others was the worst feeling ever. I think that I did good work, but cannot know until other people look it over.

My biggest fear as a developer is doing things wrong. There are many ways to develop software, and there are many ways to mess it up. I need the guidance offered by others; maybe not explicit guidance, but guidance nonetheless. Having someone to consult and learn from is one of my main goals as an apprentice. I am so new that I do not know what I don’t know. Rubbing Elbows with more experienced developers will help me along my path.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.

Kindred Spirits seems like a good pattern if not taken forcefully. This pattern is all about joining a community of developers who have similar interests and/or skills to you. As an apprentice, your main goal is to learn. Working in a professional environment will not always provide this environment, and the mentors you gain along the way will have their best interests in mind – not your own. This is why it is important, as an apprentice, to seek out communities that you are drawn towards because they all have the same motives as you. The goal of these communities is to learn and experiment, and they will be the best place for you to do the same.

To be completely honest I had no intention of doing this prior to reading the pattern, and still am against it. I get why it is good, and I am not against having friends of course, but I am not sure I want to join a community. I guess the point is that you only go when you want so I could just abandon a community I don’t like. Like I have said in previous blog posts, I do not want to focus on programming as a hobby. I do enjoy it, and I am not against joining a programming community if I want to, but I am not the type of person to code for fun all the time.

That being said, I do see the benefits of Kindred Spirits. Of course it is good to have friends in the industry with similar goals, and I do plan on making friends. Having someone to talk to about something I am working on will give me a new perspective and may solve a problem, and helping someone else will test my knowledge on what I actually know. They say the best way to learn is to teach, and to have someone ask me a question I supposedly know the answer to will help me as much as it helps my friend.

Overall, I do like Kindred Spirits. Friends and community are always a benefit. I don’t like the feeling of being forced into friendship and community, but I don’t think that’s what the pattern is saying. I believe it is saying to keep yourself open to new opportunities, find people who you get along with, and use your fellow apprentices to your advantage.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.

Christian Shadis

In the apprenticeship pattern Concrete Skills, Hoover and Oshineye explore the importance of developing discrete, demonstrable skills with specific technologies. This is an important pattern to implement as a young programmer because often in the hiring process, your skills are often more surface-level, and your value lies in your potential. Developing concrete skills makes you a more valuable candidate and thus more likely to receive an offer.

This pattern makes a lot of intuitive sense. My skills (outside of specific languages) are top-level, and I do not have a lot of projects to demonstrate specific skills and value that I can immediately provide to the company/team I am joining. Currently, my appeal as a candidate lies primarily in my successful academic career and ability to quickly learn, and secondarily in the skills I already possess. In order to successfully find a job, supplementing my portfolio is necessary.

This pattern coincides well with the Breakable Toys pattern in that building those personal, low-stakes projects will allow the developer to demonstrate their skills in a discrete, specific, and demonstrable environment. The toy can then be used in the hiring process, or to develop a demonstration for the hiring process. Having that project available to demonstrate during the interview process will reassure employers that not only does the candidate have potential to contribute greatly as time passes but can also contribute immediately.

I hope to use this pattern throughout the next several months while trying to secure my first career position. I have identified the biggest weakness in my resume to be my lack of full projects to display my skills. I have worked on multiple programming projects that I can use, but they all seem too simple to truly impress a hiring manager. I have a great academic record, but little to concretely prove my development skills. In conjunction with the Breakable Toys pattern, I will look to develop a full-stack project over the coming months that I can add to my portfolio and increase my chances of being hired.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Emptying the Cup. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern talks about how software developers should stay in the trenches. As software developers gain experience, they tend to gain a reputation for being exceptional at delivering software. Many organizations tend to reward with promotions in the hierarchy. However, such promotions might end up leading apprentices away from their craft. This pattern elaborates how apprentices should not confuse promotions into management with success. Being promoted might seem like a good sign that you are on the right path, however, one should understand that they will not remain a “technical” manager for long.  A craftsman who strays from their craft will have their mastery over it fade. The more time you spend not programming, the further away you are moving from being a journeyman.

If an apprentice wants to remain in the craft, then they need to draw their career map accordingly. For example, one could try to discuss with their employer the possibility of finding different mechanisms which they may find rewarding. This could come in the form of higher compensation, or it could come in the form of nontraditional technical leadership roles such as internal consultancy. In the case where the employer is inflexible, then perhaps it might be best to look at other opportunities elsewhere. This way you will remain in the craft and prevent yourself from being promoted away from it.

I personally think that this apprenticeship pattern is useful for people with a specific set of values. It is useful for anyone who values their passion for staying in software development and wants to stay active in the craft. If you are someone who loves software development and want to continue However, some people might value things like status, compensation, and greater responsibility more than remaining active in the craft, and therefore, going into management might be the right move for them. Since different values can lead to different career paths, it is important for software developers to constantly reevaluate their career map to see whether the path that they chose is aligned with their values and circumstances or if they need to consider a different path.

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

This week I would like to look at the “Confront Your Ignorance” pattern. I feel like this is always a good one to look at as despite how good of a programmer you might be, there is always something more to learn, and there is always something you don’t know.

This pattern means there are things you still need to learn/know, and some of these things are things that many others may already know, so it is expected of you to also have this knowledge.

I feel like it is always important to confront your ignorance, as there is still much to learn, even when you have seen a lot. This pattern is very similar to the “Expose Your Ignorance” pattern, but this one is about learning in private, so you do not need to hurt your pride by making others aware like in “Expose Your Ignorance”. However, it is still important to know to expose that ignorance as well, since always learning in private can have some negative side effects, like having failure be unacceptable instead of just another step of the learning process. You need to be able to learn and grow in a way that will positively affect you and those around you.

But should you choose to not learn in private, a great way to confront the ignorance is to ask questions, as many people may have already had the problem you are currently facing, and are hopefully happy to help you overcome the issue. A common cause of ignorance is focusing too heavily one one particular skill or context, which causes you to become ignorant of the other skills. One must be able to learn, and identify the areas of ignorance, and actively work towards reducing those areas.

You must also always be able to admit your faults, in this case admit that your knowledge is lacking, as how will anyone know your knowledge is lacking unless you tell them? This way, everyone can work together to achieve better learning. Of course, it may hurt your pride in the short term, but it is always better to be known for your willingness to learn more, than to know a lot about a few things.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.