Monthly Archives: March 2022

Apprenticeship Patterns: Be the Worst

Christian Shadis

In the apprenticeship pattern Be the Worst, Hoover and Oshineye explore the dynamics of skill level on a team as a software apprentice. They assert that while it may seem counterintuitive, it is a better plan to not be the strongest developer on a team, for that situation yields less opportunity for growth and learning. However, if you are surrounded by accomplished developers who are more skilled, there is far more to learn from them, and far greater space to grow.

Be the Worst, like The White Belt, seems to go against the average worker’s intuition, and are somewhat related to each other. One might think that being the ‘big fish in a little pond’ is a surefire way to distinguish yourself from your colleagues and get promoted, or maybe compete for more prestigious jobs. However, being that big fish increases your chances of stagnation. If you are already at the top, there is nowhere to go, and you may find yourself plateauing as a developer. It is more beneficial to contribute to a big pond and be a little fish, because the little fish can learn and grow more, and eventually start to grow larger than the fish around it, and eventually may become the biggest fish. Combining this pattern with The White Belt by accepting new methods and techniques unfamiliar to you will maximize learning potential at any position.

This pattern is likely to be rather difficult to me, having gone to a small high school and university, and finding myself as one of the “big fish” in both. It would be very unnatural for me to be the worst member of a team, but it would catalyze the learning process and motivate me to become a better teammate (or even the best). In turn, that growth and learning will open opportunities for more interesting and lucrative positions in the future.

I hope to use this pattern throughout my career, but more specifically I plan to implement this pattern at my first development job. I plan to work at a large tech company, and that company likely would hire largely candidates from more prestigious computer science backgrounds, with more dense portfolios and extensive experience. I could perceive this as a disadvantage in the job market but utilizing this apprenticeship pattern instead would motivate me to improve my contributions and prove myself as a competent and evolving developer.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Accurate Self-Assessment. 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.

Be The Worst

Sometimes being the worst is not the worst thing to be recognized as. It can be a scalable thing. In sports for example, being the worst player on the Boston Celtics may seem like a bad position to be in. The reality is that your skills are far more impressive in comparison to the average person who watches basketball, and you should give yourself more credit for even making it into the league. The “Be the Worst” pattern is one that allows those who exercise it to never remain stagnant. While it is nice to admire yourself for all the progress you have made along your journey, you should not bask in these accomplishments for long periods of time.

There have been many times in my life where I’ve felt like I’ve done all that I needed to do and “now I can just chill”. That same attitude has also gotten me in a few binds during my academic career. These things occurred because I felt like I was doing my best at something and would always be the best even if I didn’t continue maintain a certain level of excellence. It seems like the view here is that being the worst is the best and being the best is the worst. In other words, you have nothing to lose if you’re the worst and have nothing but the potential to grow, but if you’re the best then you must maintain being the best and potentially face having to fall from grace.

While I understand the message this pattern was trying to get across, I feel the messaging could possibly be misleading. The author mentions being the worst person in your team that produces good work can “make you feel as if you are performing better” when you could not be performing at all. While I feel like this pattern is helpful for myself, the advice given here should be taken with a grain of salt. To me, the most important part about being the worst is making sure you have the will to become the best and repeat the process.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance Pattern

For this week’s apprenticeship pattern, I did a reading on “Expose Your Ignorance”. A summary of “Expose Your Ignorance” is simply about how you may be unfamiliar with some technologies that are required to do a job and your manager and team members are looking to you to complete the job. At this point you already landed the position at the company but now, you’re required to do a task that requires certain technology like a specific language you’re not proficient in. To counter this, you must show them that learning new technology or anything is part of the process of getting a job done. In this pattern it mentions about how you should be honest and speak the truth to your clients and team members. This would allow them to be reassured even if you do not know the technology right away. If you’re able to show them that you’re learning and progressing, it will build trust and your reputation will be built upon that. Not only that but ask questions. Even though there’s already a presumption that you already know certain things since you’ve been hired, it will never hurt to ask since this is the most direct way in getting a task done and learning. The whole point to this is, to not be afraid of learning and let your team know that you’re learning.

My initial reaction to this pattern is similar to those of the other patterns where I can relate to it. In my capstone class, I am constantly being exposed to new stuff that I haven’t touched or barely learned from the other semesters, and I find myself always asking questions or looking things up on how to do a specific thing. What’s thought provoking in this pattern is how it mentions to not pretend what you know what you’re doing. I believe this is something a lot of people do, and it will negatively impact you more than anything. If you are honest with your manager and team members, they will get a better understanding about where things stand but will more than likely give you a chance to prove that you’re able to learn and do the work. Then if you were to pretend to know what you’re doing and give a horrible product. After reading this pattern, I felt more reassured that it was okay to ask questions and that it was okay if I didn’t know exactly everything. As long as I’m able to show I can learn and do the tasks properly and on a timely manner, I will be okay going into the professional world.

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

Be the worst

Be the lion’s tail rather than the fox’s head!

—Tractate Avot

I found this pattern interesting, but at the same time, a pattern that has a lot of space to describe from different perspectives. “Be the worst” is the title that when you see it at the first glance doesn’t sound really good. It grabs your attention, and also sounds like a piece of advice.

In every work environment, there are employees who are not at the same level of knowledge. Someone is good at factual and theoretical knowledge, someone is good at accessing and applying information, another one is good at coding, someone in communications skills, and someone in the way of organizing the work. A company might have also a person that is capable of doing all of these, but also it might have people that can’t do any of them.

There is an expression of Mahatma Gandhi. It says: “Practice as you are the worst, perform as if you are the best!”  This quote looks the same as the pattern that Tractate Avot talks about. Even if you are the worst on the team, you still need to practice and learn from the best ones. But at the same time, whatever you learn, you have to share and perform as the best thing you can do.

The solution that the author gives here, is to be surrounded by developers who are better than you. Based on him, also the solution is finding a stronger team where we can be the weakest member. Okay, when I read in this context it looks like advice that I can learn from. But at the same time looks a little challenging to me. Being in an environment where you are the worst of all the employees, firstly could make you feel as inferior. You might feel uncomfortable in a place where you know less than anyone. I think that nowadays anyone has the possibility to be informed about something is not sure about. Nowadays everything is well explained through information, tutorial videos where anyone can learn something new or when you are not really sure how something works. In this way, it might not be necessary to feel like someone that is just “the worst”. Of course, we can look for help when we are not sure about something or for learning something new and unseen before. But I don’t agree with being the worst.

To sum up, the point where I totally agree with Tractat Avot is when he says that one thing that can help us maintain a more accurate self-assessment, will be collaborating with great developers. Only in that way, we can have a successful software project on our teams.

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Sprint #1 Retrospective

At the beginning of the sprint a general overview was collectively made by the group and some confusion over the scope of work completed so far occurred. We were expecting a majority of our work to be code refactoring but at the time it was noticed that there was no actual operating code to refactor really, and our collective effort was directed at simpler cleanup tasks.

During the first sprint I assigned myself to two tasks created by Sebastian:

1st https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/61

2nd https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/2

The first task was creating landing pages for to later connect to the second task which was assigning href links to those landing pages.

I specifically chose these as I have never worked with html except for one occasion earlier in my youth during high school. I felt like this was a good opportunity for learning html and getting familiar with it as it is something I should know how to work with on at least a basic level. The majority of my time was spent on learning how to code in html and dealing with what I considered to be how weird it handles spacing and formatting.

My general experience with learning html did not go as well as I hoped. As with learning anything new the tricks of the trade generally do not surface early on and instead are buried deeper in more specific tutorials.

I generally struggled with spacing and formatting and in specific aligning a couple text boxes until my fellow team member Kurt off the top of his head mentioned that you could add spacing and tabs with specific code that made the pages look slightly more organized. He also told me about CSS and I spent some time learning about that and bootstrapping to find an easier way to automate the formatting of the landing pages.

Now I could have originally finished the landing pages and connecting them to the main landing page, but I had decided that without a more complete formatting style and still uncertain as to the future of those landing pages (the way the users will be directed to these pages depends on the Keycloak and Kubernetes systems being developed by the other teams and might require a complete design change to those landing pages), I chose not to finish the landing pages during the first sprint.

The second issue relates to a far simpler task that seemed a bit more difficult at the time but as I discovered it was far simpler. At the start it seemed like I might have to create other structures in the other front ends for linking together all the landing pages. Luckily after looking over the code it seemed to me that all I would need to do to link the landing pages together would be through the one hub located in the header.vue in the addinventory front end. It is the one point that has the href linking to the other front ends and I’ll be likely directing the landing pages from this point. Ultimately again it wasn’t implemented as the formatting was not completed for the landing pages. Overall I spent far too much time kind of randomly learning html and felt like I needed to find a more organized path to learning html. I also am expecting during the next sprint to have a far more coherent style and to format it based on Worcester States’s general website formatting and color scheme, as well as actually creating the pages and linking them together to finish these two issues

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Use the Source

The pattern I am writing about today is use the source. The problem is that an apprentice can be using bad habits, but he will not know if he is not reading someone else’s code. The author specifically mentions that the apprentice should look at the source code of the tools he is using. One reaction I had to this was an interview experience I had. I solved a coding problem, and my interviewer asked my what the time complexity was. I was using the Java library method Arrays.sort() but I did not look up what the time complexity of that library method. I eventually figured it out. But it made me realize that I should know more about the libraries that I am using in my code.

The author also mentions the importance of refactory code. When reading somebody elses codebase. The craftsmen should look for ways to improce the codebase, and understand why the project is built in the way that it was. This experience could also lead to apprentice refactoring his own code. The author also mentions code reviews. This is something I am really looking forward to as a professional Software Engineer. When we learn the fundamentals school, we are usually working alone, or in a small group. But in the professional world, we collaborate. This will give myself, as an apprentice an oppurtunity to learn from the source code of my coworkers. Open source is another great way for new craftsmen to gain this experience.

The author recommends that the apprentice contribute to open source, so he can read source code, and learn from it. He also mentions that if a programmer can understand a program from the source code, that means he is a good craftsmen. This makes a lot of sense to me, and understandy the code base is typically what a programmer does on their first day or days on the job. In order to contribute to a project of any size, the craftmen should know what the code currently does. So I agree that using the source is an incredibly important skill.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Reflection on The Deep End Apprenticeship Pattern

The Deep End is an Apprenticeship Pattern that encourages software apprentices to take risks, to challenge themselves, and to take opportunities they may not normally take. It makes sure to warn readers that this does not mean that they should jump into things that they are completely unqualified for, or do things with no thought or preparation. However, it is saying that we should be willing to take risks in order to further our learning, and should be willing to try things, even when there is a chance of failure.

I think that this pattern offers a very good way to ensure that we continue our learning, as stagnating at one job, on one project, is no way to continue our lifelong learning, tying into the Long Road apprenticeship pattern that I have discussed previously. We have to be willing to take risks and risk failure if we want to move forward (the same principle used in the Breakable Toys apprenticeship pattern). I also really liked the idea of keeping some sort of record of your own accomplishments, some archive of code we’ve written previously, how long it was, how many group members you worked with, and how large the codebase was. With this sort of history, not only can you track your progression and always look for bigger things and more learning opportunities, but you can also have a record of what you have done that you can go back to in the future, which also follows principles laid out in the Record What You Learn pattern. Being able to go back and see how you’ve changed can be an invaluable tool, and if you don’t risk failure, you will never be able to progress past a certain point.

This pattern has presented a great strategy as to how to keep track of my accomplishments and is great motivation to actually take risks in my professional career. I want to continue to grow my skills and grow, and unless I am willing to fail, I will never get anywhere. As for something I disagree with from the pattern, I guess the only thing I really disagree with is the idea that line numbers and team sizes are the metrics that your career should be based on. I think they can be useful to keep track of and consider, but in the pattern, it is kind of implied that these are the main metrics to measure your performance, and I’m just not sure they are the best ones. Regardless, I don’t think that invalidates the value of the point of this pattern.

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.

Apprenticeship Patterns: Study the Classics

                Often when we as people begin our education in any field we tend to lean either towards readings and studying our predecessors, or jumping into a more practical hands on approach. I myself have often leaned towards a hands on approach to learning. I find myself learning best when thrown into real work rather than boring myself reading textbooks and taking note of the though process of our predecessors. This is exactly how I have honed my craft for a majority of my time as a software craftsman so far. While this method of studying has its merits, it has also hindered my growth by minimizing exposure to the thoughts and theories of others before me.

                Oshineye and Hoover go into detail within this section explaining how and why we ought to delve into the books written by those who came before us. Classics such as Rodney A. Brooks’ Robust, Layered Control System for a Mobile Robot” and Valentino Briatenberg’s “Vehicles: Experiments in Synthetic Psychology” have long been used in the world of robotics and for good reason. They present a series of theoretical ideas and thought processes that yield results that may have otherwise been unexpected. Briatenberg’s Vehicles guides people that are new to robotics into a mindset that inspires out of the box thinking.

Briatenberg’s vehicles are examined not for their capability, but for their behaviors and different configurations exhibit different behaviors. Along with this, one might read Brooks’ work and apply the idea of subsummation to one of Briatenberg’s vehicles. Starting with simple behaviors that are subsumed by higher level thinking can be applied to vehicles to ensure they at the very least can perform certain task such as avoiding collisions with objects while carrying out their main goal.

The goal of these theories and mindsets presented by classic literature is the same as the very text put together by Oshineye and Hoover. It will not directly help with your skillset as a software craftsman, but it can lead to utilizing what you do have in new and interesting ways. An adherence to a certain design philosophy and being willing to experiment in ways that may not have been directly taught to you is important in forwarding your own skills as a craftsmen as well as forwarding the industry when one becomes a master craftsman.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Apprenticeship pattern: Expose your ignorance

I was reading chapter two on “Expose your ignorance” and got so caught up to it. When working with my team this semester, if there is something that I learned is to ask questions and not be afraid to show my “ignorance” like the book calls it. Sharing and exposing myself helped me understand that we should never feel less smarter than others just because they know better than we do, because learning and knowledge is open to everybody and it is not impossible to reach their level or even better, surpass them.

It can always happen to be caught up in the middle of a project that we do not know anything about. Some people might, and some might not. In that situation, we should let our ignorance awaken our curiosity so we can easily ask questions. People in general hate being seen as ignorant because we always want to show that we have knowledge, experience, skills required for the position or project. So, because of that, we find ourselves faking our knowledge and skills just to impress others. But software development does not work like this, it’s either we know or we don.t because the more we try to hide our ignorance, the more we’re sinking ourselves; And there will be a moment when it will be hard to get out of that place we got stuck on our own.

I love what the author said about the runner: ” She’s not training to have strong legs; she’s training to run. Like the motivated developer who after working on a Python for two years achieves a deep knowledge of Python, the marathon runner’s strong leg muscles are a means, not an end”. Craftsmen need to have the courage and humility to set aside their expertise and wear the “white belt” as they pick up an unfamiliar technology or learn a new domain.

One of the most important traits that a craftsman can possess is the ability to learn, identifying an area of ignorance and working to reduce it. As, software developers, we should not run away from knowledge and being shy or scared to expose our ignorance is not doing anything god to us. I am proud of asking questions and showing that I don’t have or I barely do have knowledge about a certain domain. And it is something that I do even with my team. When I am not familiar with something or don’t know how to do it, I just ask and the one that have the answer will provide it to me and help me understand. This is how I increase my knowledge and skills.

This is where “The long road” will take place. By exposing our ignorance, and then confront it. We will spin the missing threads much more quickly than we will by faking it in order to appear competent. And let’s remember that while we are exposing our ignorance, we are also exposing our team to our learning ability.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Be the Worst

When reading this chapter, I found it challenging because I asked myself who actually wants to be the worst? I tried to project myself and put myself in that specific position and I found it very hard to do. However, after second thoughts, deep reading, and analysis, I am very impressed and humbled by the content of this book and this chapter. They say: “You have to be the best”, “You have to master what you do”, “You have to always be the head”. However, we never hear the opposite of those sentences. We never hear: “Be the worst”, “It’s okay to start at the end of the queue”, “We all started from the bottom”. It is discouraging to know that nowadays when working as an apprentice, the expectation and the pressure is greater than the willingness to be understanding and people tend to forget that they have been there once and act as if they were the best from the start.

 There are points the author mentioned that I found important when being the worst in a team. He talks about couple of risks associated with it like brining the team down, the risk of getting fired when falling behind or inability to catch up and feel bad about ourselves. This part tells us that it is a great thing to accept being the tail of a lion. However, it comes with some risks that require hard work and regularly updating ourselves on where am I? Am I making progress? How much time the team is granting me and what happens if I don’t meet specifications? Being the worst is just a way to make us confident in the lion’s den, but we must really be motivated to learn, we must show the desire of doing better, bringing ideas that get us noticed with time.

The last interesting point the author mentioned was reaching out, asking to join a team and observe the team’s dynamics and ways of operation. For me, this is great because it shows the desire for personal growth and the team might be motivated to take you in because you have shown initiative and interest. I feel more confident now to “Be the Worst” in a team of professional software developers because that position will unleash my confidence, allow me to be myself, learn and improve at the same time in my craftsman’s journey.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.