This apprenticeship pattern discusses the risk of finding yourself the strongest member within your team, and stunting your learning possibilities. To be the worst means to always surround yourself with developers who are stronger than you whenever possible. This can continue to encourage your learning growth, and make you realize you are capable of things you did not know you could achieve. While there are many positive to being the weakest member in a team, there are also many risks. A high performance team will most likely expect you to be able to keep up with them when they are working full blast, and if you do not have the knowledge or skills available to consistently keep up with their pace, you run the risk of getting fired or kicked off the team. There is also the risk of ruining your confidence level. For example, if you were the best developer in your old team or job, and suddenly get thrown into an environment to where you are simply not the best anymore, it can be damaging to your self confidence, which can then decrease motivation and the drive to learn and achieve new things. To accomplish “being the worst”, it is good to make a list of all the developing teams that you are aware of, and rank them based on their skill level. Then identify who is accepting new members who want to advance in their skill set. This process would require looking at different departments than the one you are currently in, as well as different companies. It is always wise to keep your mind open to new opportunities when compiling these lists. It would be a good benefit as well to join mailing lists or other services that will keep you updated on new positions available.

In my experience, I have always felt I was not the strongest developer in no matter what team I found myself in. I always felt that there was at least a single person who way beyond my performance. Instead of letting this drag me down however, I followed closely to what the stronger individual was doing and how they operated in order to learn more and increase my skill. I always did my best to learn on my own when I needed to so I would not drag the team down. I felt that I was not just merely a passenger on the team, and I was bringing valuable information and skills towards the projects we were completing. In some aspects, I actually was the most proficient in a certain task and I did not even realize it, and that could be contributed to having been surround by such strong developers in my past. It is important to keep advancing your learning so that you are able to perform and produce the best quality products for customers, and surrounding yourself with individuals who are a higher skill level than you will increase your chances of becoming the best in your group, restarting the cycle and starting back at looking to become the worst.

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

This apprenticeship method is closely related to Expose Your Ignorance, but instead of just simply identifying what you don’t know, you learn those topics. Reading this method expanded my thinking about how to go about learning within a team environment. The article describes that there is a detrimental difference between incorporating your learning in a positive way and a negative way. The negative way can appear in a few different ways, mainly an individual doing all of their learning in private, not sharing their experience with other individuals who also are learning the craft, and the risk of creating niche products and tools that only you are able to use and understand. This could lead to frustration and other issues within your team, and drive the team towards a “fend for yourself” mentality. It can also lead to individuals stagnating in their learning, causing them to not really care when a problem occurs within the code that is someone else’s issue, since they did all their learning in private.

Exposing your ignorance can also appear in positive ways as well, which is the ideal goal. After identifying what areas of knowledge that you didn’t know, one positive method would be to seek out other individuals that also want to learn, and learn together. Applying this to my life, I am luckily in that situation with my team on the Libre Food Pantry project. We all are working on the same issues together, so we are also learning together when we solve the issue. We are all learning chai together and how the docker containers interact with the rest of the project. And when one individual is working on an issue by themselves, they explain how they got to where they are in the code and let everyone see the inner workings of the code. By doing this, the team will all be caught up on how to work on a particular issue, and there won’t be any frustration when a team member is not available for the day.

When I begin my new job, I will already have taken in my list of topics that I want to learn about. The next step would be to seek out other individuals who are also wanting to learn the same topics that I do, and discover them together. Working on “breakable toys” as a team will give everyone the opportunity to use them without hassle. Also seeking out mentors and senior leaders who have experience in whatever topic we are striving to learn will help, as they can show us what they have learned, what mistakes to avoid, and how to effectively apply the knowledge to a team environment. It is important to always keep your team in the loop whenever you are learning a new topic, and to keep learning and seeking out new things to learn.

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

This blog posts discusses the issue of individuals at their work place dealing with the expectation that they are an expert in their area of work. In regards to software, this is a difficult issue to tackle, as new innovations and technologies are pushed towards software developers rapidly. It can be hard to catch up to all of the new ways of doing tasks and creating code, new IDEs that the company is enforcing software engineers to use.

Personally, I relate to this topic. Growing up, I was always the “tech guy” in my family, helping my parents and everyone else at family events. This gave me a false sense of confidence when I started college, and I realized how little I knew in the world of software. With this little knowledge though, I still felt I had to maintain my sense of “expertise” when I was with my friends and family. When I was in class however, I was in awe of how much the knowledge of software I did not know. This idea can also apply to the workplace. I would assume that when I do start my new job, I will be with other recently graduated software engineers, and everyone will want to make their mark. Who would want to work with the new grad who didn’t know how to work in a certain language? This way of thinking is created by the idea that in the corporate world, its everyone for themselves.

When I start my new job, I will try to keep the mentality that I can always learn more when I am working on a project. The reading describes a method of writing five things that you don’t know, and keeping them in the open at your workstation so other coworkers can see it, and to always refresh the list. Working on the Libre Food Pantry project, I already have most of my list assembled for that project. The list includes: chai syntax, inner workings of docker containers, and the CI pipeline. This list will obviously change when I transition to a new work environment and new projects, but the idea will stay the same. Keep refreshing the list of new things that you want to know more of, and keep it out in the open and “expose” your ignorance. Its ok to not know everything in a certain field, that what experience does. It helps you develop your skills and become a better developer.

Another solution is to just simply ask questions. The more direct the question, the quicker you’ll find yourself becoming the person that answers those questions. As stated before, it’s difficult to ask questions, especially when you are brand new in a project. You are expected to be able to handle yourself and not rely on anyone else, and if you do rely on anyone else you are just a hinderance to the project.

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

The introductions of the chapters gave a really nice and simple outline in the different ways to expand your learning and tools that are available to be a better apprentice. It also defines what it means to be an apprentice, or journeyman or master, and where the origins of the listed apprenticeship patterns originate from. The most useful section I found was the section explaining that without discipline, we would let ourselves be constantly distracted by different things in our environments so that we would avoid work. I felt this applied heavily to myself, as when I do work from home I find myself easily distracted by different things. My cats jump on the desk and want attention or Discord notifications ringing in my ear. After reading the section, I realized that I do not actively attempt to get away from those distractions and will end up spending time giving attention to my cats or responding to my friends on Discord. I need to attempt to disengage from these distractions when I am trying to work so that I can produce quality work, and not something that when I look back upon it I will be disappointed. Another introduction that I found heavily applying to myself was the section regarding self assessments. The reading notes; “You must be willing to let go of your perceived competence and allow yourself to recognize that you have traveled only a short distance on The Long Road.” I feel that I can get lost in my abelites and my limitations, and I will either take on too much work at once or not enough work, or that I will become too confident in myself, not realizing that I have only scratched the surface of a certain topic or skill. Reading this made me realize that I need to constantly be aware of what I can and can’t do, and if that I am ahead of my fellow apprentices that I need to not become over-confident, and maybe help guide them along the way so that they can accomplish certain tasks as well. All of these apprenticeships patterns will create a better teamwork environment.

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