Category Archives: Week 6

Apprenticeship Pattern: Confront Your Ignorance

This week I read the apprenticeship pattern “Confront Your Ignorance”, I chose this one because I thought it would be very relevant to me due to the fact that I am in a new role where many things are new to me. This pattern suggests that you do exactly what the name says, come face to face with the things that you do not know. Thus far, I think that this is one of the most valuable pattern mostly because nowadays, since the industry is constantly changing if you are not actively trying to fill in the gaps in your knowledge you WILL fall behind.

To relate this to my own personal work experience, I am currently trying to fill in the Spring gap in my knowledge. I have in a sense been “lucky” for a while since I have been able to avoid any tasks involving those tools, but my team uses Spring so much that my luck will eventually run out. If I do not confront my ignorance when it comes to Spring, then when I am assigned a task involving it I will harm my team. The other great benefit to this pattern is that, if applied, will make you an invaluable member of your team, nowadays there are so many technologies and components to learn that it is almost impossible to know them all so if you are constantly trying to learn more of them, then your value is constantly increasing.

Though this all sounds good on paper, in the real world I don’t think this pattern is applied because it is intimidating. We are comfortable with what we know, and we don’t like being thrown into a situation where everything is new, never-mind doing that intentionally! Also, I think another major hindrance is time, often times you are working on a major project that is taking up nearly all of your time making it difficult to find the time needed to learn something new. A solution that this pattern provides is starting small, you don’t have to do a very deep dive, you can start with an overview and simply learning the basics and that is what is the most promising for me. By learning the basic of Spring in the spare time that I do have, it will massively decrease my ramp-up time when I have to use it. In conclusion this is a very useful pattern that I will 100% try to apply in my software career.

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

Apprenticeship Patterns: The Deep End

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

Pattern 4

 

PATTERN 5: THE WHITE BELT

I think this was a very informational chapter in the pattern lists. This chapter opened my eyes to the realization of my current situation. We are moving on to angular development for our capstone experience and its seems to be taking me longer to understand and grasp the concept. I had been using mostly java for most of my college programming years and have grown accustomed to the ways and norms of how things are done. But with this new angular task I realized that I had to learn and try to understand more things and even though I am a pretty quick at picking up new technology and understanding them, angular was just taking me long. But after reading this pattern, I understand that developing the deep knowledge and tricks in java and getting accustomed to being able to maneuver around in that specific language caused me to slow down my skill picking ability. Since I didn’t have to pick up much but instead implement and use what I had acquired. I believe and agree with the author of the book to some extent. I cannot just forget all I have learned and start from scratch but I can create a new array mentally that is to be filled with new technologies and languages and also try not to bring up what I already know when learning the new materials. But doing this, I will yearn a humble and fertile mind that will be able to grasp and understand anything that will be thrown at it. Also according to the author, unlearning what you have learnt and forcing yourself to believe in your novice status exponentially accelerates the new learning process and makes it easy to develop new insight and possibilities. I believe that its very important for me to understand that I have to give the new technology time and energy to allow my mind to digest it. And after that I will be able to combine it with my prior acquired knowledge, it is at that point that I can call my self a good programmer. Knowing one technology is good but being able to learn multiple and train your mind to utilize what you have learnt makes you a special programmer!

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Use The Source

So we’re finishing up our second sprint regarding the AMPATH project, and honestly I feel like we’re making some progress. Personally, I’ve been concentrating on Angular fundamentals to help me understand the “big picture” a bit more. I realize I need to implement strategies to hold onto and straighten my knowledge of these fundamentals. To accomplish these goals, one of the tasks I’ve been doing is applying the “Use The Source” pattern. For instance, I’ve been meticulously going over the AMPATH project code, trying to familiarize myself with every aspect of the app’s process.

The authors describing a successful application of the Use The Source pattern seem to emphasize the importance of specific procedures, such as:

  • Find an open-source project and analyze its structural pattern.
  • Study every aspect of the project, including the code, layout, methods, and history.
  • Try to think of why the original authors implemented processes in the ways that they did.
  • Seek additional resources giving clarification for procedures that seem unclear.
  • Attempt to refactor either parts or the entire project; perhaps in a personal “breakable toy.”
  • Ask for (and/or offer) feedback whenever necessary, with an emphasis on constructional criticism.

These points seem to outline the primary objectives I should concentrate on when “using the source.” I’ve been trying to follow this outline the best I can.

After attempting to analyze the structural pattern of the AMPATH app, I’ve been realizing that it seems to rely heavily on HTTP processes and routing. Having limited knowledge of these topics, I felt I needed to familiarize myself with these processes going forward.

I’ve asked for feedback from the AMPATH development team, who suggested that I should focus on understanding the processes of REST APIs. This helped direct my attention to several quality Angular video tutorials concerning these topics.

Now that I have a better understanding of the workings of the AMPATH app, I’ve been working on a Angular breakable toy of sorts. The idea is to replicate many of the pivotal functionalities of the project. So far my “breakable toy” has HTTP, REST (Representational State Transfer) and CRUD (Create, Read, Update, Delete) capabilities. My ultimate goal is to make it sort of a “lite” version of the AMPATH app that emulates the basic idea of the program, such as submitting and retrieving medical records. I want to compare my implementation to that of the AMPATH development team. Perhaps this can help me better understand why they implemented certain processes in the fashion they did. 

Following these aforementioned procedures are helping me successfully apply this pattern. I recommend that anyone looking to further their progress in any complex open-source project to “Use The Source.”

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

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.