Apprenticeship Patterns – Be The Worst

Let’s start out this one with a hypothetical situation. You graduate college with a Computer Science degree. You walk the stage knowing that you have a job lined up. You are excited enthused and ready to learn some new things! Good!

Fast forward 3 years. You are now the person at the company that everyone asks questions and expects quality answers and advice from you. You feel like you have repeated the same thing for the last 6 months.  You have gotten into a routine of doing the same thing over and over and over AND OVER again. Long story short, you only have three years of experience and you have already maxed out your potential at this company.

This is the exact situation that Oshineye and Hoover try to help you overcome with their apprenticeship pattern “Be The Worst”. Obviously, this title is a little misleading but the solution is clear. You want to be the worst developer on a team. Not on purpose but naturally. You should look for a team with developers that are way more experienced than you. You will pick up their good habits and drop your bad ones. They will correct your mistake and teach you efficiently without you even knowing it. The authors have a great outlook on it : “Being in a strong team can make you feel as if you are performing better. The other members of that team will often prevent you from making mistakes, and help you recover from mistakes so smoothly that you won’t realize that you may not be learning as much as you think.” (Oshineye, Hoover)

I enjoyed this pattern because I feel as though I am going to be in that boat myself. I feel as though my first job will teach me a lot but I don’t want to get tied down to one job forever. This pattern actually made me feel very comfortable. For some reason, I had always thought that my first job out of college will be my last. I like the fact that it is acceptable and recommended to leave a job that you aren’t learning from. I like it because I am always trying to pick up new skills and I can’t wait to be fully emerged in the industry! With some experience under your belt, you can open yourself up to new options and jobs that you would have never thought you qualified for. This pattern will be invaluable to me in the future.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: The Deep End

In this apprenticeship pattern, the authors present a problem that I’m sure many rising computer science professionals have encountered early on in their careers. They describe the context of the problem as being when one feels they are stuck in a rut, falling short from their colleagues in terms of knowledge and skill. The authors explain that the only way to address this kind of issue is to dive head first into the “deep end.” What they mean by this is that the only way to advance one’s skill, knowledge and, most importantly, confidence is to take on harder tasks that are more challenging. The authors stress the fact that it is to easy to fall into a pattern of complacency and that it is essential to take risks in order to become a better software professional. One particular quote from this pattern that really stuck with me was the following:

“Risks are opportunities seen through the half-shut eyes of fear.”

I think that fear plays a huge role in decision making when it comes to computer scientists. Most notably, the fear of failure may cause a developer to hesitate in taking on a larger role within a team or committing to working on a difficult project outside of their comfort zone. I think its important to remember that even the most brilliant developers have made their fair share of mistakes and the only way to get better is to continue making mistakes because you are bound to succeed at some point if you keep trying. In this pattern, the authors give a real-life example of how this ideology can serve to benefit a developing professional by providing testimonial from a developer named Enrique Comba Riepenhausen. Enrique found himself taking on a new role at his company that entailed much more work than his previous role. Instead of becoming overwhelmed with fear and hesitation, Enrique rose to the occasion and put his best effort forward. As a result, Enrique excelled at his position and was able to construct a customized platform for his client’s needs.  Since then, Enrique describes having a plethora of opportunities including being able to travel the globe doing what he loves.

After reading this patter I decided to take the advice given by the authors in the Action section by doing the following:

  1. Make a list of the largest successful projects I have contributed to.
  2. Determine the dimensions of complexity as a means of measurement for each project listed in step 1.
  3. Create a chart with the information from steps 1 and 2.
  4. Add any new projects I take on to the chart in order to visualize the trajectory of my career.

 

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog 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.

Post #20 – Reflection on the “Nurture Your Passion” Pattern

This week, I will be writing a reflection on the “Nurture Your Passion” pattern.  This pattern addresses developers who feel that their work environment is stifling their passion for the craft.  I don’t have any personal experience with this problem, but I wanted to reflect on this pattern because I found the advice about how to nurture your passion to be quite useful.

The first bit of advice, provided by Oshineye and Hoover, is to work on things that you like and spend time building Breakable Toys, which I reflected on in the previous post of this series.  The second bit of advice they provide is to seek out kindred spirits, or, other people who are also passionate about software development.  They recommend seeking out a group that focuses on something you want to learn about, and keeping a blog about things that interest you in the field of software development.  The third bit of advice they provide is to immerse yourself in the literature of software development.  This tip, in particular, felt relevant and useful to me because I have begun seeking out literature that can help me acquire knowledge and skills that will improve my employability.  Oshineye and Hoover make the point that studying the classes and becoming immersed in relevant literature can help reignite your passion for the craft.  I still feel very passionate about software development, but I will heed this advice and refer to it in the future if I ever find myself in a rough place.  The next piece of advice they provide is to draw your own map, which means to seek out organizations that will offer career paths that you have a passion for.  Their final piece of advice is to not be discouraged by demoralizing tasks and coworkers, and to set clear boundaries that define the kind of environment you are willing to work in.

I think that I have been doing a good job of nurturing my passion, so it is a positive reinforcement to find patterns like this one, in the book.  I am still passionate about software craftsmanship, and I don’t see it diminishing anytime in the near future.  This pattern has further strengthened my foundation and provided me with advice that I will continue to carry with me, as a developer.

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

Turning Dummy Links Into Real Links

Often, when I’m designing a website, I will sketch out a diagram of what I think the relationships between different pages will be. Here’s an example of one of my early sketches:

Even if the finished product is vastly different from the original diagram, sketching out some of the pages and their relation to one another helps me to get a better idea of the overall layout of the website. Skipping this step has, in the past, led to a jumbled mess of pages with no real organization. It is much easier to change a few pages’ organization when problems arise rather than having to redesign the entire website from scratch. The design step is also great for determining parent-child relations. In the above diagram, for example, every page is a child of the HOME page, and all of the child pages link back to HOME. The first generation of children are the WHAT IS HOSA?, CONFERENCES, CHAPTERS, as well as the three callout pages HEALTHCARE PROS, STUDENTS, and TEACHERS. Under each of these pages exist multiple other pages or sections all related under a common theme. Some of these pages link to related pages that exist elsewhere, such as the Find a Chapter link under both CHAPTERS and STUDENTS.

The overall goal here is to make the site as easy to navigate as possible. When I have a basic skeleton of the site set up, I will often ask someone unfamiliar with the organization to attempt to perform a particular task. If I have done my job, they will be able to navigate the site without knowing more information than what I have given them in the description of the task. I watch closely as they move around the site, asking questions to clarify why the user makes certain choices. Things that seem obvious to me may be completely unexpected to a first time visitor to the site. This sort of testing allows me to make improvements to the flow and organization of the site.

 

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Craft over Art

The pattern Craft over Art in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses the opposite approaches one can take when writing software…

On one end of the spectrum there is practicality. This would be considered the “craft” portion of this apprenticeship pattern [AP]. The best way I can describe this side of the spectrum is with the idiom “don’t reinvent the wheel”. If a solution is already there, don’t go out of your way to rewrite it. Why would you waist your time? If there is no currently solution, then find the quickest and most efficient way possible that solves the problems and meets the customer’s demands [AP]. Don’t go above and beyond.

On the other end of the spectrum is the “art” portion of this pattern [AP]. This means that your solution should be beautiful and elegant [AP]. It should be a master piece [AP]. The tradeoff here is that creating masterpieces takes both time and money. Although the pattern seems to lean towards favoring the “art” side of things, it does suggest that there are times where you’ll have to find a middle groud between the two [AP].

I’ve mentioned this in the past and I’ll mention it again. If you truly want to be a master software developer, then I feel the advice this pattern gives is worth taking. However, in most cases, following this pattern doesn’t seem realistic. Companies have goals and deadlines that need to be meet. They aren’t going to want you to take a week to complete a task that can be done in a day just so you can make it perfect. Time is expensive, so if you can meet the customers demand in a day rather than a week then they are going to expect you to do so.

The pattern also notes how one should be wary about making something beautiful, yet useless [AP]. If you are going to take weeks to perfect something in which a valid solution could be developed in a few days you better be darn sure it is going to work [AP]. This is something that I agree with. Creating something that is useless isn’t craftsmanship or art. It is a waist of time.

Form an overall perspective I get what both this pattern and book are trying to preach. This pattern is great advice if you can find a place that will let you follow these practices. It just doesn’t seem practical. If you are given the opportunity to actually follow these guidelines I say go for it. I just don’t see it as being realistic for most people in most situations.

 

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s02.html

 

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

The One Thing All Newcomers Can Offer: Enthusiasm

The one thing that just about any recent college graduate has to offer a prospective employer is enthusiasm. While enthusiasm may help with getting in the door somewhere, once starting out on a new team of experienced developers the newcomer may be less willing to express that same enthusiasm. Although it may sound juvenile, the desire to fit in applies just as much in the workplace. This desire may prevent a newcomer from sharing valuable excitement and new perspectives with the team. Overcoming this fear of and sharing your excitement and creative ideas will be far more beneficial in increasing learning and value throughout your apprenticeship. In Apprenticeship Patterns, Hoover and Oshineye cover this topic under the Unleash Your Enthusiasm pattern.

If there is one thing that I am sure about, it is my desire to make a real difference through software development. I am passionate about making a difference and excited to begin this journey. I will admit, however, that I would be a bit hesitant to express this eagerness if other members of the team seemed to be skeptical of me. It would be far easier to take the conservative approach and try to match the excitement level of the team. Taking this approach is not the most effective strategy in these situations. It would be far more valuable to both the team and to the apprentice to fully embrace that enthusiasm and use it to inspire and motivate the team. Rather than viewing your excitement as an annoyance to the team, you should view it as an asset that will help the team.

When first starting out, it may be difficult to find ways to make any meaningful contributions to the team. You will need to earn the trust of the team before taking on risky tasks that may jeopardize the integrity of the work as a whole. One way to make contributions while also gaining the respect and trust of the team is to ask questions and unleash your enthusiasm. If you’ve found the right mentor, your enthusiasm for the craft of software development will be rewarded. This mentor will guide you, and you will give him or her a renewed excitement for the craft.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Concrete Skills

Summary

We all need our set of Concrete Skills that we can build upon.  There are certain types of soft skills that allow you to contribute to a team. Understanding which ones are important to flesh out and explore is very important. In our current landscape, having a working skill set with Git, Agile methods, and other collaboration tools is of the utmost importance.

 

My Reaction

Understanding and using Git in today’s development world has become ubiquitous. It seems that every job description contains some reference to Git or software like it. I agree that this is a necessary concrete skill that each developer should learn early in their education.

I see the need for me to better develop my experience with writing build files and understanding what they are used for. I can imagine that having a better understanding of this concept is a good place to start.

In the chapter, there was a reference to a CV. I was not familiar with the acronym and looked it up. It seems to stand for curriculum vitae. I had not hear of this phrase and learned that it is a written overview of a person’s experience and other qualifications for a job opportunity. It is like a more detailed resume. I intend in creating my own CV and adding it to my website.

Once this is created, I will review it and curate it as I learn more about my craft and better understand my experience.

The other interesting point of the pattern was the statement that your virtues must be a little more overt in the beginning. I will have to give this idea a little more thought as I struggle to understand its purpose.

I agree that these concrete are a very necessary part to a successful career. There were times where I had to leverage my Photoshop or video editing skills to get the job done. I also lended my programming skills to many minor projects at my previous jobs. These minor skill sets have helped me remain valuable in many business situations.

Finally, now that I understand what a curriculum vitae is, I will begin to make one on my website. This is the perfect place for something like a CV. Once this page is completed, I can add a link to it on my resume. This will allow me to keep my resume concise while offering a more comprehensive version of my previous experience.

CS-448
CS@Worcester
Week-6

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

Retreat Into Competence seems like the ideal apprentice pattern to apply this week. Our capstone team is in the process of discussing ideas for implementing the AMPATH application with offline capabilities. The problem is that I have become keenly aware of how complex this project is for me to even begin to understand. I’ve been noticing that my limited knowledge of Angular is certainly hindering my process. So I started to think to myself, “what can I learn more about that can help me move forward with the AMPATH project?” Then, and I’m not kidding here, I started thinking about this textbook trying to remember the name of the pattern that discussed what I should do when I feel I’m in over my head. I found it, and as the name suggests, I should Retreat Into Competence.

There’s an Angular tutorial by sitepoint that I have done portions of at least a couple of times before. It’s incredibly helpful and seems to cover every important aspect needed to develop applications in Angular. I’ve used it last semester when I first started learning both Angular and Typescript for the first time.  Now I’ve been finding myself going back to it again and again. I feel this is a great way to Retreat Into Competence because it’s something I’ve done before and become at least somewhat familiar with. Right now I’m in the process of going through the tutorial as thoroughly as possible to ensure I understand every piece of code that’s in there. I think I’ve got the CRUD (Create, Read, Update, Delete) part down, which helps boost my confidence a bit as I proceed to tackle the more complex topics. But I’m still Retreating Into Competence, and I know I have some more substantial learning to do before I can say that I’ve successfully finished applying this pattern.

Ultimately, I need to work on better understanding how the AMPATH application communicates back and forth to a remote server.  I had at least a high level understanding of the “Todo app” discussed in the sitepoint tutorial. And when I “retreated into competence” and started to go through the tutorial again in a meticulous fashion, Angular is seeming more clear to me than ever before. I am hoping to finish the sitepoint tutorial section regarding REST (Representational State Transfer) APIs before my next team meeting on Tuesday. Learning more about the workings of REST and mock servers should help provide some clarification regarding how the AMPATH server communication works. Then perhaps as the pattern suggests, I can “launch forward like a stone from a catapult” after momentarily Retreating Into Competence.

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

CS@Worcester – Fun in Function 2018-02-18 23:46:51

“The Deep End” resonated with me, not because I’ve applied the pattern before, but rather because I’ve been thrown into the deep end. When I took Data Structures at a different college over the summer, I found out the course was being taught using C, which I hadn’t yet learned. My dad accurately described the task ahead of me as, “Here’s a new [human] language. Write a novel.”

Worse, the professor was often unhelpful. The pattern, which encourages taking challenges and high-profile roles, warns that you could end up in over your head and drown in trying to apply it. I actually compared my emotional state those first couple of weeks to drowning in the middle of the ocean, because I was so out of my depth, no one could help me, and the consequences of failure were drastic. And I was failing for a while. Assignments were graded using an automated system that tended to give out 100s or 0s with no in-between, and 10 points got taken off for every day late. I fell behind and was submitting assignments late, which in turn gave me less time to work on the next one.

The Deep End identifies Find Mentors and Kindred Spirits as patterns that can be used to mitigate its risks. What eventually made me feel less like I was drowning was identifying the one tutor available for the class who seemed to know what he was doing and reaching out to him for help. He was accommodating and even offered to look at my code outside of his tutoring hours. It was, in fact, finding a mentor/kindred spirit that enabled me to salvage the situation.

Good things came of surviving the deep end. I was able to take Robotics the next semester because my knowledge of C made me feel more prepared than I would have otherwise. My Unix Systems Programming course this semester is also turning out to be much easier than it could’ve been.

The idea for action given at the end is also interesting. The writers suggest rating every project you’ve ever worked on using your own ways of measuring complexity or difficulty, and then plotting new projects that come along in a chart with the others. This seems like a good idea for making sure your career trajectory is going up and consistently challenging you instead of stagnating.

As a final note, the idea of applying this pattern by taking high-profile roles also reminded me of a principle one of my role models has: that if you’re given something you feel you don’t deserve, the answer isn’t to refuse, it’s to take it and work hard to deserve it.

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