For this post, I was looking for an eye catching pattern name and “Be the Worst” definitely caught my eye. After a second a of thought, it was pretty obvious what this pattern would be about. This pattern breaks down why it is important to not be the big fish in the little pond. It encourages apprentices to not rush into leadership roles and to not strive to become the best on your team and stagnate with your position. Instead, if you find yourself at the top and lacking learning opportunities, it may be time to move on and find the bigger pond, to surround yourself with higher tier developers when you leave.

I almost entirely agree with this pattern. I remember growing up in a relatively small town, where we had a couple athletes who were notably better than anyone else in the town at their respective sport and position. None, yes none, of them tried to get into bigger school districts where they may be challenged more and had more of an opportunity to get scholarships and even potentially make it professionally. Instead they all enjoyed their high school careers at a school with roughly 500 students in a division 3 conference. They didn’t aspire to leave the little pond and they never made it anywhere in terms of athletics. There are definitely parallels to this even in the college world and looking for positions directly out of school. There are always going to be people who are happy to just cruise by and not learn everything that they can at each step of their careers. I honestly feel like these are the people who are most likely to never even get a job in respective majors and then somehow blame the university for not finding them a job with a 2.0 GPA. No one owes you anything and you can’t expect anything to be handed to you, knowledge especially. There is always more to learn and never enough time to get everything into a four year curriculum. Never settle for being the best you know. All that means is that you need to meet more people.

The only part of this pattern I disagree with is how the authors try to sway readers from promotions. Promotions and new responsibilities even outside of coding are definitely important to becoming the best within a company. If the goal is to rise through the ranks of a company, isn’t this an obvious side effect? That being said, I will definitely consider this pattern as I move along in my career.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

While most of the Apprenticeship Patterns  I have read thus far are mainly focused on developing long term skills with an internal locus of control, as many of these patterns’ goal is to change our perspective to be more successful and adaptable to the software development industry. What I like most about this pattern, “find mentors”, is that the authors give good advice for branching out socially into the software development community by finding skilled individuals who can serve as mentors that can use their perspective and experience to catalyze the growth of our skills.

What spoke out most to me about this pattern and the reason I decided to write about it was their quote which seemed to me to encapsulate exactly the meaning of what they were going after; “Your apprenticeship is unlikely to happen in isolation”. While it is ultimately up to us as apprentices to take responsibility for our own development, there is an immense value in finding someone else who is worlds more experienced than you to show you the ropes and use the benefit of their experience to learn the best ways to do certain things or pitfalls to avoid.

The authors give a lot of good advice which I would not have thought about without reading this pattern. First, they highlight not only the importance of finding mentors but also the difficulties associated with finding something. Not only is there the risk that the individual is not interested in mentoring an apprentice, but it can also be difficult to find such a suitable person. The solution the authors provided is to start out by lurking at online forums related to the field and topics that we are going into. After lurking and getting a good sense of the community and their values, then it is good to start discussing on threads with people, and even asking for advice.

What I learned from this pattern is the importance of finding a skilled mentor to catalyze my professional development, as well as concrete strategies for finding people who might be willing to take on an apprentice. While the responsibility is on us as apprentices to gain the skills needed to succeed, finding a mentor is definitely a huge step forward in the journey to master the craft of software development.

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

This week, I will be exploring another apprenticeship pattern, which is “Breakable Toys.” I briefly mentioned this pattern in my last post, and I thought it was worth revisiting.

The professor of my capstone, Dr. Wurst, had suggested for us to try to create something, even if it wasn’t exactly what we were trying to do. This would allow us to dive deep into learning one thing.

The term he used for what he was talking about was “spike,” which I isn’t exactly the same as this pattern, but it certainly is a similar idea. This pattern more pertains to doing projects on your own time to learn from your mistakes.

In school, it wouldn’t make sense to turn in projects that don’t work. It would be hard to pass most classes if I did. In many cases, school or work, failure is not an option. Of course the authors don’t advocate experimenting with those projects. They would rather you learn independently so that you can apply the skills you pick up.

For the past few blogs, I have talked about being more proactive. I have made a conscious effort, but it has been hard keeping it up. I have to realize that change doesn’t happen overnight, and it’s good to take these setbacks in stride to avoid being discouraged.

In the pattern, it uses the analogy of someone learning to juggle. I once read a study where of those instructed to juggle just five minutes a day, all of the participants were able to juggle by the end of the study. Reading this was enough to encourage me to try this experiment for myself. I set a timer for five minutes everyday, and I was able to pick it up after a few weeks.

The important thing to note is that five minutes was the minimum I set for myself, but I would invariably go for much longer than that. Currently I do not have any side projects that I am actively pursuing. If I were to set a five minute minimum to do something, although it would be small, it would be far better than nothing. I’m willing to bet most days it turn into much, much longer segments of time than five minutes.

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

This pattern discusses the importance of practicing when it comes to improving your skills as a software developer. Many people’s daily programming activities do not give them the space to learn by making mistakes. If you find this to be the case, it is important to find an environment where you can practice without interruptions or pressure. For this pattern to be useful you need to carve out time to develop software in a relaxed and stress-free environment. If you aren’t relaxed, it will be harder to learn from your practice. Feedback is also important when it comes to practicing coding because it helps prevent bad techniques from being developed. The point of practicing is not to hone your memory, but to learn the nuances of your skill. This is why it is effective to do something a little different every time an exercise is performed. Choosing the right thing to practice is almost as important as the practicing itself. A good way to practice is to go through old programming books that focus on the fundamentals of computer science, as the information rarely stops being useful and provides a large source of interesting problems.

Reading this pattern was interesting because it complements the last pattern I wrote about, Use the Source. While that pattern discusses how reading code is important for improvement, this pattern talks about how practicing coding is important. I thought this pattern was very useful because it goes over the most effective strategies for practicing. The advice given about practicing in a relaxed environment and practicing within a community is very true. Enjoying your practice and getting feedback on it are both important aspects that are necessary if you want to see real improvement. The advice about doing exercises from older books that focus on the fundamentals rather than the latest trendy framework is also useful. There are so many frameworks out there that it can be overwhelming to pick one that you want to practice with, and sticking to the basics is usually more helpful anyways. Overall I thought this pattern was interesting to read through and I will try to apply what I’ve learned from it when I’m practicing in the future.

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

After “Expand Your Bandwidth”, we learned how to learn skill set. To make those skills better, I don’t know any other way than “Practice, Practice, Practice”. This is no secrets in life and coding is no exception. Once you learn, practice is the way that you can apply, and deeper understand from your mistakes. There is no point learn language without apply it to practice.

This is good point, if we take the time to practice our craft without interruptions, in an environment where you can feel comfortable making mistakes. When we don’t code with other people, we don’t feel pressure to get it right. When we make mistake, we just debug to fix and learn from it. The “deliberate practice” seem nice but we do not live in ideal world. Although it would be great, if there are program that learn from our coding and suggest exercise base on us weakness. It is better if we have stress-free and playful environment to practice, I would feel more comfortable doing in this area. Because I do feel the pressure coding in classroom. Although it is comfortable and less tress when we are coding alone. It is having its downside, to get better we need someone else to look at our code. Good code is not just the code can run or not. Code is good code when it is clean and efficient, by other developer look that our code. They could tell us where are our strong and weakness. We correct them and repeat the process; this is how we are getting better. As in the book suggest, each time should be a bit challenge. Take what we have learn and devise it to the next level. As I am graduating soon, this is one of my goals. I will try to practice more as well as learn new technology.

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

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s08.html

This pattern encourages the reader to pay close attention to minor details along the way when evaluating a success or failure. Apprentices commonly find themselves in complacent situations in an average team, so naturally improvement stagnates and it becomes hard to keep yourself on track. The problem is, “the less skilled you are, the worse you are at assessing the skills of yourself and others.” This indicates that it is especially hard to get started again once caught at the bottom of the barrel.

The pattern advises seeking out feedback and constantly adjusting yourself accordingly. This will help you more accurately predict success or failure and help you more efficiently improve. Being open with your work is the focus of other patterns, all apprentices should strive to be as “teachable” as possible.

The chapter classifies feedback under two categories; reinforcing and balancing. Reinforcing feedback encourages more of something, while balancing feedback encourages less of something.

In my personal case at work, I can apply feedback to the pitch I give to the average customer. For the most part, my pitch is designed to be friendly and get the customer the product they are looking for quickly. In that time, I work to fit in other deals or offers I think the customer might be suited for. This could mean higher quality products, the benefits of the best buy credit card, or becoming a member of our total tech subscription service.

At the end of the month, we are provided feedback on how much we sold and how many cards or subscriptions we put out. Some months are luckier than others, but certainly every associate starts to get better and better over time. If an associate doesn’t raise enough revenue after a few months, they receive coaching on their style of pitch. Reinforcing feedback in this case would encourage an associate to mention the subscription service to more customers, thus increasing the chances of closing one. Balancing feedback would prevent swearing and acting rowdy with coworkers in front of the customers, in an attempt to be more approachable.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

Whenever you are new to a team, it an be very nerve racking because you do not want to mess up a single thing. This mindset is perfectly normal and makes sense.  This pattern discusses newcomers into a project and what to do in this environment. For starters, it’s always important to make good relationships with your team. The situation is that you are a new apprentice on project and the team is unsure of you. You want to find ways to contribute to the teams work but you can’t overdue it. This pattern explains that y ou should volunteer yourself for simple but necessary tasks. There are always going to be certain tasks that your team will need to get done one way or another, and even though they are simple tasks, they can often enable for the future success of whatever project you are working on. When taking these tasks, you should still pump out a high quality job. Showing that you can perform even basic tasks at a very high standard of quality shows your team that you care about what you are doing even if it is just small tasks. Sometimes these tasks can be just as vitally important as other tasks. Some examples of these tasks are maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, or even setting up the project wiki. However, it can be tough to do if you spent a lot of time and money on computer science education. The reality of it is that when you get into the workplace, our education is worth a lot less. When you join a computer team, getting hired is different from joining a team. Your firsts takes should be made to send a message. However, there could be some potential downfalls to this pattern. It could keep you permanently doing these mundane tasks for the team and never giving yourself a chance to expand to bigger and better things yourself. But if you do the tasks that sometimes your team may not want to do, it could give you a sort of priority on what you can do next for the team and open new opportunities for your team to see how worthy you are.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

The section titled Find Mentors discusses finding people in your field who are seasoned and have a lot of experience to offer, and to reach out to these veterans of the field and try to gain from them what knowledge they have to offer. It is a simple idea, but as the text explains, it is intimidating to just ask someone to offer their services and mentor you. It is a lot to ask, and not everyone is up for it after all. Besides, it is challenging to know who is even a good mentor, and who is not.

I consider many of my professors at Worcester State mentors to an extent. However, I wouldn’t say I’ve ever had the kind of mentor-ship detailed within the section. I can definitely relate to the anxieties listed about reaching out to someone. It can seem weird and uncomfortable. I suppose it is just a feeling you have to conquer if you want the best for yourself, however. After all, nobody else is going to ask for you.

From my perspective, Find Mentors is such an important pattern because there is a limit to how much most people can learn independently. There is such a huge advantage to having a resource like someone who has been through all the challenges you are facing and can solve some of the problems that come up. I hope that in my future I have the chance to meet someone who can offer me these advantages. Actually getting into the field is a huge hurdle, and having someone who has been through it and could coach me on how to navigate it would be incredible. It is just something I am going to have to search for.

Overall, Find Mentors seems like one of, if not the most important apprenticeship pattern I’ve read about and discussed so far. After all, finding a compatible mentor that is willing to dedicate the right amount of time for you would result in huge growth and development. It is hard to obtain this ideal, but it is something worth striving for.

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.

For this weeks blog post I will be discussing the pattern known as “Sweep the Floor”. Sweeping the Floor is about you starting from the bottom and then getting into the more complex tasks. This being you contributing to simpler tasks, learning from these and becoming more skilled then graduating into larger more complex tasks. Imagine you are an new apprentice on a project, unsure where you stand compared to others on the team and they are unsure about you as well. You want to earn your place on this team, contributing where you can, gaining their trust and growing in the craft essentially. To do this you could simply volunteer for something simple that is necessary to complete. This is a good starting way to contribute to a foreign team and to the teams success early on by showing you can do high quality jobs even for simple matters. Skimping on quality here could lead to trouble later on when it turns out later that this part is actually very important. Some various examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, setting up a project wiki and so forth. Basically you would be focusing on the edges of the system where less risk lies rather than the heart of the project where the stress and complexity would be. But this of course could prove tougher to swallow if you have spent a lot of time and money in a computer science degree. The moment leading up to your career in theory has been doing all of the said above tasks almost just without pay. Another negative aspect of this would be you ending up as the teams gopher, condemned to do menial tasks no else wants to do. You may find yourself intimidated by doing anything other than sweeping the floor, feeling only comfortable doing this. There is also danger in that you may not be able to develop appreciation for bigger projects due to the smaller menial tasks you are accustomed to. In short finding the tasks nobody wants to do or complains about and creatively resolving these problems in ways that exceed peoples expectations will allow you to slowly soar above, something that most including myself can get behind.

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

For the tenth and final week of reading, I chose to read the pattern, Use the Source. This pattern focuses on the problem that without the presence of good source code to study, practice, and emulate, you can’t get better, and you might continue developing bad habits you didn’t know you have. The solution provided is to find another person’s code and start reading them. This will enable you to learn how they wrote their code and understand the thought process that made that code. The recommendation includes examining open source projects and examining them for why they work in such a way. Also, to attempt and refactor codebases to understand the decisions programmers make and why they didn’t choose a different way. This process also leads to why there is appreciation for code reviews and pair programming. Having other people read your code, you read theirs, everyone can learn from each other. Allowing yourself to get a feel for good and bad code, you can develop a better understanding of yourself and how to improve.

This pattern is interesting because I never thought about using open source projects as a way of learning. I always took open source projects as a way of getting things from the community and as a way of contributing back to the project. However, using it as a way of reading well maintained code, reading practice, and understanding the thought process is a creative way of using publicly available projects.

This pattern is also useful because once you have seen the code, you might remember it for later as the code is not textbook examples. Examining, dissecting, and understanding code from real world projects allow you to see more, retain more, and most likely apply it in your own code later on.

The pattern has caused me to change the way I think about my intended profession because there are many different ways of improving yourself as a software developer. Being on the look out for readily available information and tools and being creative with the resources you do have access to can make a difference. As such, this pattern is incredibly helpful at showing that sometimes resources for learning can be right in front of you, you just weren’t creative enough to know it was there from the start.

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.