Category Archives: Apprenticeship Patterns

Dig Deeper

Problem

You keep running into difficulty maintaining the code you’ve written because it turns out that the tutorials you followed cut corners and simplified complex issues. You find that your superficial knowledge of a thousand tools means you’re always floundering whenever a subtle bug arises or you have to do something that demands deep knowledge. People often accuse you of having a misleading CV because you don’t distinguish between a couple of weeks of extending an existing web service and a deep knowledge of the issues inherent in maintaining an interoperable and highly scalable enterprise system. What’s even worse is that because your knowledge is so superficial, you’re not even aware of how little you know until something or someone puts you to the test.

Solution

The solution the text offers is to “dig deep into tools, technologies, and techniques. To acquire the depths of knowledge to the point that you know why thing are the way they are.” Depth meaning you understand the forces that leads to a design rather than just the details of the design. Areas where you have deep knowledge feed your confidence and allows yourself to apply your value early when on a new team. Having the background knowledge of how things work gives you the ability to fall back onto that to tackle difficult challenges and allows you to explain the inner workings on to tools and systems you are working on. This knowledge will help you in interviews, setting yourself apart from others because you can explain how a system or tools works. Using primary sources is the best way to understand the deeper workings of things, you can follow the trail of information that leads you to the decisions made along the way and why they were chosen.

This pattern is overall good advice for anyone who want’s to be a software craftsman. It’s important to Dig Deep into something you are passionate about. You don’t have to know everything about programming and software design but you should know a good amount about a few important areas. The ability to fall back on that background knowledge keeps you from struggling to understand new concepts, and makes you an asset to any team because you understand what’s going on beneath the surface. With this knowledge you can help others by explaining things in a clear way. Doing research and looking into primary resources allows you to get to the core of the information. It takes time to learn how things work but the benefits are worth it. This pattern will definitely improve my professional career and ability to help other understand deeper concepts.

The post Dig Deeper appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

The White Belt

The White Belt apprenticeship pattern is one that focuses on your mindset when approaching new problems and learning new skills.  It encourages you to approach new situations from a point of view that you are a beginner. That can be confusing, it’s not to say that you should forget everything that you have learned in the past, just that while using skills that you may already have when learning new ones just keep in mind that you do not know the new skill and should approach it with an openness and readiness to learn as much as possible.

When I was in the Army we were constantly going through additional schools and courses to build our list of skills.  Whether it was general skills for service or specific to our job such as new routers or satellite terminals. With all this schooling we learned quickly that you need to realize that you don’t know what you are in the course for and are there to learn that skill or how that equipment works.  When you realize that you are a beginner you open your mind to the possibility of accepting all the little things that you need to know to help grow your proficiency with this new skill.

My first job out of college will be a Quality Assurance Engineer role and the company I will be working for does not use an object-oriented programming language.  This will be a large shift from college where I spent the past four years developing skills and learning new things centered around object-oriented programming languages.  I plan to take the skills that I have learned through the years at Worcester State and keep them in the back of my mind and use as a foundation, but I will approach it with a clear head that I don’t know what I am doing, but open and ready to learn what they teach me.  Another important point to keep in mind is that even if I think I know some it is important to find out how they want me to accomplish the type of task. There may be a specific way that the company needs it done, those reasons could be from a legal standpoint or just company preference.  I’ve learned over time that the specific reason why things are done a certain way may not get passed down and may not make sense at the time, but chances are they are done that way for a reason and there is a better approach and talk to your manager if you think you may have a better way.

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

Dig Deeper

Dig deeper is a very important apprenticeship pattern to remember throughout your career and especially one to pay close attention to early on in your career.  It stresses that just writing a solution that you found online or just guessed until it worked is not good enough. It is important to know why the code solved the problem that you were having.  You should also look as to why was this the chosen solution, why code A over code B. This will help you stand out at work as someone who is a more effective problem solver. This will also help so you don’t submit a project that is only half complete; maybe the question that was answered on stack overflow did not include a test that was specific to your work.  If you do not dig deeper into your solution you may not realize this and turn in an unfinished project. When you only scratch the surface and just barely do enough to get by or even less than that work falls to others. There is a set amount of work that needs to be done for each project. Just because you do less doesn’t mean less work needs to be done, it just means that you are putting a bigger burden on the rest of your team that needs to complete their own work and pick up your slack as well.

When moving on from school I intend to make it a point to set aside time to review all the work that I complete as well as try to fully understand other parts of the program that I have a chance to see before submitting my work.  I think this will be beneficial for a few different reasons. First it will help set an impression with both my peers and superiors that I am a thorough worker who puts extra effort into my code. More importantly though it will allow me to expand my knowledge and provide the best possible solution for the problem that I am presented with.  It will help a well rounded tool kit that I may not only use immediately but could be applied in the future too. Doing this early on will create a solid foundation to build on for the foreseeable future.

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

Use the Source

Problem

Without exemplars of good practice to study and emulate, the Practice, Practice, Practice pattern only entrenches the bad habits you don’t know you have. If you never walk a mile in someone else’s moccasins, you may come to believe that all shoes are meant to have stones in them. So how do you find out if your work is any good, given that those around you may not have the ability to tell good code from bad?

Solution

The solution the text offers is to seek out other people’s code and read it. Start looking into applications and tools you use every day. It allows to you to learn how other professionals write code, and the thought process behind creating the infrastructure you’re using. When examining open source projects, it’s best to download the most recent version and preferably from the direct source so you can inspect the history of commits and track future updates. Learn the codebase and how the files are structured. Think about how you would have done things differently, and if maybe you should rethink the way you do something because someone might have a better solution.

This pattern has good tips on learning from the source. I liked the idea of starting with tools and applications you work with every day, I think starting with open source projects is a great way to learn how current professionals are writing code and what practices they are utilizing. You may find things you disagree with and things that make you re-think how to approach a problem. I think it’s also good advice to seek out others to read code you’ve written and have them offer feedback. It refreshing to know that so much content is available open source, and it can give people like me access to real working programs that I can learn and possible contribute to in the future. I like the idea of looking into sites like Git, Subversion, and Mercurial and learning how these projects work, and what design patterns and algorithms they are using. I believe reading and understanding open source projects will make me a better programmer, and will help me greatly in my professional career as I continue to add to my toolbox of best practices.

The post Use the Source appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Record What You Learn

Problem

Those who do not learn from history are doomed to repeat it.

Solution

The solution the text offers is to keep a record of your journey in a journal, wiki, or blog. Having a chronological record of the lessons you’ve learned can help those you mentors you, it can also be a vital resource to draw upon when needed. Those who follow this pattern sooner or later realize they’re trying to solve a tough problem and use what you’ve recorded to solve the problem. Try to avoid writing lessons down and then losing the information and forgetting to keep it updated. An example the text offers is someone who keeps a wiki for his private thoughts and the other for sharing with the world.

I think the pattern is good advice, I like the idea of keeping a blog to update as I start my career as an apprentice. I liked the idea of having two wikis, one designed for personal use and one to share with others. Having a more personal blog or wiki allows you to be painfully honest with yourself and the progress you’re making. Having something to go back to and refresh yourself has many benefits and can help you in a bind when you might not have anyone to ask. I keep cheat sheets at the current job I work and having that information saved makes my job much easier. Another good suggestion from the text is creating a textfile or page on a blog or wiki to save tidbits of information or quotes from software craftsmen, in the example the book noted, someone uploaded all their saved quotes online for others to learn from. I like how this patterns ties into the Breakable Toys pattern, you can start projects that you can share online, creating a chronological history of every step of the project, where things went wrong, and what you did to fix it. I think during my time as an apprentice I will continue to blog what I learn and keep the lessons I learn from mentors and colleagues. I like the idea of Sharing What You Learn, a lot of the lessons I’ve learned have come from other people who’ve taken the time to create blogs posts or YouTube videos describing the steps they took.

The post Record What You Learn appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Breakable Toys

When starting in a new work environment, especially when stepping into a new craft as an apprentice you only want to produce positive results, even though failing is a great learning tool.  A good apprenticeship pattern to develop is to create breakable toys. Develop personal projects that you can afford to fail on and break so that you can learn these valuable lessons without it having an impact on your performance review and without risking your job.  These can be programs, servers or anything else that mimics your work station and helps develop your toolset. The important part though is to remember that it while it should mimic your workstation it should not intermingle with your work by any means. This could lead to massive problems if you break your toy and it negatively affects your work.  You also don’t want to run the risk of breaking any confidential agreement that may lead to legal trouble beyond just losing your job. This is not a pattern that should just be applied blindly; you need to apply a basic level of common sense of whether or not it would be ok to include things that you may have gotten from work onto an unsecured system.

When I start my new career I intend to mock my work station at home to the best of my ability.  I will use this to create similar projects to the one that I am working on so that way I can have more freedom trying solutions.  While that is part of what version control fixes this will allow slightly more freedom to try things that shouldn’t work and take the time to see why they don’t work as a viable solution to the task at hand.  Then as time permits I can create new projects that are not associated with work and expand my toolset to work on mastering new areas of my craft. I know for myself that I learn better by doing something hands on rather than in a visual manner.  Creating a personal workstation will allow me to further develop my craft and skills that I need to succeed in this new role. It will also allow me to explore and create any personal projects that I may find interesting that will help develop a broader toolkit that may come in handy later in life.

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

Kindred Spirits

Problem

Organizational cultures that encourage software craftsmanship are rare. You find yourself stranded without mentors and in an atmosphere that seems at odds with your aspirations.

Solution

The solution the text offers is to keep your momentum going, there will be times when you may not have access to a mentor so you must keep in contact with those who are walking a similar road you are, as well as seeking out others who may be looking to excel. The Long Road is not something you walk alone, some relationships are short and effective, others are long lasting, and help nurture your passion. Though there are many benefits of a community of like-minded people, you need to be wary of group-think. It’s O.K. to follow the crowd sometimes but must always remain vigilant and question something when you feel it’s important.

This pattern is a good reminder to always try to keep people around that you can rely on to share experiences and learn from each other. I think it’s interesting you can have mentors all over the world, you may have never even met in person but you have a connection because you are walking a similar road. Having a Kindred Spirit to talk to, to take a break from the 9 to 5 work and share something that may be new or interesting. The dynamic is different because you can share what you know without coming off as a mentor you should follow. Kindred Spirits reminds me how important relationships are especially with the people you work with, as they can be great resources especially when you need advice on something work related. Having a community around you is another good way to ensure you have kindred spirits, and I like the idea of healthy debate, to keep the community fresh and healthy. I like that the pattern encourages finding those in community who may have a broad interest in software development, but then slowly find those who may have a particular niche that you may benefit from. Knowing those with obscure knowledge can help you when you if you ever find yourself in a situation where you are working on something unfamiliar.

The post Kindred Spirits appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

Everyone is going to fail at one point or another in our lives.  Those that do not experience failure haven’t tried; failure is a part of living.  The important part is to see what these failures are, see what setbacks you face and what you are going to change moving forward in order to try and keep from repeating the same failures over and over again.  It may also just mean recognizing when things are heading in a direction towards failure and cutting your losses.

This is another apprenticeship pattern that I believe can be applied to any other profession and also extends to all aspects of life.  Early on in my career in the Army, I saw my share of failures and mistakes. The Army knows that this will happen and that is a big part of basic training.  Making mistakes and realizing that a lot of the time it is not the end of the world. The important part is to not dwell on your mistakes and feel sorry for yourself, but instead to identify what caused the failures and change your habits or actions to prevent that mistake from happening again.

Starting at a junior position I will be in a position to make plenty of mistakes and fail multiple times.  I am excited about this opportunity because while I understand that failure should not be celebrated and we showed be striving for success, it does give me the chance to learn and grow in this field.  It will give me a chance to stumble and interact with my superiors who will provide guidance and pass along what they have learned. If I stay away from any position or role that has the opportunity for failure means that I have also stayed away from any role or position that gave me a chance to succeed and progress toward a mastery of the craft.  Taking risks and running the possibility of failure is what will help me grow in this trade and pass that knowledge along to others that I work with and those that come after me and hopefully leave the field a little better than when I came into it.

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

Share What You Learn

Share what you learn is a pattern that believes that in order for new apprentices and others to learn we need to share what knowledge we have.  This is a very important apprenticeship pattern that is looked over often. Passing along your knowledge is what allows future generations to improve standards and practices.  It may also help your peers fill in that missing piece that they may need in order to complete a large project that they are stuck on. With the advancement in technology, it is easier than ever to share what you have learned with almost anyone around the world.

My past work experiences have instilled in me that this is absolutely true.  When I joined the Geek Squad at Best Buy I had a base level of technical knowledge but was not an expert by any means.  Thanks to the other employees sharing what they knew as I watched on for the first few weeks. This allowed me to take in and learn from what they already knew instead of being on my own to figure out what the specific problem was, research the different possibilities that could have caused this to occur, and finally trying the different solutions through trial and error.  This not only made my life easier but created a better experience for our customers. They got their device back sooner because we already had a good idea of what the problem was and they were able to start from the most likely solutions and work out from there. It also made them feel more confident in our abilities to work on their unit. While some may know that there can be different causes for a problem and a solution could be as easy as turning it off and on again, most customers that I interacted with did not know or understand this concept and would sharply lose confidence in us if we were not magically able to touch the device and have it fixed so the quicker we are able to do so the better.

As a brand new apprentice, I will not have the ability to follow through with this pattern right away I will be able to, and plan to, take full advantage of others sharing what they have learned and absorbing as much information as I can to better contribute to the team and the final products.  I do believe that it is a very important pattern and as soon as I am in a position to help pass any knowledge that I have along to others in order to help them improve and develop in their trade I intend to take full advantage of that opportunity. It will help improve on three different aspects.  First, it will help the apprentice to develop a stronger toolkit moving forward. Second, it will help you develop leadership skills and presentation skills. Lastly, it will help your trade as a whole, having more skilled tradesmen working will help create better products and practices.

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

The Long Road

Problem

You aspire to become a master software craftsman, yet your aspiration conflicts with what people expect from you. Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills.

Solution

The solution the text offers is to first accept that what you want to become might be strange to others, and second to always think in the long term. Value learning and long term growth opportunities over salary and traditional notions of leadership. By focusing on your long term development, you are enriching yourself with a set of skills that aide learning, problem solving, and developing strong relationships with your customers. Keep in mind the length of your journey, if you have 20 years of work ahead of you, you have plenty of time to master your skills. The text mentions that this pattern is not for someone who wants to become CIOs or product managers, or filthy rich. Thankfully the software development field is constantly changing and new opportunities are always available.

I think this pattern is a good grounding for anyone who may be a little too ambitious, and may take promotions without understanding how this may affect the Long Road. Unfortunately, sometimes taking a promotion means a break from learning, and while you may be making better money, you may be setting yourself up for failure down the road, or at least you want have the same skills and knowledge you would if you continuously worked on being a software craftsman.  I do think it’s important to always consider the Long Road, where you are in your career and what kind of job you want. I think this pattern is subtlety saying that taking jobs as mangers or corporate executives may not be as rewarding as working on their craft their entire career. This pattern is a good reminder to me to keep the long road in the back of my mind and focus on always putting myself in a position where I can learn new things and hopefully avoid burn out.

The post The Long Road appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.