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.

In this apprenticeship pattern, the authors present a context in which developing software professionals are “spending a lot of time exploring blind alleys.” They then describe the problem by saying that the software apprentice is “walking along a path” but having trouble being prepared for “what’s around the corner.” In other words, they are describing the difficult task all software apprentices face when trying to learn new skills and master their craft. The authors then go on to remind the reader that every software developer who is considered to be a “master” in the field, has walked the same path and knows exactly what that path entails.

For the solution to this problem, the authors suggest that software apprentices “seek out” those that are considered to be masters who are further along on “the long road” and attempt to learn from them. However, this suggestion comes with some warnings. They point out that as an apprentice it may be more difficult to spot the true master craftsman in the field. To counteract this concern, the authors advise that apprentices ” be supervised by a series of mentors who possess varying degrees of mastery.” Additionally, they remind the reader that “no one knows everything” so it is ill-advised for an apprentice to be under the assumption their mentor is infallible in terms of their software development skills and expertise. By upholding this mindset, the apprentice may be able to recognize their mentor’s weaknesses without feeling like they have outgrown their mentor.

The authors also address the issues and concerns that coincide with reaching out to more experienced professionals within the software development field. They recognize that this task may seem extremely intimidating to most apprentices due to fears of rejection or being seen as “strange” by a potential mentor but they assure the reader that these risks are low when compared to the payoff of being mentored by someone who is much further down “the long road.” The authors also provide testimonial from a developer named Dave in which they illustrate these payoffs. Dave reminisces on the time he “uncharacteristically” approached a more experienced software developer named Wyatt at a conference and later went on to exchange emails with him asking to be mentored. Wyatt agreed to become Dave’s mentor and the two went on to meet periodically throughout a year. Dave describes his interactions with Wyatt as “pivotal in (his) progress” in becoming a skilled practitioner of agile development.

After reading this I plan on taking the authors’ advise by “lurking” on message boards and community web pages with the intention of finding potential mentors and valuable information regarding my particular field of study within computer science.

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.

I have to say I did not fully agree with this particular apprenticeship pattern. The authors reiterate their views from the other patters here by explaining that software apprentices should shy away from promotions that involve managing others rather than maintaining positions that heavily involve writing code. The specific context of the problem in this pattern is that you are being offered a promotion that will “pull you away from programming.” The promotion in question is one in which you may receive higher pay but will involve much less technical skills and require less programming.

I understand that the authors are trying to encourage readers to stick with programming in order to enhance their skills and write better code but I think that at some point in one’s career it is important to consider roles that involve management. Part of the reason I say this is because if good programmers never become managers than developers in the field will end up with lousy managers that aren’t understanding when it comes to handling difficulties a team of developers might face. Also, just because you take on a role that involves managing people doesn’t mean you’ll never write code again. For instance, many developers have side projects, such as open source projects, that are unrelated to their work which allows them to continue to hone their craft of software development.

I agree with the authors that developing software professionals should always continue to work on enhancing their skillset but I don’t agree on their anti-promotion/ anti-managerial outlook. Skilled developers occupying the role of manager may prove to be good mentors for those working under them. Furthermore, many projects can benefit from having someone with a strong background in programming making the important decisions. These decisions can range from architecting the project, choosing different tools and/or programming languages to use, and assessing whether applicants are a good fit for the team. If the only people managing teams of developers are those with little experience in programming then the teams could really suffer by not having the right personal with the right expertise and not having all the necessary tools/information they need to be successful.

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.

The Be the Worst design pattern seeks to solve the problem of an apprentice’s learning rate leveling off.  Perhaps this is because they have outgrown their team or organization.  Perhaps this is because they are still working through things alone.  Either way, Hoover and Oshineye have a solution in mind.  They suggest that the apprentice seek out a team where they are the weakest developer, so that as many team interactions as possible can lead to learning, and other team members can help them to avoid pitfalls.  They do note that this is somewhat selfish, and the apprentice should be willing to take on whatever menial work comes up in order to balance their lack of experience or skill.  It also means delaying leadership positions or switching jobs and companies for the sake of craftsmanship.

This pattern really speaks to me.  It’s a position I expect to find myself in this summer as I work as an intern.  I will be the least experienced member of my team, and part of my job is to learn as well as to contribute value.  I expect that I will end up with some of the less-desireable work, but that I will be able to learn from my colleagues and that learning will improve my job prospects in the future.

I also have found Being the Worst member of my team to have contributed best to my learning in the past.  As I’ve changed schools and spent more time in school, that position has been less and less frequent.  I don’t mind leading teams if I feel confident in the subject matter or the technology, but I would prefer to be on the less-experienced end of the spectrum.  This isn’t because I want to dodge responsibility; it’s because that’s where I’ve found I do the most real learning.  It also helps me a lot, both in productiveness and confidence, to know I can rely on more-experienced team members to help if I run into problems.

In the future, I want to find more opportunities to Be the Worst (either in classes next semester as I finish my degree, or at work) at least for a while longer.

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

This weeks second pattern can be considered a bit of a counterpart to the first. The Deep End described going headfirst into a new challenge to get yourself out of a rut and advance your skills. But what happens if you go too far, like the pattern cautioned? What if you bite off more than you can chew?

This is where the pattern, Retreat Into Competence, comes in handy. It is in essence , as the name states, is a retreat from the challenge. If you take a challenge that seems to be impossible or you can not make any headway into, then the wisest course of action might be to simply take a break. Gives yourself a breather, but not just that. You want to not only take a break, but also invigorate yourself and bring back your confidence if you were close to throwing in the towel. So once you retreat, do something you are competent in. Change course for a moment and do something you know you are good at or enjoy. Then once you have realized how good you actually are, dive back into the problem with more energy.

By taking a step back, you can fling yourself back at the problem with much more strength. And by taking a step back and giving yourself some space, that allows you to talk to mentors or others you know that can help you. With advice, tips, and renewed confidence, actually solving the challenge before you becomes much more likely than continuing to bash your head against it over and over again.

Overall, this pattern makes a lot of sense to me. Throughout my life, taking a a respite from something that had me in a frustrated loop of failure, and then coming back, led to me succeeding soon after. This does not just apply to software craftsmanship, it is a pretty universal tip for problems. Retreating can even provide a new perspective that would be impossible to gain with the tunnel vision that usually comes about when focusing on a challenge for a very long time. I have also had times where the retreat becomes me giving up and never coming back too, like the pattern warns. It can definitely be a double edged sword, so take caution.

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.

This weeks first apprenticeship pattern is The Deep End. The main issue this one is trying to solve is essentially getting into a rut. When one is just competently doing their job for a while, they are not preparing themselves for the next step or improving themselves. They are not advancing themselves as a craftsman, but simply doing a competent job and nothing else. As it states pretty succinctly, bland competence eventually decays into mediocrity .

A software craftsman has to improve their skills and their confidence, they need challenges. By not taking challenges, advancing in ones career becomes difficult. This is something I myself have experienced, especially during my college career. This is mostly due to the varied classes taking up both my focus and time, making it difficult to fully devote myself to advancing my software skills. This fed into a bit of a negative feedback loop where I would get down on myself for not working hard enough on challenging myself or being productive enough, which would definitely not encourage me to do more.

As the pattern states, a solution to this is to simply force oneself into a challenge, that requires ones full attention and learning new skills. By forcing an ultimatum, essentially, where one either grows and succeeds or fails, growing becomes much easier. Also, in my opinion, having a new project in and of itself is a very motivating thing. Something new that you might not even know how to begin solving is very exciting. It is akin to a new toy, playing with it can be much more appealing. It is a bit shallow, but it is true. Also, by being challenged, it can rouse the pride of a software craftsman inside that might have slowly faded in the rut.

I agree with the text, it can be dangerous to go head first into a challenge or big change without any help or guidance. While a big, new project can be a change of pace that allows one to break out of a rut, it can also cause them to fail and further entrench them or worse. It is important to throw oneself into the deep end, but make sure there is a lifeguard present.

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.

This sprint was an important one, as we finally began true work on the project. My team and I seemed to have decided to work on the offline storage aspect of the project before even formally deciding it. We all started some preliminary research on PouchDB, the database tool suggested by the Ampath team, before this sprint started.

With this sprint, we began researching and experimenting with PouchDB in earnest. Breaking the larger task up into five individual tasks for all team members proved difficult. Thus we all began doing the same task in our different ways, and planned to meet up and discuss pitfalls and tips we discovered individually.

Unfortunately, due to snow storms and power outages caused by the storms, our next two in person meetings were canceled and communication for some team members was cut off. This meant meeting back up to discuss our experiences and research results did not happen, except a limited one between myself and two other members when we happened to be on campus at the same time. This was very helpful, and I wish we were able to have the two meetings we missed with everyone.

I began by reading through the documentation of PouchDB, learning how it is setup . It’s a NoSQL database that stores documents, that can have as many attributes as one wants. Each document has a unique ID and rev attribute. The unique ID is to give each document a unique identity. The rev attribute is to revise previous documents. The previous documents are not deleted from the database, but the new revised document is simply added to the database.

I began delving into PouchDB by doing the basic tutorial on PouchDB’s website, a basic Javascript project. I looked through the code to see the basic commands, such as creating a PouchDB database, adding documents to it, and getting documents from the database. After this I created a new angular project to play around with PouchDB in Angular. This led me to an unexpected error in creating a new Angular project using the Webworks IDE. I learned after some looking this is due to a change in Angular CLI 1.7.0 that makes creating a new project through Webworks and other JetBrains IDE’s impossible. The issue as explained by a Webworks Product Manager:

https://github.com/angular/angular-cli/issues/9655#issuecomment-370491452

After discovering this I simply made the new project using Angular CLI directly, then opened itin Webworks. I made a new project instead of playing with PouchDB in the ng2-amrs project is due to the amount of dependencies and pre-existing files in the project. I wanted to start with no baggage and play with PouchDB in a clean new environment. Through trial and error, and discussing with my team mates I learned one large mistake I made was following the Javascript and Typescript instructions for installing PouchDB. Due to the basic tutorial I did, I used the method that involves adding a script line in the index.html file of a project, and then used the TypeScript method which installed the @types folders for PouchDB, as Angular uses Typescript files. This led to issues with the import statements in my program. After getting rid of the line in my index.html, the import statements worked as stated in the instructions on the PouchDB website.

After this, using the examples shown on the PouchDB website, I was able to create a database, put in new documents, and got those documents back and logged them on the console in Angular. I read up on several resources to understand how promises work, as the PouchDB API uses promise formats for the commands I stated earlier. They are essentially a truncated try-catch block, that waits for a response before continuing on.

Despite the missed meetings, I feel like we got a good start to the project. We now have a foundation to complete the offline storage aspect of the project. Especially as one of our teammates has pushed their version of the project with PouchDB installed and dependency issues fixed on Github for us to use.

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.