In this portion of the Individual Apprenticeship Patterns, it gives an overview about how the new coming of an apprentice can impact a development team that is filled with well-experienced craftsmen or developers. Apprentices by their nature are new, and inexperienced first hand, and therefore they are open to learn ideas and techniques used by the craftsmen around them. Assuming that most of the experienced craftsmen have 10-20 years experience, they are unable to further their skills because their only primary concern is to just get the job done or delivering the next project.  In order for a development team to improve its dynamics with new ideas and techniques, the apprentice can be one of the main components to improve or repair the team’s passion and enthusiasm.

“Most teams are not hyper-passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain. Therefore, enthusiastic apprentices can often succumb to the urge to fly under the radar.”

The quote struck out to me because it shows the apprentices can give in or succumb to the ways of the experienced developers. As an individual, I want to be the type of person to bring enthusiasm to the team and to allow a flow of passion and excitement into the team. To me, maintaining a positive vibe and atmosphere allows everyone in the team to communicate effectively and consistently.

“On a team that is open to the excitement and contributions of an apprentice, you will provide some unique qualities that more experienced developers rely upon, such as unfettered imagination and enthusiasm. This is the time in your career when it makes the most sense to take risks and speak your mind. You have very little to lose. Your ideas and passions will add intelligence and diversity to your team.”

I found this quote extremely useful because it supports my idea that as a team member, having a passion about the work environment or project can bring positive outcomes for the team, and good things will happen. I fully agree with this Apprenticeship pattern because it promotes an amusing and enjoyable atmosphere for every team member, which can be traced back through the conscious or subconscious actions of the apprentice.

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

The “Confront Your Ignorance” pattern offers the next steps after you’ve followed the “Expose Your Ignorance” pattern. It’s not enough to admit that there are gaps in your knowledge; an apprentice software developer needs to be willing to do the work to fill in those gaps. The book suggests several ways to go about this. You might read introductory articles about the subject, start making a breakable toy, ask experts and peers if they’re willing to share their knowledge, or learn alongside someone else. Personally, I think learning with breakable toys would be the most effective strategy for me. I understand what’s going a lot quicker if I can try something myself and see it in action. I’ll also keep in mind asking peers and mentors. A lot of the time, I won’t be able to figure out something that’s obvious to someone who already has knowledge in a certain area on my own.

The writers emphasize that this pattern needs to be used with “Expose Your Ignorance.” Confronting your ignorance without exposing it means fostering a culture where failure and being seen learning are shameful and must occur in secret. It will also probably be more difficult and time-consuming if you don’t ask for guidance when you’re stuck. Exposing your ignorance without confronting it means you won’t be able to solve any problems outside of your particular niche, and others won’t appreciate it when the gaps in your knowledge prevent you from fulfilling your responsibilities.

This is also the first time the writers have mentioned a situation in which you should prioritize the job over the apprenticeship. It’s possible to be so caught up in your drive to learn more that it gets in the way of delivering the product. You might also be tempted to go about solving problems in a way that helps you learn what you’re trying to learn, but is impractical for others. You should be striving to improve your craft, but not at the expense of your team and your duties. Part of being an apprentice is putting the needs of your community before yourself. These guidelines provide a good balance between the greater goal and what’s more immediate.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

This semester, I am tasked with writing 10 blog posts, each being a reflection of a pattern defined in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye – this is the first of those blog posts.

This week, I will be writing a reflection on the “Breakable Toys” pattern.  The use of this pattern arises in the situation where a developer feels like failure in the workplace is not an option, and desires a safe space in which he or she can make mistakes and not suffer terrible consequences as a result.  Most people believe that failure is one of the best ways, if not the best way, to learn anything and so, if a person feels like they are in a situation where failure is not an option, it becomes harder for them to learn in that situation.  The “Breakable Toys” pattern is the solution for developers in a similar situation to the one I have just described.  A “breakable toy” is a personal project that is similar in toolset, but not in scope, to a system that you would typically see at work.  The idea behind using a “breakable toy” is that it allows you to try your ideas and techniques, safely, even if they lead to a catastrophic failure.  On this scale, the outcome of your attempts will only affect you, giving you the freedom to learn from your efforts without the fear of affecting others in the process.

The reason I chose this pattern to be the first subject of reflection in this series, is because it is a pattern that I already try to utilize in my own life.  I am currently trying to land my first internship as a developer and a couple of the companies I have been in contact with have asked me to complete coding problems (as you would expect).  I am a person who has a slight fear of failure – not enough to prevent me from trying to achieve things, but enough to give me a ton of anxiety in ‘make or break’ situations – so I began creating “breakable toys” to refresh my knowledge of data structures, algorithms, and fundamental programming concepts.  These “breakable toys” were quite useful to me, and they helped me to solve the programming problems, posed by my potential employers, in the interview process.  I also found a lot of enjoyment in creating “breakable toys” and solving coding challenges, so I have started to make more of an effort to make that a regular activity in my life.  I believe I am starting to utilize another pattern covered in the book: “Practice, practice, practice”, which will likely be the subject of next week’s reflection.

Thanks for reading.

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

Problem: You feel your job depends on you delivering a solution written in a specific programming language and of the same standard of quality as your teammates. Alternatively, obtaining a job in the first place depends on your proficiency in a specific programming language.

Solution: The text suggests picking a language and becoming fluent in it, as it will be the main language you will be using for the next few years to solve problems. It’s a difficult choice to make, especially when looking for jobs that may been looking for specific skills and languages. It’s “important to carefully weigh the options, as it is the foundation upon which your early career will be built.” One good way to gain experience and become fluent in a language is to actually have a real problem to solve, and to “seek out opportunities to create feedback.” Becoming fluent in a language allows you to start working more on test-driven development, allowing you to check your assumptions and aiding development of new languages.

This pattern has good advice, and it’s not the first time I’ve heard someone suggest working on one language and perfecting it instead of trying to learn multiple languages at the same time and expect to be fluent in each one. An interesting tip from the text was building a toy application in the language you’re trying to pursue a job with, one that your prospective employer would be able to access. Good learning experiences come from solving real problems, school gives you a good foundation to build upon and learn from the problems you solve in your professional career. Working in the field and running into real problems, the ability to work with other people and learn from them is a big part of gaining skill. I think Java would be a practical choice to become fluent in as it’s a high demand language that receives a lot of bad press but it running on 3 billion devices. The book also mentioned the community behind these languages and all the resources you have at your disposal. They suggest taking advantage of the support network you have and attending local meetings related to that language.

The post Your First Language 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.

This week I read the apprenticeship pattern “Be the Worst”. With this pattern essentially says that once you become one of the best on your team, and you aren’t learning as much, you should put yourself in an environment where you are the worst and you know almost nothing. By putting yourself in the situation where you are the “worst”, you are surrounded by engineers who are better than you and are in an environment where there is a lot more to learn.

What I found the most interesting about this pattern is the author’s willingness to leave what most would consider an ideal situation and put yourself in one where the odds are stacked against you. For most people, being the worst on a team isn’t the goal. Most people want to grow and reach that level of expertise where you are nicely paid, do your job comfortably, and are looked to others as a leader, this pattern suggests that this means the end of your growth. After really giving more thought to this pattern I realized that I agreed with the author, this is because applying this pattern makes you a lot more marketable. If you apply this pattern it will ultimately give you more expertise in more different domains making you much more marketable and increasing your job security.

I agree with almost everything about this pattern, but I am not sure if it is the safest way to go about this growth. The author referred to this as a “sink or swim” strategy so while it is true that it might be a very good way to learn and grow, for some the risk might not be worth the reward. It is still possible to grow even if you are the best, nothing is stopping you from learning more and continuing to the be the best where you currently are.

In conclusion, I think that this is a useful pattern but I don’t think it should be followed exactly as it is stated due to the high risk. What I have taken away (and will try to apply) is that I should try to put myself in situations that will promote growth.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

This week I read the apprenticeship pattern “Be the Worst”. With this pattern essentially says that once you become one of the best on your team, and you aren’t learning as much, you should put yourself in an environment where you are the worst and you know almost nothing. By putting yourself in the situation where you are the “worst”, you are surrounded by engineers who are better than you and are in an environment where there is a lot more to learn.

What I found the most interesting about this pattern is the author’s willingness to leave what most would consider an ideal situation and put yourself in one where the odds are stacked against you. For most people, being the worst on a team isn’t the goal. Most people want to grow and reach that level of expertise where you are nicely paid, do your job comfortably, and are looked to others as a leader, this pattern suggests that this means the end of your growth. After really giving more thought to this pattern I realized that I agreed with the author, this is because applying this pattern makes you a lot more marketable. If you apply this pattern it will ultimately give you more expertise in more different domains making you much more marketable and increasing your job security.

I agree with almost everything about this pattern, but I am not sure if it is the safest way to go about this growth. The author referred to this as a “sink or swim” strategy so while it is true that it might be a very good way to learn and grow, for some the risk might not be worth the reward. It is still possible to grow even if you are the best, nothing is stopping you from learning more and continuing to the be the best where you currently are.

In conclusion, I think that this is a useful pattern but I don’t think it should be followed exactly as it is stated due to the high risk. What I have taken away (and will try to apply) is that I should try to put myself in situations that will promote growth.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

As an apprentice or a developer, your career begins with you choosing one language and mastering it. This language will be the grounds at which your early development is going to be based on. It does not have to be big; everything begins with you taking a small step. The best way to learn a language is to work with an expert in it. This is because feedback for your work is very important apart from you having someone who will boost your morale in learning such a language. Your first language is not only the foundation of your career but the pivot at which you will learn other languages.

So far, this book has enlightened my taught very much and I am really happy for laying hands on such a materials. I totally agreed with every point made in the aspect of the book. I will say it is a wake-up call to me and for my colleague students who will want to excel in the programming industry. I deemed it very important to have one language mastered and any other language could be learnt afterward than trying to learn two or more languages at the same time; you will end up haven a shallow knowledge in all of them.

Also, haven someone as a mentor is as equally important as your choice of life. There have often been times that I went through tough time trying to do things myself and there were times I had thing very easy with the help of an expert even though I did not like his style of mentoring but after reading this portion of the book, I have now come to realized why he did what he did; he didn’t wanted me to be solely dependent on him to do my work. I used to study ahead of what I was assigned to do before our meetings in order not to appear before him looking stupid and some time he only ask questions which lead me to solving my own problem without him given me the solution. I can clearly differentiate my level of production on those days we worked together as compared to the time I worked on my own especially the time spent in solving a problem.

In conclusion, I will say this portion of the book has boost my morale of choosing and mastering one language before trying to learnt any other language and I am also reconnecting with the expert I have worked with in the past as a mentor for my career.

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

A very important apprenticeship pattern to keep in mind is Draw Your Own Map.  The pattern discussing the importance of planning out the next steps that you need to take in your career.  It is important to talk to your bosses and others that have been in the field longer than you about the direction that you need to take to advance your career, but it is important to note that while you should listen to what they have to say and take it into consideration do not blindly heed their advice.  When you do this, you are no longer in control of where your career and to a degree where your life is headed.  You need to sort through all the advice you are given and decide if it is in your best interest to follow said advice. One thing that I have always believed in and kept in mind when following advice of others or handing out advice of my own is that it is very easy for someone else to tell you what you should do because they don’t have to wake up and deal with it tomorrow.  By this I mean that ultimately the path you choose and decisions you make will impact your day to day life, career, and happiness.  Most of the time while your advisor may care what happens and worry about if you will succeed they don’t have to feel the pressure of what happens or the negative or even positive consequences from that decision.  You need to remain in control of your own life and career.  The best way to do this is to draw an actual diagram of where you want your career to head and what you need to do to get from point a to point b.  Life isn’t that simple though and things change so it’s important to constantly examine the map to see if you are on the right track.  If not see what you need to do to get back on track, or maybe things changed and you want to take a new direction either from a new-found interest or responsibility change in your life and then it’s time to redraw your map to have a plan of your next steps.  No one else is going to do it for you or care as much about the success of your career as you.

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