Category Archives: Week 6

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.

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.

Find Mentors

Problem

You’re walking along a path with no idea of what’s around the next corner or how to prepare for it. You need help and guidance.

The solution the book offers is to seek out those who have gone ahead of you and strive to learn from them. Since our field is fairly young, it can be difficult to find someone who is truly a master craftsman. More than likely you will get support from a series a mentors with varying degrees of mastery. Help can come in many forms, you can get help one-to-one with someone or remotely via the internet. While an apprentice is trying to find mentors, we must remember we are all walking “The Long Road” and no one knows everything. More problems you might have is finding a mentor who in interested in mentoring or who isn’t intimidated by the task of being responsible for another persons learning. It may seem risky to ask someone for help and fear rejection but the payoff is worth it if your offer is accepted. Just as people will be ahead of you, there will also be people who are behind you. You are also tasked with finding those who you may offer to help with information you’ve learned. Passing along what you’ve learned in one of the ways you can being the transition into journeymen status.

I think it’s super important to find someone or a group of people to ask to pass on what they know about the current state of our field. I think work is a great place to meet people that can offer you their skills and knowledge, especially because you will be building relationships with these people and seeing them every day. The text advises picking a tool, library, or community that has an active mailing list and learning the values of the community. Learn who the teachers are and seek out those who may be interested in offering help, I would consider this a great idea. I think sharing what we’ve learned if very important, it helps everybody, it helps the world. I would be super grateful for anybody who’s willing to take the time to share what they’ve learned and I know some people enjoy sharing their knowledge and would be flattered if someone asked for their help.

The post Find Mentors 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.