Category Archives: Week 7

Emptying the Cup: Retreat into Competence

In this Apprenticeship pattern “Retreat Into Competence”, it explains that at times, an apprentice might need to take a step back from their ideas or objectives in order to fully approach the idea or objective effectively. This could mean that you as an apprentice may need to take a step back in order to clear your mind from what you know, and what you think you know to be able to allow new ideas and motives to flow into your mind, which would allow you to develop new crafts as an apprentice. Attaining these newfound ideas can be learned from your teammates and experts.

“Pull back, then launch forward like a stone from a catapult. Retreat briefly into your competence to regain your composure. Take some time to build something that you know how to build. Then use that experience to recognize how far you’ve come and how much you are currently capable of.”

I agree with this statement of retreating briefly into your competence. The way I see this idea is that it is basically telling you to reset yourself or revert yourself back into a new apprentice. This means that you have a fresh mind and you feel open to new ideas because you have the motive to learn new things from others around you.

“This pattern is most relevant for people who have stretched themselves far beyond their ability. If your apprenticeship has you taking reasonable-sized steps forward, taking on gradually increasing responsibilities and technical complexity, then you may not need to take shelter in this pattern. But if you are really struggling or are barely keeping your head above water in The Deep End, look for opportunities to temporarily retreat. Sometimes you need to take one step back in order to take two steps forward. When you do this, it is important to turn that backward movement into forward momentum as quickly as possible. That forward momentum is revealed in your possession of more knowledge and greater skill than you had yesterday.”

This part of the apprenticeship pattern was useful to me because it states that it is not good to pull back to far because you may find yourself to settle for initial failure and surrendering to the fear of failing. If I was in this position to shortly retreat from everything, I would use the time effectively to relearn what I already know in case if I missed something important such as an important basic fundamental instruction in a specific programming language. I feel as though if I did retreat to far back or for too long, I might not use my time wisely and may feel too comfortable in my retreat. This pattern will change the way I work and operate in my profession because now, I know that it is normal to retreat a little if I’m stuck on a software development problem, or any real world problem.

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.

Concrete Skills

While learning how to be a great apprentice is great, the main issue is getting to that point. Specifically being accepted onto a team or project, being hired by a company. To be a part of a professional team and become an apprentice is the first step and can be the hardest thing to accomplice for some.

As the book states, it is a risk hiring someone new and untested for teams out there. You may not be able to contribute to the teams work and you may not even be able to take care of automating simple manual tasks. So then how does one solve this issue? By having Concrete Skills. Having skills that will first of all get you through the HR filter and technical skills that can and will aid any team you are on. This makes the risk of hiring you on much lower, and makes the decision easier.

This apprenticeship pattern was not really at all surprising. Every step of the way, I was nodding my head. Learning concrete skills just makes too much sense in my head to be something anyone can disagree with as a valid way of making it more likely to be hired on to teams. Reading this apprenticeship pattern has not changed any of my thoughts on my chosen profession but has solidified the path I believed I would have to take in the first place.

The story the pattern offered did make me open my horizons when it comes to what count as concrete skills. Skills gained as a therapist would obviously be helpful in a team setting, but it is not something that would come to my mind readily. I mainly think of only technical skills, but social skills that can aid the rest of the team in ways I or they would not expect are also completely valid avenues to making it easier to hire oneself.

Also, looking at others CV’s and resumes, then pulling out the concrete skills that one can learn themselves and demonstrate easily, is a simple action that I can start doing now. Something obvious in hindsight that I should have been doing from the start.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Stay in the Trenches

This week I have decided to cover the “Stay in the Trenches” pattern. While the title of this pattern seems harsh, it is actually encouraging. One day in your career as a software developer, along the journey of the software craftsmen, you will encounter promotions. These will most likely be in the form of increased… Continue reading Apprenticeship Patterns: Stay in the Trenches →

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

Apprenticeship Pattern: Breakable Toys

This week I read the apprenticeship pattern called “Breakable Toys”, like the other patterns that I’ve read so far I think that this one is very applicable. This pattern suggests that one of the best ways to learn is through being able to try new things and do experiments that can and likely will lead to failure. The issue that this pattern addresses is that often times, we are not in an environment where failure is acceptable or consequence free and thus by having a “breakable toy” we are free to effectively try whatever we please.

I think that this pattern is extremely useful because it is very applicable in real life. Everyone has been in a situation where they wanted to try a new approach to a problem but didn’t because the risk associated was too high. When applied correctly, the risk associated with trying something new is almost nothing while giving you an increased opportunity of finding new solutions and learning new things. After giving this pattern a little more thought however, I realized that we developers apply it almost daily (often times not to an optimal degree). Take branching for an example, by working against a branch of the master code, you are essentially working on a breakable toy where you are free to try almost anything you please. Having the ability to work on a breakable branch of a product brings a level of freedom and productivity that working on a master branch never could!

This pattern has changed the ways that I look at my profession in the sense that I now have a better understanding the true importance of working on a branch for any change (even if it is miniscule) and test builds/environments. With the former you can for example, try implementing a feature however you please without fear of it breaking and halting the progress of your coworkers, and with the latter you can (for example) load test and try to break a “toy” version of your app without worrying about taking down production.

In conclusion, this is a great pattern that we use to a certain degree daily. This pattern can provide great benefits when applied correctly and result in catastrophic failures when not applied at all. I intend to use this pattern to continue learning as a grow in my career.

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

The Long Road

This pattern has reopened my mind on how the society expects us to function without taken into consideration what the individual passion is. I kind of knew many point mentioned in this pattern but didn’t know how to deal with them until I read this pattern.  It is true that the community I live in wants me as a young graduate to get a nice reputable job with lucrative sum of money. They would expect me to have solutions to problems at the tips of my hands. But the little I know is that learning is an ongoing process and takes place gradually. Implies I might get my four years college training and graduated alright but my learning doesn’t end there. As an apprentice, I should continue to learn in order to achieve that mantle of the journeyman. Looking up to satisfy the society would do me no good than to draw me back from the long term goals that I have set for myself. Being able to growth in this industry requires me to be patience and stay focus to my long term goals.

One thing that marvels me is promotions. I didn’t see promotion as a detractor until I studied this pattern. I usually would take promotions as a reward for your good and professional word. But after reading this pattern, I have come to realized that not all promotions are worth taken.  For example, as a software developer, taken a promotion to managerial position that has no connection with your previous duties will harm you at the long round. I would rather demand an increase in pay than promotion in order to stay focus on my passion for developing.

Also, it’s a norm, and as society demands, people would always seek a well paying job than seeking to develop their skills. It is quite challenging to work for less money when you know you can get more for the same input. But that notwithstanding, one need to weigh passion and long term ambition for his career against the present even though, I think the long term would pay you than your present.

 

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

Post #22 – Reflection on the “Craft over Art” Pattern

This week, I will be writing a reflection on the “Craft over Art” pattern.  This pattern addresses developers facing the problem of wanting to create something special for the client, but there already exists a proven solution at your disposal.  I chose to reflect on this pattern because I think it’s a pattern that all developers can relate to, at some point in there career, and I liked the quote that Oshineye and Hoover provided to distinguish craft from art: “I would describe programming as a craft, which is a kind of art, but not a fine art.  Craft means making useful objects with perhaps decorative touches.  Fine art means making things purely for their beauty” – (Richard Stallman).

The first piece of advice they provide is that, as a developer, you need to do your best work in ways that place the interests of your customers over your desire to display skill.  This is an act of balance because the things built by software developers must be useful but they may or may not be beautiful.  Creating something that is beautiful but useless is not being a craftsman; because a craftsman always values utility above all else. The general rule of thumb in software development, according to Oshineye and Hoover, is to sacrifice beauty in exchange for utility whenever necessary (which is often).  Your focus should always be to deliver value to the customer, first and foremost.

The second piece of advice they provide is that, as a developer who considers themself a craftsman, you should produce quality work regardless of your personal interests/feelings.  This ensures that the customer is being delivered a piece of software that provides immediate value to them.  This is the part of the pattern that I most agreed with because this is already the kind of work ethic that I bring into both my school and work-life.

Utilizing this pattern means to find the balance between your customer’s desire for an immediate solution and your standards as a software craftsmen.  As a craftsman, you should have an understanding that utility and beauty are not opposed and that it is crucial to hold onto the balance with your customer, even in stressful situations.  If a stressful situation causes you to make a mistake, you are also responsible for knowing how to refactor and repair – often times from the ground up.  Oshineye and Hoover provide another useful quote to conclude the pattern: “it is by fixing things that we often get to understand how they work” – (Sennet).  I found this pattern to be quite useful and, from this point forward, I will carry this concept of balance with me as I move forward 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.

Share What You Learn

We’re currently in the stage in our capstone where teams are beginning to implement code for the AMPATH project. I’ve been noticing that all of the teams having been making a lot of interesting discoveries in the process. I think I’ve done a good job communicating what I’ve learned with my team so far. But at the same time, I believe communication with all teams as a whole is equally as important.

The “Share What You Learn” apprenticeship pattern concerns primarily what its name suggests. It is asserted that when we learn or discover something new, it ought to be shared with anyone who might benefit from that information. This can be done in a variety of ways. Examples include sharing resources on blogs, relative community platforms, and/or during face-to-face discussions. I feel this is important because even if one person has struggled with something seemingly trivial, chances are there are many others having the same exact problem. For example, a couple of weeks ago, others mentioned that deleting the package-lock.json file (while in WebStorm) before running npm install allowed a successful build of the AMPATH project with no errors. Sharing this information was especially useful to myself, my team, and any of us who had to previously make several manual code edits just to get the app to run.

Lately I feel that as a class, we have been improving in our cross-team communication. We’ve been having more cross-team discussions and sharing of resources, both in-class and on Slack. This is very important; we may be working on different tasks, but ultimately we’re all contributing to the same project. It is certain that we’ll face many of the same obstacles. Thus I believe it is important that we continue to share what we learn. Doing so is a great application of the “Share What You Learn” pattern.

Personally, I’ve been trying to apply this pattern to the best of my ability. For instance, I’ve shared everything I’ve learned about my understanding of the AMPATH app’s processes and procedures. I’ve done this in previous blogs, during class, and on Slack as well. My hope is that sharing what I’ve learned can help others – whether they’re in my capstone course, or someone on the other side of the world searching for information on something even remotely similar.

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

Adding Content to the Skeleton, an Adapted Scrum Methodology

This week marks the beginning of adding real content to the skeleton site that I have been developing for Massachusetts HOSA. The content was provided to me in the form of a word document, with titles to differentiate between pages and sections. The first thing I did upon receiving this document was break the document down into individual user stories. I then created a Trello card for each story and placed the cards on the product backlog list. During this process, I was reading and building an understanding of the product owner’s vision for the website, as well as attempting to come up with potential acceptance criteria. I was also informally coming up with estimates for the amount of time and work that each story would take, but decided not to include these as part of the stories as it would offer minimal return on investment with me as the only developer. I looked at this process as a sort of modified Scrum Story Time meeting.

The next step was Sprint Planning, in which I plucked some of the story items that I saw as most important and placed them on the Sprint Backlog list. During my modified Story Time, I had already, for the most part, broken these stories down into small enough pieces to be worked on as tasks. This was the simplest way to handle breaking down the requirements, and is allowable because I’m the only one that is working on these tasks.

Once I felt that I had taken enough stories from the backlog to keep me busy for a week, I began work. This involved adding content in the form of text and images to existing blank pages on the skeleton website, as well as creating new pages as needed. Some of the story items involved formatting things like the footer and sidebar to achieve the desired effect. Throughout development, various questions arose.

Each time that I encountered something that I needed clarification on, I added a comment to the Trello card. For this reason (and many others), I really like using Trello cards to represent user stories and tasks. Using Trello also allowed me to attach images, checklists, tags, and mentions directed at specific users. I like the idea of keeping all of the relevant information about a specific user story in a single place rather than scattering it across email, in-person meetings, and Trello. I’ve been attempting to document any information passed through other communication channels into Trello so as to have a complete log of interactions.

I’m looking forward to getting into some more specific development on the site. Next week’s post will include a review and retrospective for this sprint.

 

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew 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.

Apprenticeship Patterns – Find Mentors

The pattern Find Mentors in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discussed one of the key tools any apprentice needs to succeed: a mentor. How is one supposed to become a master at their craft if they have no one to model themselves after and no one to turn to for advice? With no mentor there would be no way to go from an apprentice to a master.

In my opinion, finding a mentor is perhaps one of the most important if not the most important thing an apprentice needs in order to succeed. I speak from personal experience when I say this. When I first started my internship some two years ago one of the senior engineers took me under his wing. Now, I was lucky enough that he took the initiative to show to show me the ropes. The amount of knowledge I have gained from working with him is priceless. I am happy to say we still work closely together to this day. It helps that we have a lot of the same likes and interests too. It makes it easier to have a causal conversation and pick his brain a bit because we have so much on common.

Now that I’ve told you my little story, I wanted to mention that the pattern brings up several valid points. First, it is hard to find masters in the field of software development because the field is so new [AP]. Often times you’ll find yourself taking on multiple people experienced in different areas as your mentors [AP]. I certainly have done this. Another thing to note is it may be challenging to get someone to take you under their wing [AP]. Most people with the level of expertise you are looking for are very busy. They may not want to and/or have the time to show you everything [AP]. That being said, the pattern discussed how you must be a bit bold when trying to find a mentor [AP]. This is something I agree with.  The last important point the pattern brings up is that you should return the favor [AP]. If you get to the point where you feel you know enough to pass knowledge on to someone else, even if you aren’t a master, you should take the time to do so [AP]. Remember how appreciative you were when someone shared some insight with you. The person asking for your help will probably be just as appreciative.

 

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

 

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