Category Archives: Week 9

PATTERN : Sustainable Motivations

Sustainable Motivations

The author opens this apprenticeship pattern by addressing all the intangibles that are often overlooked in the programming world. He talks about the challenges we, as developers encounter in our career. He addresses the issues of horrendous real-world projects that are often rigorous,  tedious and exhausting. It can grow from  frustrating at times to morphing into overly chaotic or constraining issues that are backed by a business man who only knows what the current trend demands. All through this, the author urges us to hold firm and ensure that our drive for mastery propels us to withstand the situation.

Personal Reflection

I was fortunate enough to be taking the CS-348 class so i got to witness the dynamics of a software development environment through one of our in class simulations and there i realized that the constant specification changes by the business man often can lead to stressful and frustration environment to work in but it is here that the author tell us ground our motivations to the walking the long road pattern. In that pattern, we are though to continue taking on task that build and molds our skills. So in the mist of all the chaos, we are expected to find a related source of interest in programming that will continue to carry us when the going gets real tough.

I personally feel like this is the hardest pattern to master because normally, programming is challenging so the only thing that keeps us going at it is our passion for coding/ developing software. Now should that passion be attacked, we have no more source of interest. But the author tells us to persist even when we have lost drive and find a secondary source that can fuel us through the tough time until our original passion returns. I do agree that it does get to a stage that being able to provide for you family comes into the equation so this rules out switching of area or quitting in generally and money often serves as the secondary drive that can propel us until we get our initial vision back. The life of a programmer is filled with many adventures, learning slopes and curveballs but finding joy in programming amidst the bad times deepens the love and passion to be great !.

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.

Pattern : Sweep the Floor

Sweep The Floor 

When reading this pattern, i was a little puzzled the first time but after a second read through i understood what the author was insinuating. No one hands over the most important tasks on a project to a graduate they just hired. That would be putting the future of the company in jeopardy. This is mainly because you do not know how competent a person is without seeing their actual work.

Summary

In this chapter, the author brings to light how apprentices can gain trust of their respective teams and build their way to becoming master craftsmen on the team. By “Sweeping The Floor” newcomers or  new hires are able to build a portfolio performing tasks that the other team members would  not like to do. And when performing these tasks, they are to do it with a sense of urgency and purpose. By ways of such means, you are able to build trust, contribute to the team and also demonstrate your level of competency and understanding of the  team tasks.  We often forget that before we get to celebrate the big victory, having multiple little victories builds ones self confidence and skills that would eventually contribute to the “big wins”. 

The author did mention the value of our college degree once we graduate and i think this is the most surreal thing i read from the entire chapter. Knowing that all the time and effort invested in acquiring my degree only goes to raise expectations on what i could potentially bring to the team but doesn’t solidify me as knowing how to develop a software. with this said, the only way to solidify and earn my teams respect as a  programmer is to create well organized code and programs when i work on the less impacting task i am assigned or i volunteer for. Of course “sweeping the floor” is hard when i have completed my degree in hopes of becoming a full time software developer but the key is that, i would still have an opportunity and by doing a tremendous job on assigned tasks, i will be able to make a case for my skills and earn the respect of my  team members. 

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.

Pattern : The Deep End

Chapter Overview

This chapter was especially exciting to read because it encompassed many of my personal life mottos and philosophies. The author begins by talking about avoiding safe steps but instead to challenge ourself with bigger things. Growing up, my mother always motivated me to do my best and to continue to move forward. she also emphasized on seeing every task as a stepping stone to treasures that would enrich my personal repertoire of experiences and tenacity.  I believe this is what the author was attempting to address in this chapter. In the absence of fear, the sky becomes the limit and everything becomes doable.

Thoughts

 I do agree greatly with most of the authors input on the deep end pattern. I believe that in the absence of growth and challenges, we are often succumbed to mediocracy and complacency.  We need to continue to learn and take-up new opportunities that challenge and cause us to fall out of our comfort zone. The feeling of accomplishment is exponentially amplified when we seek new challenges to conquer and complete each day. The life of a software developer has a starting point but no clear end point as illustrated in the previous post. To continue to remain relevant and up to par with the industry standards, we need to constantly build and elevate our skill so that nothing will take up by surprise.

Although we are advised to seek out projects and task that  challenge us, biting off more than we can chew will only cause us to loose our breath and end up getting it wrong , but to avoid this, we can implement mentorships and find experienced role models who can give us good guidelines and support should our going get tough. Also we need to take educated risks by understanding what will be needed to get the task accomplished. Its one thing to blindly tackle an issue without fully comprehending its ramifications but its also an even bigger issue when you have already jumped into the task but have no source for guidance and support.  “Risks are opportunities seen through the half-shut eyes of fear” as the author said but understanding what we are capable of is an even greater tool for success. 

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.

Walking the Long Road: Craft Over Art

In this Apprenticeship Pattern “Craft Over Art”, it explains the relationship between the craft and the art of a craftsmen’s work. As an apprentice, it is important to understand how much of an impact both aspects have for the work that they produce for their customer. In the software development field, most of the work that you would produce would be for the customer or client that requests the product. With this being said, the customer or client that requests the product will have certain specifications that they want you, the craftsmen, to make, or they could ask for you to make a product that is useful for them.

“Craftsmanship is built upon strong relationships. Focus on delivering value to your customer over advancing your own self-interests. As a craftsman you are primarily building something that serves the needs of others, not indulging in artistic expression. After all, there’s no such thing as a starving craftsman. As our friend Laurent Bossavit put it: ‘For a craftsman to starve is a failure; he’s supposed to earn a living at his craft’. You need to do your best work in ways that place the interests of your customers over your desire to display skill or pad your resume, while still adhering to the minimum standards of competence provided by the software development community. Walking the Long Road means you must balance these conflicting demands. If you starve because you are too much of an artist and your creations are too beautiful to be delivered in the real world, then you have left the craft. If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.”

This idea of deciding craft over art is understandable and this idea stood out to me the most. The software that you make as a software developer must be useful to the customer, otherwise it is a meaningless piece of work.  It is okay to implement the special touches on your work once it has fulfilled its usefulness to the customer and their needs. However, it is not okay to primarily focus on the art aspect over the needs of the customer. You are called craftsmen for a reason, not an artist, and that’s how I view this pattern’s main idea. I completely agree with this pattern’s idea of craft over art and I feel that every software developer should consider the “craft” a priority over the “art” of their work first.

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.

Backing Up

In light of what happened last week, I decided to make coming up with a strategy for backup a priority on the Massachusetts HOSA website. After all of the work that I put into the design the first and second time around, I do not want to risk losing it again. In many regards, I am thankful that losing the data happened when it did. It has allowed me to improve my habits and develop in a more efficient and sustainable way.

The first thing that I made sure to do once I had restored the design of the website was to make an initial back up of the files and database. Although there are more efficient ways (I’ll explore some of these later), I chose what was easiest at the time and copied the files from the web server to my local hard drive through an FTP client. Through an SSH session, I dumped the contents of the database to a .sql file and transferred this file to my local computer, again through FTP. I am now far less paranoid making changes, because I know that I have this backup to fallback on should I mess anything up beyond repair. This backup contains the entire base site, with all design completed per original specifications.

After meeting to discuss the next steps, I will undoubtedly be making more changes to the site. Rather than having to initiate these backups manually each time using the process I described above, I would like to have some way of automatically backing up changes on some sort of a regular schedule. After researching plugins that could accomplish this, I found UpdraftPlus. I wanted to use a plugin rather than something server-side because we will be migrating the WordPress installation to a different server following development. By using a plugin rather than some sort of cron job or script on the server I would eliminate the need to completely reconfigure the backup service after the migration.

After initial setup, I ran a forced backup using the UpdraftPlus plugin. Despite a few files that the tool was unable to backup due to incorrect file permissions, the backup ran smoothly and stored all of the pertinent website data, including a database backup, on my Google Drive account. The only thing that has to be done at this point is to transfer the backup location to someone who will be able to access them if needed following development. I’m very happy to have found a solution to the problem of backing up, and looking forward to not worrying about breaking the website.

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

Breakable Toys

Those describing the Breakable Toys apprenticeship pattern assert the importance of designating a safe-space for failure. But we must accept there is no room for failure on the job. In a professional working environment, many expect us to produce material that works every time. But as depicted in this pattern’s description, failure is necessary in order to grow.

Building breakable toy projects can be a great way to contain, evaluate, and improve upon one’s failure. The idea is to personally design something “on the side” that emulates one or more features you’re working on professionally.

I’ve somewhat already applied this pattern throughout the course of working on the AMPATH project. I’ve developed a few “breakable toys” of my own with the intention of better understanding specific Angular capabilities. My reasoning is as follows: AMPATH uses many Angular functionalities I was previously unfamiliar with. I quickly began to realize I have a whole lot of learning to do.

The concept behind the Breakable Toys pattern seems practical for any Software Developer. In fact, I wouldn’t be surprised if the majority of all programmers have created at least one breakable toy or another. I base this on my personal experience with breakable toys. They have definitely given me a better understanding of the “big picture” behind the AMPATH app. When working on a large project, breaking it down into pieces can give us a better understanding of its overall functionality. We can feel confident evaluating the features in a breakable toy through trial and error. If the toy breaks beyond recognition, its okay. Whereas breakable toys are disposable, large open source projects like AMPATH are not. It seems a lot safer to evaluate functionalities in an isolated space first.

I would also like to mention the specific action suggested by those describing the Breakable Toys pattern. Personally constructing a wiki from scratch is proposed. I feel this will be very beneficial for me in my future endeavors. Building wikis appear to be great breakable toys to experiment with; we can use them to explore fundamentals such as concurrency, HTTP, REST, and general web development. As I begin transitioning to my professional career, these are fundamentals that I certainly need to become more knowledgeable in.

I’ve recently purchased a website domain and hosting space from InMotion. I don’t have anything on it yet, but my eventual goal after I graduate is to build my own “breakable toy” wiki. I want to do this to become more familiar with web development tools and prepare for job interviews. Further, I am hoping to showcase everything I’ve learned about the AMPATH project in this proposed wiki to help others in the future.

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 Pattern: Learn How You Fail

This week, I read the apprenticeship pattern “Learn How You Fail”. To quickly summarize, this pattern asked you to stop looking at your successes and start actively seeking your failures and weaknesses in order to learn from them. I really liked the message behind this pattern because it is different from what we are accustomed to. It is normally very easy to focus on getting better at something you are mediocre at, and even easier to focus on getting better at something you are great at, but it is really difficult to confront your shortcomings and approach what you are terrible at. My interpretation of this pattern was that it doesn’t seek to discredit the good aspects of your skills but rather putting a focus on the bad as to make you a better engineer overall.

This is another applicable pattern for me personally because I still have a few areas of weakness in my development skills, even in some of the technologies and languages that I’ve been using many years. I have caught myself opting out for a simpler but worse performing option because I didn’t want to confront an area of weakness needed to implement the better solution. The other key aspect of this pattern in accurate self assessment, asking yourself “am I really this good at X, or is there major room to improve there”. I often find that we normally give ourselves the benefit of the doubt and say “Yes we are that good”, and this closes out any potential opportunities to actually improve. What this pattern teaches is to really ask and assess deeply and even ask for an external opinion (via peer review) for areas of weakness.

I agree with this pattern and I plan on implementing this going forward in my career. This pattern should be fairly easy to apply because of its practicality. If you are weak in a skill that will no longer needed, the pattern suggests that you shouldn’t waste your time with that and focus on more important areas of weakness. The only challenge to applying this pattern will be the reluctance to do what we are not good at, but I believe that overcoming this will be much easier if we think about the benefit that will come from fixing our weakest links.

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