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.
At the end of last sprint, we had finally resolved compilation problems that 3 of our 5 team members were experiencing, and we have Jason Knowles to thank for that. Our team felt a rejuvination of morale at the beginning of this sprint, and we began finally resumed work on implementation of our offline encryption-service. We split up the labor of implementing the service, among our 5 team members. I was made responsible of implementing functionality for ‘salting’. In encryption, a ‘salt’ is piece of random data that is used as an additional input to a hash function. Within the hash function, the salt is concatenated to the password or passphrase to be hashed, which will help defend the encrypted data from rainbow table attacks. I spent our first couple meetings researching salt, and was absent for most of the third meeting because I had to attend a lecture. As I have mentioned in earlier blog posts, our team planned to use the crypto-js encryption library for our offline encryption service – but when I did make it to the third meeting, my team members were having problems importing the crypto-js library into the Ampath application source. I had not experienced this problem yet because I had been doing all my implementation for the service within an npm runkit that had crypto-js integrated. This problem, apparently, ruined productivity for that meeting and the majority of it and the following meeting were spent trying to resolve this issue. Our teammate, Henry, began to have errors within his application toward the end of the sprint, haulting his progress. We were unable to resolve these issues by the end of the sprint.
During the second half of the sprint, I worked on implementation of the salting functionality. We discussed approaches with Matt Foley, of one of the other development teams, and we came up with a plan. Their team is working on an offline login service, and login data is currently the primary focus of our offline encryption. We decided that the salt for login data encryption would be the user’s username and the timestamp of their computer at the time of their login. One meeting was spent merging changes from our group repository with my working repository. Once that was done, I spent the remainder of the sprint writing a mock service for salting functionality. I did my rough work in an npm runkit with crypto-js integrated, because we were not able to figure out how to import crypto-js into the Ampath application. This is a major problem as we do not have any more time to research other encryption libraries. We decided that we will just all write mock implementation for the purposes of our end-of-semester presentation. The implementation for salting functionality seems pretty simple to me it is just incredibly unfortunate that we can not get the library imported into the application. Professor Wurst said that we can still work on implementation if we wish, but we will have to reserve only a small amount of time for it as we have to prepare for our presentation.
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.
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.
At the end of last sprint, 3 of our 5 team members were unable to run the application due to compilation errors. The compilation errors continued into this sprint which made our team unproductive and a bit disheartened. I think low-morale in the team caused a bit of a stand-still and some of our meetings were short-handed with regard to present team members. Members of the ‘Everyone Else’ team gave us some advice on how to get our application running again, but it did not work. As a last-ditch effort, we contacted somebody at Ampath to ask how they might resolve the errors we were experiencing. They did not respond for several days. During those several days, we happened upon a solution while discussing implementation with another team, and we concluded this sprint by successfully compiling the application.
The few meetings we had with team-members present comprised of planning our strategy for implementation (for when our team members are back on board) and creating an API for our offline-encryption service while we worked on finding a solution to our compilation errors. We figured that, with only one sprint remaining, we will only be able to create an offline-encryption service for encrypting login and patient information. We wrote a mock-service that utilized the crypto-js encryption library to encrypt login and patient information, and then used that mock-service to write an API for our planned implementation. Once we finished the API, we sent it to somebody at Ampath for approval, and they approved it.
We then went back to addressing compilation issues. Like many of the other developers working on this application, I have had compilation errors previously, and figured that I would be able to use one of the fixes that I had already found. However, none of the fixes that I had used previously were working to get my application compiled and running again. Me and the other team members experiencing this problem convened with members of ‘Everyone Else’ and they advised us to run the command ‘npm rebuild’ to potentially fix the compilation erros, but this did not work. We contacted somebody at Ampath for advice about how they would resolve the kinds of compilation errors we were experiencing, but they did not respond by the end of the sprint. While we were waiting for a response, we happened upon a solution while discussing implementation strategies with another team. Matt Foley pointed us to some installation and compilation instructions that he was presented by somebody at Ampath. This solution worked for the present team members, and we shared it with the our absent team members so that they could also get the application running. As the sprint wrapped up, we were all able to successfully compile and run the application and, now that we have all members up to speed and an API approved by the people at Ampath, we should be able to fully resume work on implementation and we hope to have some deliverables worth presenting at the end of the semester.
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.
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.