This week, I will be writing the posting my final reflection on an apprenticeship pattern – the Rubbing Elbows pattern.  This pattern addresses developers who feel that they are more productive when they work alone.  The problem that arises for these developers is that they feel that their learning is stagnating because they believe that superior techniques are out there and their work environment causing them them to elude you.  I have had some problems working in groups throughout my college career, but I have never felt that my learning is stagnant.  I chose to write a reflection on this pattern because I think it could be useful in the future, if I ever run into this kind of problem.  Oshineye and Hoover provide solid advice on how to improve your learning in unfavorable environments.

The first piece of advice they give is to find ways to work on tasks with another developer, “side-by-side”.  Oshineye and Hoover believe that some things can only be learned while in the company of other developers.   Even if many techniques don’t require you to collaborate to learn, many ‘microtechniques’ do.  They believe that it is also beneficial to rotate programming partners, because you may find that, after some time, your partner has beome a troublesom one.  Your peers are not the only element conducive to a good working environment though; the physical location is actually important, as well.  According to Richard Sennett’s the Craftsman, an ideal work environment is one in which “absorption into tacit knowledge, unspoken and uncodified in words” takes place.  As many of us are aware, those kind of environments are few and far between, so ‘rubbing elbows’ with another developer is the modern day substitute.  Working with others exposes you to work habits that allow you to gradually refine your skill and extend those habits beyond software development.

The action they advise you to take, if you are somebody currently experiencing this problem, is to find somebody who has already expressed an interest in working collaboratively.  Try to coordinate with that person to meet once a week for a while and see how long you remain motivated.  If the business of your life begins to put a strain on your motivation, adapt and find ways to keep pushing forward until the motivation returns.  I found this pattern very helpful and I will utilize it in my future collaborations.

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

This week, I will be writing a reflection on the “Reading List” pattern.  This pattern addresses developers who are proficient in their first language but feel that the amount of knowledge to be learned about the language is growing at a faster rate than they can acquire it.  I chose this pattern because I have been visiting book stores to shop for software development literature.  While I feel proficient in a language, I have yet to encounter this worry of an expanding knowledge-base that I’ll never fully acquire.  I do, however, plan to begin putting a reading list together as I continue preparing for my internship in the summer.  Regardless, Oshineye and Hoover provide sound advice on how to manage the books you plan to read and how to reflect on your past reading habits.

Their first piece of advice, ofcourse, it to create a list of the books you plan to read.  This is useful in that it allows you to plan out a kind of strategy that will allow you to learn incrementally and notice patterns, trends, and gaps.  As a side note, they also suggest that you make your reading list public to open the possibility of receiving suggestions for future reading while also allowing others to follow the same plan you did.  They recommend that you treat your reading list as a priority queue, as it will help you realize that some of the books on your list might actually not be worth reading.  To initially create your list, choose books that will broadly cover the area that you are studying, and then subsequently drill down on individual topics as you filter out the ones you find most important or interesting.  I found these tips helpful and will likely use them when I head to the bookstore soon.

They conclude the pattern by describing the kind of action you can take to begin implementing this pattern in your own life.  They recommend listing the books you are currently reading in a text file, and then progressively update the list as time goes on.  As long as you maintain the text file, you will be implementing the pattern.  I began my list today, with Clean Code and Apprenticeship Patterns being first and second in the queue.

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

This week, I will be writing a reflection on the “Sweep the Floor” pattern.  This pattern addresses apprentice software developers that are unsure of their place on a new team but want to contribute to the team’s work and earn their trust.  I chose this pattern mainly because the title caught my eye, but also because I think it could come in handy for when I begin my internship, working on a small development team, in June.  Oshineye and Hoover provide solid advice on how to make meaningful contributions to a team by volunteering to perform simple yet necessary tasks.

Some tasks you can complete to promote the early success of the team might be maintaining the build system, setting up the project wiki, updating documentation, code reviews, etc.  They describe these tasks as residing in the “edges” of the project where there is less of a risk of damaging causing damage to it.  The reason that this pattern is called “Sweeping the Floor” is because it refers to the fact that, while sweeping the floor might seem like a mundane and tedious task, it is necessary to the upkeep of any building – and somebody has to do it.  Simple and/or tedious tasks benefit not only the team but also you as an apprentice, because “chores” are often overlooked in academia but doing them fills the gaps in developers’ knowledge.  Oshineye and Hoover raise an interesting point by saying that education means less than college-graduates might think, because everybody starts at square one when they join a new team and, as a developer on square one, taking on mundane tasks is very helpful.

They go on to explain some of the negative consequences that could occur when applying this pattern in the field.  The first negative consequence could be that you might become the team’s “gopher”, the go-to person for mundane tasks, for the duration spent working on the project.  A second negative consequence that could result could be that you no longer feel confident tackling tasks that aren’t like your regular “sweeping the floor” tasks.  There is also the possible negative consequence that you don’t develop an appreciation for the bigger picture while “sweeping the floor” because you aren’t gaining a wider coherence.  Oshineye and Hoover recommend that developers facing any of these negative consequences refer to the “Nurture Your Passion” and “Unleash Your Enthusiasm” patterns.

To implement this pattern, Oshineye and Hoover advise apprentice developers, who are new to a team, to tackle the tasks that everybody else would complain about.  Not only should apprentice developers tackle those tasks, but they should also approach them with creative solutions to exceed their team’s expectations and make the situation fun and rewarding.  I think this pattern will be a useful reference in my repertoire and I hope to implement it in the field, this summer.

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

This week, I will be writing a reflection on the “Practice, Practice, Practice” pattern.  This pattern addresses developers who want to get better at programming and to expand your diversity of concrete skills.  I chose to reflect on this pattern because I recently accepted an offer for a summer internship and I intend to put in quite a bit of practice before I begin working in June.   Oshineye and Hoover provide solid advice on how to exercise programming skills for those in the ideal situation of having a mentor and those who are left to their own devices.

They begin by saying “Take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes”.  I think environment is a very important element in getting the most out of practice.  The environment in which you practice should allow you to focus completely on the skill you are trying to improve.  Ideally, this environment would also include a mentor that can help guide your practicing and gauge your progress.  Personally, I think an ideal environment could also include peers who are also developing their programming skills because it would provide more outlets for each individual to discuss their work and mentor one another.

They go on to say that the key to this pattern is finding time to develop software in a stress-free environment with no due dates production issues, or interruptions.  This pattern, like the “Breakable Toys” pattern, also stresses the importance of short feedback loops in practice sessions.  Short feedback loops refer to the cycle of completing exercises and quickly receiving feedback on your performance for the purpose of gauging a person’s progress toward a goal.  Short feedback loops can be found in the form of feedback from a mentor or in your own incremental completion of progressively more difficult tasks.

To implement this pattern, Oshineye and Hoover advise developers to find exercises or create their own, and ensure that those exercises will challenge them to at least some degree higher than what they know they are capable of.  They also advise that you should solve and resolve the same issue over some period of time, so that you can see how your solutions change and progress.  I have been motivated by this pattern and I intend to implement it in the coming weeks as I prepare for my internship.

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

This week, I will be writing a reflection on the “Dig Deeper” pattern.  This pattern addresses developers who feel that feel that they only possess a superficial knowledge of some of the technologies, tools, and techniques utilized at their workplace.  The problem that arises, in this scenario, is that the developer begins having trouble with maintenance of his or her code because it was written with only superficial knowledge that is likely to be forgotten.  I chose to reflect on this pattern because I really like the advise that Oshineye and Hoover provide about how to truly immerse yourself into the learning process and transform your superficial knowledge to deep knowledge.  I also agree that having a deeper understanding of the everyday things in your life can be incredibly beneficial in a number of ways.

The primary importance of deep knowledge is that allows you to explain the inner workings of systems you work on, which will distinguish you from colleagues that are unable to do so and show others that you are more proficient in working with that system.  I recently had an interview for an internship and many of the questions I was asked were related to my contribution to and understanding of past projects.  The recruiter got back to me a short time after the interview and informed me that I ‘knocked the interview out of the park’ and I was offered the position – I accepted!  Oshineye and Hoover explain that deep knowledge can also act as a safety net in that you can refer back to how you gained your deep understanding in that area to gain confidence about learning something new.

They recommend that developers ‘dig deep’ into the tools and technologies involved in the project they’re working on, until they have a deep understanding of how those tools and technologies work and why they are being used.  One of the ways somebody can dig deep into something is by getting their information from primary sources.  Primary sources understand the problems they were trying to solve.  Another way somebody can dig deep is by looking at tutorials and guides regarding the thing(s) they want to learn, and asking themselves if there are underlying computer science concepts behind what you they are learning.

I think this pattern will prove to be a useful piece of knowledge in my repertoire.  I will try to apply it regularly in my career and I strive to become a person who truly understands the tools and technology utilized in the software I am working on.  I have used this pattern and seen it work, first hand, and I hope it will lead me to more success in the future.

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

This week, I will be writing a reflection on the “Your First Language” pattern.  This pattern addresses those are seeking a job in software development but obtaining said job requires a proficiency in a specific language and/or developers who feel comfortable in one or two languages but are expected to maintain the same standard of quality as their teammates/coworkers.  I chose to reflect on this pattern because I am currently trying to obtain a software development internship and most, if not all, of them require proficiency in at least one or two languages.  I do feel as though I am proficient in Java and C, but I am unsure how my skills compare to those that I might work with in one of the internships I am applying for.  I found this pattern particularly helpful in my current situation.

To deal with this problem, Oshineye and Hoover recommend picking one language and becoming a master of it.  They advise developers to spend a few years solving problems in a single language while honing their abilities.  I found this to be useful because I have had the idea, for the past few years, that employers would look for a diverse skillset in novice developers, but Oshineye and Hoover believe that being a master of one language is more useful than being sufficient in many.

To help improve your experience while learning your first language, Oshineye and Hoover believe that it is incredibly helpful to have an actual problem to solve.  I was at this point last year, which is when I decided to join a website that offers free coding challenges that deal with both real world issues and the type of work you might do in school like programming functions in a specific data structure.  They go on to suggest that, in addition to spending a lot of your own time practicing a language, novice developers should find also experienced mentors to aid in their learning.

Oshineye and Hoover conclude the pattern by describing ways to create short feedback loops and use testing frameworks so that novice software developers can easily track their progress as they learn a language.  This pattern has inspired me to ‘master’ a language, find a mentor, and begin creating feedback loops (such as testing) to track my progress.  I think all of these things will give me a sturdier foundation when I enter the field.

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