“The two most important days in your life are the day you are born and the day you find out why.”
― Mark Twain
A quote from Mark Twain.
“The two most important days in your life are the day you are born and the day you find out why.”
― Mark Twain
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.
The test-application that I made demonstrated bcryptjs’s usefullness in encrypting passwords, but my teammates were curious how the library would handle encrypting other kinds of data that we may experience within the Ampath application. We came to the realization that bcryptjs is useful and easy-to-use for password encryption, but lacks functionality for encrypting other kinds of data. We decided that this would be problematic, effectively eliminating it from our choices. We communicated well and discussed our remaining options with a sense of direction we hadn’t had in the previous sprints. After further research, we came to the agreement that we would run with the encryption library crypto-js. We began looking at resources for crypto-js and wanted to begin testing some implementation. We also discussed potential strategies for dividing the work that we must do among our team members. We do not have a solid plan in place right now, because we were unsure if it would even be necessary to divid the task among all member of the team. During our next sprint-planning meeting, we intend to talk more about the division of labor and how we intend to move forward with implementation and avoiding compilation issues. Unfortunately, when me, Erik, and Oren tried to run our application on the last day of the sprint, we all had the same compilation errors, despite having not changed any code since the week we worked on it. We spent the remaining day of the sprint troubleshooting this issue, to no avail. Shane and Caleb, members of the ‘Everyone Else’ team, recommended that we try running the command ‘npm rebuild’ in the WebStorm terminal, which is what he and his team members did when they encountered this issue. I have not tried this solution out yet, but I intend to in the next sprint.
I feel that we made some real progress this week. We were able to successfully agree upon the best-fit library for our task, and we began troubleshooting errors so that we can get back on track to implementing offline-encryption. I feel much more comfortable with our strategy than I have been feeling in the previous weeks, and I feel very motivated moving forward.
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.
This week, I will be writing a reflection on the “Stay in the Trenches” pattern. This pattern addresses developers who have been offered a promotion to a non-programming position. I chose to reflect on this pattern because it is a scenario that I have actually seen other people face in the real world and that I believe I may face some day. At this point in my career as an apprentice software developer, I am still very passionate about coding but I wonder if I will ever consider taking a position that pulls me away from it.
The advice provided by Oshineye and Hoover is helpful and aligns perfectly with my views toward my field. They refer to 2 of their other patterns in saying that a promotion of this kind will test whether a person is willing to walk The Long Road and/or has Sustainable Motivations – the passion that I feel about programming, now, leads me to believe that I am a person that is willing to walk The Long Road and does have Sustainable Motivations. They warn that taking a promotion is not necessarily a step down the right path, and that mastery fades when skills are not practiced. Because I am an apprentice still on my way to becoming a journeyman, I need to practice programming as much as I can and not consider any other course of action. Oshineye and Hoover’s advice to those who experience this problem is to negotiate with employers to find other ways of being rewarded.
By staying “in the trenches” and having the desire to continue working on implementation is a direct way to “Nurture Your Passion”, which is another pattern I have written a reflective blog post about and feel aligns very well with my way of thinking. After reading about this pattern, I think I am somebody who does wish to stay in the trenches and nurture my passion, rather than take a promotion just for increased compensation. I found this pattern pertinent and useful and I will carry it with me as I move forward as a developer.