Pattern : The Long Road

Chapter 3. Walking the Long Road

In this chapter, Adewale Oshineye and Dave Hoover bring light to the life long journey of becoming a master in programming. One cannot expect to become a great programmer after a specific number of years because the concept of mastery in it self is subjective in programing. Its subjective because the better you get, the more you begin to understand how much you actually don’t know.

The author begins by acknowledging the fact that being exceptional in your group just means you need to find new competing and other sources of motivation because like everything in life, there is always someone who will be better at it than you. I agree with the author when it comes to the longitivtiy of programing. I have always known and understood that there will never be a time where i didn’t have anything else to learn in programing, in-fact after taking the software testing class, i realized that far beyond great programing skills is a whole plethora of development that deals with software testing and designing softwares that can be properly tested. The concept of mastery in programing should be facetiously understood as a hoax because no such thing exists. Everyday new technology emerges and with each new technology comes new knowledge and techniques that needs to be learned and implemented. So you can be a very familiar with something today but tomorrows technology will bounce you down from you mastery pedestal. The key to staying relevant is to dedicate yourself to a lifetime of learning and with each step, grow a more yearning character that is always ready to receive and learn new things.

Finally, there was a section in the reading that i don’t think i fully agreed with. It talked about passing up new opportunities to move up into management and elaborated on staying in your path to maximize growth but i disagree with this. There is a saying that goes like “in the land of the blind, the one eyed man is the king”. I don’t understand how it makes sense for a dedicated apprentice programmer to pass up an opportunity to oversee and mentor other programmers just so someone else who is trying to exit the programing world ,take the position to criticize and give instructions on how code should be written. 

 

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.

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.

Breakable Toys

Problem

You work in an environment that does not allow for failure. Yet failure is often the best way to learn anything. Only by attempting to do bold things, failing, learning from that failure, and trying again do we grow into the kind of people who can succeed when faced with difficult problems.

Solution

The solution the text offers is to build “toy systems that are similar in toolset, but not in scope to the systems you build at work.” Experience is build upon failure and success, having a more or less private space to seek out failures in order to learn from them. When implementing this pattern, the text suggests making your systems relevant and useful to your life as an apprentice. Suggestions include building a wiki, calendar, or address book.

“Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects.”

The projects you take on may be excessive and not complete but having the ability to fail, and find solutions trial and error will benefit you in the long run. Maintaining a wiki leads you to learn about things like HTTP, REST, parsing, web design, caching, full-text search, databases, concurrency, and possibly data migration. Other forms of breakable toys include games like Tetris and Tic Tac Toe, blogging software, and IRC clients. The intent of Breakable Toys is learning new things and allowing yourself to learn from roadblocks that might occur.

The idea of building a wiki to record what you learn is similar to this blog in that I am tracking my progression as an undergraduate seeking employment and mentors to help become a software craftsman. I’ve been using WordPress for some time and have slowly learned more about PHP, HTML, CSS, and SQL databases. I think the Breakable Toys pattern is an essential part of learning new and complicated projects. I liked the idea of creating other tools that help you in other aspects of life, like making your own calendar or address book. My first angular 2 project could be considered a breakable toy, I didn’t know anything about Angular and very little about Javascript but having the time to sit down and create a workable web app helped me learn about something new and has prepared me more for the Angular project I’m working on now.

The post Breakable Toys 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.

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.

Sprint Retrospective 2

This week’s sprint retrospective we finally figured out what we are doing.  We started to talk about what we wanted to do for the project. Looking at the Trello board there were quite a few options. However, since Eric had some experience with encryption services we decided to work on the encryption for the website. While we were reading the google doc to see what they wanted us to do for this project. We noticed that they wanted to be able go to download a certain patient information before they were to go out onto the field because whenever they were to work on the field the internet would cut off and it would impact their work dramatically. So, we know that since they are taking sensitive information with them outside they have the risk of it getting stolen.  With this information, we wanted to have an encryption that is not just some username password but also a keygen so that way it would last a few weeks or however long the doctor would want the information on the tablet to be accessible on the tablet but after that it would get locked out where you would not be able to access the information at all. We then started to look up what kind of library’s we could use to make this encryption such as crypto-js, forge, bcryptjs, and webcrypto. We sent a message on the slack asking what kind of encryption that they have already used or would like us to use and they are fine with us choosing. We then set up on our Trello board what each and everyone has to research and write a sample project with the assigned library. Moving forward we just want to be able to work on our communication with each other and how we would be able to share the information that we have with not just each other but also with the rest of the class. Throughout the week all I have done was read though the code and to see what it does. Reading though the code it looks like they have some kind of implication for security however it looks very basic.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog 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.