Category Archives: Apprenticeship Patterns

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.

Sustainable Motivations

Problem

Working in the trenches of real-world projects is rigorous, sometimes tedious, sometimes exhausting, often frustrating, and frequently overly chaotic or constraining.

Solution

The text suggests ensuring your “motivations for craftsmanship will adapt and survive through the trials and tribulations of The Long Road.” You must develop your technical skills because you will often find yourself working with “ambiguously specified projects with customers with shifting and conflicting demands.” There are times when you’ll love your job but there may be days, weeks, or months when you may question you motivation to the craft. Your job will present you with tedious, vague defined, and needlessly complex problems and you may have to deal with bureaucracy, difficult personalities, and spotty leadership.

…there is not much overlap between the kind of software that makes money and the kind of software that’s interesting to write…. If you want to make money, you tend to be forced to work on problems that are too nasty for anyone to solve for free.

—Paul Graham, Hackers & Painters

In More Secrets of Consulting, Dorset House, Jerry Weinberg describes this phenomenon as the Golden Lock: “I’d like to learn something new, but what I already know pays too well.” The risk of the Golden Lock highlights the importance of The Long Road, which requires ambition to attain mastery.

I think this pattern has good insight on maintaining motivation to become a software craftsman. It had some interesting examples explaining why you should avoid getting stuck in the Golden Lock, where you may find yourself not enjoying what you do but may stay there because you are making good money. It’s important to keep balance your passion and other aspects of your life, this ties into the “Nurture Your Passion” pattern. Another good tip from the pattern is the importance of developing your skill because you will be working with a variety of people who may not understand things at the same level or might make your job harder. I believe this pattern will help me in my professional career, it’s a good reminder to learn new things, work with different people, and to sustain my motivation to avoid burnout or Golden Lock.

 

The post Sustainable Motivations 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.

Practice, Practice, Practice

No one is born with the skills needed to be an expert in their craft and very rarely are skilled immediately after learning how to do something new.  As the new member of the team you may not notice it, but it took your other team members years of practice to get to where they are and you can get there too.  Taking risks and making mistakes are important parts of learning new skills and honing your craft. Most work environments provide very little opportunity for young developers, or apprentices in most fields, to make these mistakes or the time to work through them on their own.  It’s important to put aside time to work on a personal project or two in order to work on new skills or just get more comfortable with the skills that you already have.

 

When I worked for Geek Squad I would often be at the counter talking to customers and would have to try and identify what the issue with the computer was and either perform a quick fix or document the specific issue for intake and extended repair.  While we had the opportunity to make some temporary mistakes or try a fix that does nothing, we did not have that luxury at the front counter when working directly with customers that expected us to know exactly what command to run, or the location of every setting for every system and operating system.  What I chose to do was to buy a cheap laptop, take it home and essentially find various ways to break it. In this low stress environment, I was able to get more knowledgeable with different systems and common problems.

 

This is a tool that I intend to use as often as possible when starting a new career.  While I have had practice and learning while completing assignments for the past four years; real world projects and capacity of assignments will vary greatly from what I have done so far.  My plan is to clone my workspace at home to an extent. This will allow me to create a sandbox to try new solutions without breaking programs or causing more work for my other team members. I believe that this is a double edged sword though and you need to be careful with how much additional work you take on without finding a hobby and personal life to balance it with.  I find the breaks beneficial because they allow me to think about something else and that’s when solutions often become clear; getting too consumed with solving a problem that you are practicing on you no longer see the forest through the trees and risk burning out.

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

Breakable Toys

Problem

You work in an environment that does not allow for failure. Yet failure is often the best way to learn anything. Only by attempting to do bold things, failing, learning from that failure, and trying again do we grow into the kind of people who can succeed when faced with difficult problems.

Solution

The solution the text offers is to build “toy systems that are similar in toolset, but not in scope to the systems you build at work.” Experience is build upon failure and success, having a more or less private space to seek out failures in order to learn from them. When implementing this pattern, the text suggests making your systems relevant and useful to your life as an apprentice. Suggestions include building a wiki, calendar, or address book.

“Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects.”

The projects you take on may be excessive and not complete but having the ability to fail, and find solutions trial and error will benefit you in the long run. Maintaining a wiki leads you to learn about things like HTTP, REST, parsing, web design, caching, full-text search, databases, concurrency, and possibly data migration. Other forms of breakable toys include games like Tetris and Tic Tac Toe, blogging software, and IRC clients. The intent of Breakable Toys is learning new things and allowing yourself to learn from roadblocks that might occur.

The idea of building a wiki to record what you learn is similar to this blog in that I am tracking my progression as an undergraduate seeking employment and mentors to help become a software craftsman. I’ve been using WordPress for some time and have slowly learned more about PHP, HTML, CSS, and SQL databases. I think the Breakable Toys pattern is an essential part of learning new and complicated projects. I liked the idea of creating other tools that help you in other aspects of life, like making your own calendar or address book. My first angular 2 project could be considered a breakable toy, I didn’t know anything about Angular and very little about Javascript but having the time to sit down and create a workable web app helped me learn about something new and has prepared me more for the Angular project I’m working on now.

The post Breakable Toys 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.

Sweep The Floor

As a new apprentice and low man on the totem pole you should be ready and willing to do the small unglamorous, but necessary jobs that need to be done on a daily basis.  You need to swallow some of the pride and ego that you may have developed while solving assignments in College and realize that you need to start from the bottom again and that you need to adhere to the team dynamic that you are joining, they already have a working relationship and have already built up trust with each other that they don’t have with you yet.

While this is just an analogy sometimes it is a literal translation, much like it does in the book.  When I was in high school I worked in a woodworking mill making hardwood flooring and wood trim and molding.  So there was always a lot of sawdust and dirt flying around.  Whenever we were swapping out stacks of wood to make more, or changing blades someone was expected to sweep and clean the tables of wood chips.  This wasn’t a glamorous job and no one wanted to start sweeping in the little bit of time that we had to rest in between handling and stacking wood flooring, but it was necessary in order to keep an organized work area.  As both the youngest and newest guy that responsibility usually fell on me.  While most of the time, especially at the beginning, I hated doing it instead of being able to take a full break as time went on it helped integrate me into the team.  I started getting the respect of the other employees and the boss because I had shown that I was there to work and wouldn’t make others pick up my slack.

That helped me form the belief that whenever you go somewhere new, whether it is in a new field or just a transfer to a new location that you should keep your head down and focus mainly on doing your job.  This isn’t to say you shouldn’t socialize and make friends, but you shouldn’t get too relaxed that you fall into some of the bad habits that other team members may have developed and then you start you off on a bad foot.  Be ready to be assigned the worst tasks that the team gets because they still need to be completed, and do them to the best of your ability; even if it is something a tiny as updating or proofreading some documentation.  Some may not seem like it’s going to change the world, but it needs to be done and your quality of work will show through no matter the task.

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

Practice, Practice, Practice

Problem

The performance of your daily programming activities does not give you room to learn by making mistakes. It’s as if you’re always on stage.

Solution

The book suggests taking the time to practice your craft somewhere without interruptions, in an environment where you can feel comfortable making mistakes. Ideally we would use the technique “deliberate practice”, described in K. Anders Ericsson’s research: a mentor would assign you exercise based on their knowledge of your strengths and weaknesses. The mentor would help you evaluate your work and then you would work together to create the next exercise. The mentor would then use the experience of working with other students to create more challenging exercises that add small chunks of abstract knowledge that allows you to hone your strengths and correct weaknesses. Unfortunately we do not live in an ideal world and a lot of our practice on the job. The first example the text mentions is called “code kata”, which is essentially a practice session that some companies are starting to utilize for their teams. The text mentions another pattern, Breakable Toys, the ability to work on a piece of software in a stress free environment where you have control of everything. Finding new challenges and working on problems that are harder than you’re used to can help keep you master your craft.

The pattern had good advice and good information. The idea of having “code katas” seems like a good way to practice your skill and see what other people are working on. I think most developers do this already but the textbook mentioned the Breakable Toys pattern, where you take time to develop software in a stress-free and playful environment. I think it’s important to get periodic feedback, the text mentioned if you aren’t getting periodic feedback you could be developing bad habits. I think it’s important to always practice and find more challenging problems. I think having unique experiences with developing keeps an interest in the subject and avoids created burn out from seeing the same language or pattern you’re used to working with. Reading about this pattern has reminded me to try to always keep an interest in the subject by creating unique challenges,  practicing, and seeking feedback.

The post Practice, Practice, Practice 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.

Craft Over Art

“Craft Over Art” is a pretty straight forward apprenticeship pattern that is easy for many to overlook.  At its foundation it means that you’re program and code can look elegant, but the main focus should be that it is useful.  You can’t get too caught up in the elegant design of your code that you sacrifice functionality.  This can be a difficult balance to find though because programming is something that you need to present to a customer and if there is no beauty at all then the customer won’t want to accept the project as meeting specifications.  The pattern also raises a strong point that if the software breaks it may be better to make a quick repair that solves the problem that may not look nice, but it gets the program up and running again.  We should see ourselves as craftsmen that need to make something work as the main priority, the same as an electrician for example.

A friend of mine is an apprentice electrician and this pattern reminds me of a conversation that we had.  He was describing an electrical panel that he had to wire.  He was excited with how neatly and organized it came out.  While our conversation didn’t specifically get into the topic of functionality it was a simple panel and the functionality was implied.  As a craftman the functionality of his project was so fundamental that it was not even thought about to mention.  The fact that he  completed it means that it met its functionality goal.  The emphasis was on the beauty that was achieved.  He put craft over art and since the art was optional and a preferred goal, but not required, that was the bragging point.  Because it was above and beyond the standard.

After thinking on this post I hope to move forward with this in mind not only for programming, but in most of the things that I do.  The baseline for success in programming should be two simple questions; “is it functional?” and “does it solve the original issue?”  If you’re able to answer yes to both of these questions then we can start working on the artistry and beautification of the code.  While a certain level of beauty may be important to the client I feel like if it is not functional than no amount of beauty or elegance will fix that.

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

Find Mentors

It’s important to realize that the path you are taking (it doesn’t matter what path that is) has more than likely been traveled before, or at the very least where you stand at the beginning of your career is where many have stood before you.  There is no need to reinvent the wheel and learn all the ins and outs while trying to determine and travel your career path without guidance.  There is an abundance of craftsmen with a career full of information out there, whether it is your boss, a senior team member, or just someone in the field that you look up to.  What is important is that you seek them out and develop an open dialog back and forth with them so you can prosper in whatever you decide to do.  Ideally you want to find a master craftsman that has walked a good distance along the path and not someone who is only a few steps in front of you.  While you should still develop a relationship with the person in front of you, and is the basis of other apprenticeship patterns, it is not as a mentor and not the topic of this post.  Your mentor should also be ready and willing to accept the responsibility of taking on an apprentice.  It is a very fulfilling and very important relationship to develop in your career and will benefit you greatly to learn from their experience and grow as a developer.  Remember though that your mentor does not know everything though and is not infallible.  There should be a respectful, open, back and forth communication between both of you.  A communication designed not just to receive directions and blindly follow them to build your career, but one where you can ask why they made those choices in their own career or why they are recommending this course of action to you.  One that is strong enough not to crumble if you take in your mentor’s advice and in the end still decide not to follow it, but to take a different route that they may not agree with but still respect your choice.

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

Find Mentors

Problem

You’re walking along a path with no idea of what’s around the next corner or how to prepare for it. You need help and guidance.

The solution the book offers is to seek out those who have gone ahead of you and strive to learn from them. Since our field is fairly young, it can be difficult to find someone who is truly a master craftsman. More than likely you will get support from a series a mentors with varying degrees of mastery. Help can come in many forms, you can get help one-to-one with someone or remotely via the internet. While an apprentice is trying to find mentors, we must remember we are all walking “The Long Road” and no one knows everything. More problems you might have is finding a mentor who in interested in mentoring or who isn’t intimidated by the task of being responsible for another persons learning. It may seem risky to ask someone for help and fear rejection but the payoff is worth it if your offer is accepted. Just as people will be ahead of you, there will also be people who are behind you. You are also tasked with finding those who you may offer to help with information you’ve learned. Passing along what you’ve learned in one of the ways you can being the transition into journeymen status.

I think it’s super important to find someone or a group of people to ask to pass on what they know about the current state of our field. I think work is a great place to meet people that can offer you their skills and knowledge, especially because you will be building relationships with these people and seeing them every day. The text advises picking a tool, library, or community that has an active mailing list and learning the values of the community. Learn who the teachers are and seek out those who may be interested in offering help, I would consider this a great idea. I think sharing what we’ve learned if very important, it helps everybody, it helps the world. I would be super grateful for anybody who’s willing to take the time to share what they’ve learned and I know some people enjoy sharing their knowledge and would be flattered if someone asked for their help.

The post Find Mentors 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.