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.