For this weeks blog pattern post I will be looking into the pattern known as confronting your ignorance. The context behind this one is that you have identified the gaps within your skillset that are thereby relevant in your everyday work. The problem that will arise from this is that the tools and techniques needed to master seem unobtainable as you don’t know where to begin. These may already be around you with people around you doing them but there is an expectation you already have this knowledge. The remedy to this that you should pick one skill, tool, or technique and seek to fill the gaps of your knowledge about it. Finding out the most effective ways that suit your style. For some the best approach involves getting an overview of introductory articles and FAQs. While others may find jumping straight into the construction of Breakable Toys the best approach to understanding something. Whichever approach works do not forget to ask around your Kindred Spirits and mentors to see if someone already has the skill and if they will be willing to share their knowledge. Others may be actively seeking this skill as well which can allow you both to work towards this goal. There aren’t enough hours in a day to hone all your skills to a high level, so making necessary trade offs between them is something that will have to happen. This pattern is closely related to Expose Your Ignorance, but implementing it is a less difficult task to your pride since it can be down privately. But eventually you may have to Expose your Ignorance as well, since learning in public will allow an apprentice to being their transition to a journeyman. Taking the list of items from Exposing your Ignorance and striving to learn each one, while crossing the completed off is a good place to start. This way you can see gaps you maybe hadn’t noticed before. This pattern is important to say the least, one that most people should honestly follow if they need to.

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

I decided to read “Record What You Learn” for this week’s post. This one is pretty self explanatory, record what you learn. The pattern says to do just this, and explains that this is a way to review key learnings throughout your journey of software development craftsmanship. The pattern also notes that it is important to not let your writings become a graveyard for what you have learned. By this, they mean that you should consistently go back and review what you’ve written in the past to possibly amend the posts, or to find links to other notes you have written.

I agree that this is a very valuable “study” technique and it works for all facets of learning. The most difficult part of this, is that this is a very time intensive way to remember everything. As you learn more, the bigger the library of written lessons gets. This mean that every time you learn something, that review session gets longer. I think that this means that it is important to acknowledge that you simply will have to relearn things from time to time, but documenting what you’ve learned for higher level topics, is a great way to save time in the future.

While I do see how this could be difficult for an individual who is learning vastly different and often irrelevant topics when compared to each other, this is definitely something that can be used as part of a company project wiki. Large companies are constantly hiring new personnel who have to play catch-up to learn a code base as well as the coding styles of their peers. Having some sort of blog or wiki for the project could help these new-hires get acquainted with how the company functions and how to solve problems that are specific to the particular stack and business logic that the company is utilizing.

I do not know if I see myself personally following this advice, because this is not really my learning style. I tend to learn something by repetition instead of documenting what I’m doing. However, I do recommend that anyone who learns well via methods like flash cards, studying notes, etc, give this method of learning a try. It could be quite useful to someone who succeeds` when applying these learning methods.

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.

The Deep End in Chapter 2: Emptying the Cup of Apprenticeship Patterns is a pattern that reflects much of how I’m feeling lately. There are several places in life where this pattern pops up — often because you’ve realized that things feel stagnant in your career. Things need to change in order for you to grow and expand your skillset, and your current environment doesn’t reflect one of growth. The solution of this problem is to make a large life change and let the chips fall where they may. It’s scary to do this because you’re so comfortable where you are and with the work you do, but at the same time you’re stuck in a rut and you need some sort of upheaval in order to feel excitement once again.

I’m feeling this pattern quite a bit right now because I’m finishing up my degree at Worcester State. I’m not quite in a rut at the moment, although the next phase of my professional development is going to demand that I move forward at a rapid pace. Going through the interviewing process is tricky, because I feel constantly aware of the areas of knowledge that I lack expertise in. Obviously no one can know everything, and it’s more important that you’re capable of learning and being an essential part of the team. I think that being hired as an entry level developer is going to be interesting because you really do feel as though you’re being thrown into the deep end.

It feels extremely overwhelming to move into a workspace that you have no experience in, especially in my case where I have no current internships. I know what to expect on a general level, however I also know that there will be many things that I won’t fully understand until I’ve worked as a software engineer for some time. In order to learn any of those things, I’m going to have to fail from time to time. That’s exactly the point of “The Deep End”, and that’s exactly what I need to make sure I remember. If you’re never in a place where you’re failing, you’re never in a place where you’re setting and aiming towards goals.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

One thing that was brought to my attention when going through the computer science / software development major, was that many of us suffer from what I was told was “impostor syndrome”; the persistent feeling that I do not know anywhere near enough, and that fear that your are a hack or a fake. While this persistent fear is definitely a symptom of inexperience, it nevertheless is a challenge to gaining confidence in our abilities.

Thankfully the authors of Apprenticeship Patterns have developed a pattern for dealing with this fear in the real world. Their advice is when you feel overwhelmed by the volume of information you don’t understand yet, you should temporarily “retreat into competence”. By taking a short time to work on some problem which you do know well, you can reset your perspective and freshen your resolve to tackle the new challenges, bounding back like “a rock in a catapult”, using the backwards momentum to launch yourself even further than you would have gone originally.

While this is definitely a helpful strategy for compartmentalizing our learning experience, too much reliance on this pattern will result in mediocrity, as you would hardly make any meaningful progress and your skill as a craftsman will stagnate. The authors acknowledge this, and definitely warn against it, suggesting that retreating into competence should only be done with set time restrictions before we move forward again. Time boxing in this way will ensure we can regain our confidence and composure while at the same time making sure that we are always driving forward.

I definitely appreciate this pattern though and will definitely be applying it in the future to keep myself on track. It is remarkably helpful to be able to, as the authors put it “overcome the fear of your own incompetence”. By taking one step back and two steps forward, we can continue the march of progress at a more comfortable pace, and hopefully alleviate some of the fears and overwhelming feeling when facing the vastly expanding world of software development. This is definitely a pattern I have subconsciously been applying previously, but I will definitely make a more conscious effort to use it and time box myself properly to ensure stable progress.

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

On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my ninth individual Apprenticeship pattern I decided to blog about “Breakable Toys” pattern.

Summary

When you do not have much experience and you work in an environment where there is no room for failure and mistakes. Meaning mistakes are not tolerable, even if you can build experience from your mistakes/failure and grow and inevitably become successful the idea of failure is not an option allowed. Often the best solution to this problem is to build similar toy systems with a different scope to the one being built at work that will allow you to break it, test it, and budget for failure. This approach is the best solution because as a software developer having a comfortable safe environment where you are free to make mistake without any serious consequences. This approach will help allow you to learn from your mistakes and grow into a better software developer. When implementing this pattern it is important that the systems you build are relevant and useful to you. The book suggest: “For example, build your own wiki, calendar, or address book. Your solutions might be massively over-engineered for the problem they’re solving, and probably could easily be replaced by something off the shelf. However, these projects are where you are allowed to fail.” These are project ideas where only you are affected when mistakes or failure occur. As said in the book, “Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects.”

My Reaction

This pattern helps you understand the impotence of building “Breakable toys” because it allows you to build systems that you can break and learn from its failures and mistakes. I agree with this idea because the best way to success is through failure. However; in a work environment failure is not an option so the best way around that is to build your own toy. I found this pattern to be interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think, the reason being is that it has made me realize that I need to start working building “Breakable toys” that would give me some experience.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

The long and short of the pattern is to not accept a lucrative position or promotion if it takes you away from practicing your technical skills. If those skills aren’t constantly honed, they will be lost or become outdated before long.

A family friend was a midlevel manager at a software development company before he was laid off. He had gotten away from doing the technical work. The trouble was that most companies promote from within, so it was hard for him to apply for a job that he had before. It was also hard for him to start a job doing the technical side because those skills weren’t as fresh in his mind. There’s a good lesson to be learned from his story.

I often hear from people complain their manager is out of touch. The pointy haired boss  from Dilbert strikes a chord for so many for a reason. Perhaps more fitting to this pattern is The Office’s (U.S.) Michael Scott. While he has his moments, he is by in large an extremely incompetent manager. However, he does go on some sales calls in the series, and it is clear that he is a brilliant salesman. It seems that it is common that people are promoted to the point where they are inept at that position and advance no further.

Although the pattern does not quite suggest that people are promoted until they aren’t the best managers they can be, it seems to suggest that if you are no longer using your technical skills, you will become more and more out of touch with that side. You will no longer be on track to become a master craftsman when you accept this route.

I do not want that to be me. I would like to continue to grow and learn. I have talked to people who have a technical background and become something else, such as a salesman or manager. I have been tempted to take this route. I am not saying that I won’t do something similar someday, but for the time being, this does not fit into my goals.

My goal is to become a master craftsman. I’m aware goals change over time, but I would like to pursue this for a while before reassessing. I feel as though the reason I would change tracks if I found that this career was no longer what I wanted. I don’t think that will be the case, but it is a possibility. The one thing I know I won’t do is change tracks if I’m happy where I’m at. Sometimes what seems like the logical next step to advance your career can actually be more of a step back. It is best to instead to choose the path that will lead you towards becoming a master instead.

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

Hi dear readers. Welcome back to my blog. From now on I will be writing for different Apprenticeship Patterns that I will find interesting in the book to share with you.

I started computer science with 0 knowledge in coding, programming languages or anything else related to this world that I find beautiful nowadays. My very first programming language was the famous Java and not because it was my choice but because my first contact with coding was in Intro to Programming (CS-140) and the teacher had chosen Java as a language. Now that I think back three years ago, I am happy that I started my software craftsmanship with Java.

A summary of ‘Your First Language’ Apprenticeship Pattern would be that if you start your journey different from me (in the meaning that you can choose your first language), the book recommends you to research about it and try to figure out what is the most suitable language from you. It doesn’t have to be one of the most popular language but as every language has its own characteristics you got to pick the one you find more easy (or hard, if you like to challenge yourself). If you don’t trust your research skills than you can ask your friends who are familiar with programming languages and they will  be able to tell you the differences between a few languages and why they like what they like. Learning the language is not the only step of the process as you will be using this language forever to solve different problems you might come across. Remember, switching is always an option..

Most of my friends had started programming with Python which I have heard is a very easy language to learn and use. I remember when I started to learn Java I used to try and solve other problems (as much as I could) so I would get practice and in my first problems I was not using any other libraries. Practice is the key, believe me! A language is easy to learn but it has a lot of volume. Once my boss said: “Its not the language we should memorize, its the data structure” and I totally agree as in your journey you will work in different companies that will use different languages.

I really like that this is the first pattern included in the book as the first language is the first contact you have with coding. And don’t forget..Practice

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

Hello there! For this week’s blog I have decided to write about the chapter of our textbook called “Sweep the Floor”. The chapter caught my attention because of the small description of it. The description of the chapter was something along the lines of you are a new member of a software development team and you need to gain their trust. This is something that intrigued me because I will be starting in a software development team as a new member at the end of May, and I am not quite sure what to expect. I have never worked in a real-life software development team, let alone develop software full-time 8-10 hours a day 5 days a week. This chapter was something I was hoping would help me when it comes time to integrate myself into my new team come May. So the problem that’s set out in this chapter is basically the same as mentioned above, the team doesn’t know you, you don’t know the team, so how can you find your place and find out how you can contribute best to the team? The solution is somewhat elementary and what some would think of as common sense. The first part of the solution is to volunteer for some small, perhaps even mundane task that either nobody else wants to take on or is too busy to take on. Sure, this isn’t a task you went to college for four years to complete. Maybe the task is transferring some physical data into excel, or updating computer software around the office. It doesn’t matter what the task is, what matters is that by taking the initiative and volunteering yourself for the small day-to-day not so glamorous tasks, you are slowly gaining your teams trust and finding your place on the team. They will appreciate that you are taking a step forward and doing things that need to be done; getting in the trenches (so to say) and eventually this will lead to your team trusting you to take on bigger tasks that are more normal for a software developer like pushing things to production and writing major elements of a program. I hope to use this tactic in my workplace to quickly assimilate into my team and find my place.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.