Apprenticeship Pattern Blog: Find Mentors

Hello and welcome back to benderson’s blog! This week are going to discuss another apprenticeship pattern from the Apprenticeship Pattern book that my classmates and I have been reading and taking notes from. The pattern that I would like to discuss today is “Find Mentors”, which is a kind of a self-explanatory pattern. It follows the rule of “If you hit a roadblock and need help, ask some to be there apprentice and work under them and learn from them”. You’re not a master at the craft yet and at some points you don’t know what to do next, one of the best things you can do is find someone that has already gone through the process and you can ask them questions on what they did and how you should approach your future. I have a friend actually that graduated from Worcester State with a Computer Science degree, where I plan to graduate this coming May and also graduate with a Computer Science degree, and I asked him a bunch of questions regarding what he did after graduating and what are the steps I should take so I can get a well paying job and be able to be successful for the coming years. He gave me some pointers and what I should know for interviews and stuff so he was very helpful in that sense, still finding internships and job opportunities will be a challenge in them selves but I will cross that bridge when they come.

The pattern itself wasn’t really thought provoking because as I said earlier, finding a mentor is kind of self-explanatory. You got there, find someone you consider to be really good at the craft and you ask them if you could learn from them if you aren’t too intimidated by them. If you’re too intimidated by them, just ask them out to lunch or something and generate questions to find out what you can do to better yourself in the craft. This pattern could honestly be used for many different subjects such as business, teaching or being a doctor. All those jobs have people learning under people that have already mastered the craft and are willing to teach them so they can succeed them when they retire. The pattern has not caused me to change the way I think about my major as I know one day, I will have to find a job such as an internship and learn from my experiences there, hopefully from someone really good at computer science and willing to share information with me. Finding a mentor is just one step in the journey to becoming one of the best computer scientists out there as to become the best, you have to learn from the best. Thank you for joining me this week on benderson’s blog!

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

Going Deep

The Deep End describes the situation where you feel like your skills have plateaued and you are having difficulty finding ways to improve. As it sounds, The Deep End is a pattern that encourages you to “dive in” to the deep end. That is, to take challenges that you know you could fail, knowing at least that you can learn form your failures and improve yourself as a result. It is not about taking uncalculated risks or lying to get opportunities, it’s more about taking on things that you aren’t certain you could do, but have the means to do so.

The Deep End is a pretty intuitive pattern. When you feel like you aren’t improving, push yourself in ways you haven’t before and turn it around. However, it can be very intimidating in practice to take on projects that you aren’t certain you can complete, especially if you think you have to worry about potential consequences. Although learning from failure is a very effective way of learning, it can also be very costly, and that definitely gives me anxiety.

That being said, it is important to take risks and leaps in my life and my career. It is the only way I am going to improve myself and get what I want, and being too nervous to take chances and opportunities as they come my way certainly wont help. I will make note of the lessons taught by this pattern and try to take more risks in the future. I think it will especially help me with my directed study this semester, which has begun to push me into learning many new languages and concepts all at once.

The Deep End is a cool pattern, and the it makes sense practically. Most people are definitely aware of the idea of taking on harder tasks to sharpen their skills. Most people want to improve, but it can be scary to tackle hard challenges and face the unknown. However, getting over that anxiety is crucial to becoming a smarter, more well-rounded individual. Life isn’t easy, and you need to be ready to solve hard problems at any moment.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – The Deep End

Overall, I consider myself a person who tends to enjoy my comfort zone. I appreciate settling into a routine, whether this routine appears in my part-time job or is reflected in my academic projects. But is remaining stagnant the best decision for me, going forward into my career? Probably not, considering that I want to grow in knowledge as I gain more experience in the field. This week’s apprenticeship pattern, called “The Deep End,” provides more insight about how I can nip stagnancy in the bud, so that I can break away from a more comfortable routine and challenge myself further, becoming more confident in myself and my skills at the same time.

The problem that The Deep End aims to solve is one that I’ve started to already describe. As I spend more time in my career, I may become concerned that establishing a more mundane routine (like sticking to familiar projects which keep me in my comfort zone of work) is not the ideal choice if I want to continue to improve my skills.

In order to fix this issue, I need to jump into the deep end. To do this, I should seek out projects or other opportunities that are challenging enough that they are straying away from my comfort zone. I need to also understand that this sudden change to more difficult work can come with risks, including the possibility of failure. This balance of striving to test myself with different, tough tasks, while keeping an eye on my progress so that I am not in over my head, must always be maintained. If the likelihood of “drowning” continues to increase, it is also essential that I have the capability of reeling myself back in and find help if needed.

I completely agree with everything this pattern encompasses. Even though it would be nice for me to remain comfortable with the work I am doing, I know that it is imperative for me to continue tackling difficult problems and projects so that I can remain at the top of my game and keep my skills fresh.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Diving Deep

This series explores Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. This week, I decided to read the apprenticeship pattern “The Deep End.” 
To be completely honest, most career opportunities that are on the horizon are somewhat intimidating. I wonder if I have the ability to do a lot of the work they require. The chapter talks about getting into a rut, but my rut is working fast food. Making a transition to a career-oriented position is a big step, and it is a bit out of my comfort zone.
Instead of reluctantly accepting a task that I am not confident about, I should have the self-assurance to jump in at the deep end. This gives me permission to take on a task that might seem daunting when it presents itself. This is easier said than done, and I find it hard to entirely  abandon my initial timidness.
It is important to note that they also warn about getting too far out of your depth. It is okay to jump in the deep end, but “you still need to remember that if the water level is above your head it means you’re drowning.” This is key. They offer two other patterns for helping with this, which is “Finding Mentors” and “Kindred Spirits.” The titles seem descriptive enough to give a general sense of what you might need to look for. Perhaps one of these will be the topic of a future blog post to dive in more in depth.
The action it suggests is to measure the biggest projects I’ve accomplished based on a few factors of complexity. When the next project comes along, see how it compares. It claims this is a good indicator of where my career is heading, and it might be the basis of choices I make.
Already, when thinking of mapping my projects like this, I think to myself, “I need to do more independent projects.” I’ve done quite a bit for school, but I haven’t done anything incredibly ambitious on my own. I have vague goals of what I want to do, but I have done few concrete steps to fulfill them.
Most of my goals for independent projects are somewhat formidable at this point in the game. For example, I would like to make some sort of a web app that I would have to develop full stack. I have a few ideas in mind for what to do.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

MINIX3: Scheduler Research II

I’ve had to change my approach the past week or so with this independent study. When confronted with the source code, I think I began to feel overwhelmed by the amount of concepts I had to dive into. As a result, I attempted to take it from square one and relearn many systems concepts while also working on understanding the scheduler. As it turned out, this was a bit stressful for me. So I have decided to instead look at the relevant source code and, line by line, take notes learn things as they come. Perhaps this is the traditional way to handle diving into a large system of work, but since I don’t have a large amount of experience in large-scale work this is a learning process for me. It seems that this new direction is working a bit better for me.

Let’s start with /minix/servers/sched/main.c. The main() function is the primary function of the scheduler. When a message is passed into the scheduler, the main() function defines variables for the message, system call number, the caller’s number, and the result of the system call. Then, it enters an infinite loop. This loop saves the message’s info in the variables that were defined for it, and then checks for special situations such as system notifications, etc. (I’m not totally positive on the function of that, but it says that the balance_queues() function is called in this event.) Then, based on the call_nr (the system call number), a switch statement determines what call from /sched/schedule.c should be executed next, with functions like do_noquantum() (which executes when a process is out of quantum) and do_start_scheduling() (which seems to start the scheduling of the process). So long as the process is executed correctly, a reply is sent back that communicates success, and the loop continues on to the next kernel message.

So hopefully soon, I’m actually going to start tinkering with the scheduling policy and see what I can come up with. In the scheduling report I discussed in my previous post, it was suggested that with the current interface a Round Robin, Priority Scheduling, Staircase Scheduler, or Rotating Staircase Deadline algorithm can be easily implemented, so I’ll learn one of those and aim for that. I’m sure it’s going to take me longer than just a week to fully implement, but we’ll see what kind of magic I can work. I’m also sure I’m going to have to write a couple more of these research-related blog posts before I fully understand the workings and can proceed forward, but having changed my plan of attack, I’d like to finish those this week. Ready to move forward once again!

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Every little bit helps!

For the sixth week’s reading, I chose to read the pattern, Sweep the Floor. This pattern focuses on a problem where you are a new apprentice on a project. The real-world experience of joining on a team means that you have to learn about the team and the team has to learn about you. These situations are uneasy and earning the trust to contribute to the development that they have worked on before you joined is a problem to be solved. The solution provided for this is to start contributing to the project by completing tasks that the other members do not want to do. Examples provided do not entirely mean that it has to be about coding and could be other tasks such as code review, setting up a project wiki, or updating documentation. As long as you contribute to the team, they will have an easier time and appreciate your work and build trust. The objective is to build enough trust that you can take on bigger challenges and eventually become one with the team.

What I found interesting about this pattern is the excerpt in the second to last paragraph. It is the last thing a student that is about to graduate from university would want to hear. Completing your tertiary education, after spending the four years or more getting the degree, accruing massive student loans to hear someone devalue your education is heart wrenching. However, those who chose the route of getting a degree should be fully aware that this is the reality. The knowledge you gain from school is like a baseline for real work experience. Being accepted to work at a place does not automatically mean you are on the same page as everyone else. You will have to spend time as a newbie and learn about everything the company, team, or workspace has to offer.

This pattern has not changed the way I think about the profession or how it will work because everyone has to start from somewhere. As someone fresh out of school should realize that education doesn’t mean all that much when compared to actual experience in the field.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Craft Over Art

When I read Apprenticeship Patterns, the patterns which tend to stand out to me the most are those patterns which offer a unique perspective and an illustrative focus that is clear and easy to follow. Oftentimes when I am deciding how to proceed with my learning or implementation of code, I get lost in the possibilities, and the guidance the authors provide in this book gives me some much needed clarity.

This apprenticeship pattern is called “craft over art”, because the point of our vocation is to in the end provide a useful product to customers. The value the authors place in this section is on the practical and usable skills that makes up a good developer. The authors illustrate this point well by reasserting and contrasting what it means to be a software craft-person.

At its heart, craftsmanship is making something useful or necessary with an additional style or beneficial features that are added based on the creator’s methods. The authors definitely make this point clear when comparing software development to a craft, and even more so by comparing crafts with the arts. The key difference is that while crafts focus on making a functional product, the fine arts are focused on pure beauty itself.

So what the authors suggest we focus on as apprentices is not the beauty of the product but the functionality of it. Additionally, they describe how often in practice in order to deliver value in time a compromise might need to be made between utility and beauty.

This pattern definitely helped me hone in on which particular skill sets and goals I should be orienting myself around to be successful. Often I worry that I need to be focusing on making the most elegant code or learning the newest fanciest technology, which are definitely good things to aspire for, but in the moment of me beginning my professional journey, it is more important that I pick up practical, concrete skills, and that I focus on delivering the most value and utility. What I gained most from reading this was understanding that bells and whistles will make a product shine, but you famously cannot polish a turd.

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

A Big Fish in a Small Pond

The pattern I chose for this week’s blog post is falls along of “Be the worst”. Now it doesn’t quite literally mean become the worst at what you are doing specially in the software field but rather surround yourself with better or stronger developers. From this you can be the worst or weakest member of the group and only have room to grow. If you settle for being mediocre or unaware of others strengths you will not learn or grow. The example they use is becoming a big fish in a small pond, it is critical for the big fish to be aware of other ponds within the vast global network of said ponds and realize that there are even bigger fish than that of your little pond. Going back to surrounding yourself with a team of better individuals you will then only grow due to you not wanting to be the bottom or smaller fish. From this you will work harder than you would normally if you settled for a buck average understanding. You will learn new ways to tackle obstacles in front of you almost mimicking the stronger developers’ habits until you reach their level. The others will also help you in the long run, preventing you from making mistakes how to recover and more. Some downsides of this is of course there is a risk you could drag the team down and a good team will not appreciate a free boater. Another downside is that you could end up feeling bad about yourself and your own skill levels as you being the worst in the group. This is after a sink or swim strategy so sinking will of course feel like drowning. In short being the worst pattern will allow you to increase your learning and growth levels to rival that of the stronger members of your team. I find this pattern to be very interesting because not often do you hear “go be the worst in the group” or something along the lines due to the potential of you perhaps causing a big problem for it. But it makes sense for those who want to learn and become better than their previous self’s and also see where they stand in the field compared to others. I can myself honestly trying this in the future if need be. In all honestly there have been groups I’ve been in where I could be considered the worst, whether that be in software or any group/based activity or environment. In these situations you can feel yourself wanting to be better and not be dead weight and after it I feel like I learned more on the subject, grew in it and overall bettered myself. Wherever I end up in the future and I find myself as a “big fish” in a small pond unaware of the other bigger fish out there I will use this pattern to grow and better myself.

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

Apprenticeship Pattern – Sustainable Motivations

  The pattern I chose this week I thought was interesting from the name. The name is what initially made me want to check out the pattern ‘Sustainable Motivations”. As it would turn out this pattern really resonated with me. Sustainable motivations talks about how you can develop you skills less effectively if you are… Continue Reading →

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

Confront Your Ignorance

For this week’s blog, we will talk about confronting your ignorance from the Apprenticeship Pattern book. This will be a continuation from the last blog Exposing Your Ignorance.

Now that you have let your teammates know that you are lacking in some skills, it is now time to deal with your ignorance. There are tools and techniques that you need to master but you do not know where to begin. Some of them are things that are expected knowledge from you that everyone around you already knows.

So what should you do?

The book’s solution is to pick one skill or tool and actively fill in the gaps in your knowledge about it. How should you do it is up to you. Whatever works best for you. For some, the best approach is reading all the introductory articles. Others find that looking at the code is a better way to understand it. They also recommended asking around if anyone is also trying to master these skills or ask a mentor that already have these skills and if they are willing to share what they learned.

I find this chapter interesting since it was tied to Exposing Your Ignorance chapter. To do this pattern, you will need to expose your ignorance first. Using this pattern in isolation might lead to a culture where failure and learning are unacceptable and everybody just keeps to themselves. Also, your employer has certain expectations from you and might not be understanding of your educational needs that would get in the way of the successful delivery of its project.

Confronting your ignorance is probably one of the things that you will be doing over and over again in your workplace. Most likely, your first few months in the job would be a learning curve for you. Figuring out what tools they use, how it works, and how you could use them would be the first challenge you will face.

This pattern changed the way I think about confronting my ignorance. Usually, I do everything alone and try to solve things alone. But that seems like a band-aid solution to the problem. It is better to ask people who have mastery of such skill and see if you are doing it the right way, so in the future, you will be more knowledgable and can be a master of this skill as well.

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.