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.
Our team is currently tasked with creating an offline password-encryption service for the Ampath application. After consulting with the people at Ampath, we made the decision to devote this sprint to creating test-applications that utilize the 3 encryption-libaries we discussed with them. Unfortunately, our meetings were interrupted again this sprint; 2 of our 4 meetings were cancelled due to snow. The days that we did meet, we spent a majority of our time coding and discussing our progress.
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.
Our second sprint mainly consisted of reviewing the source code of the Ampath application. The first of our 4 meetings was uneventful, because only 2 of our 5 members were present. During the other 3 meetings, we worked with one of the other development teams to review the services within the application, reviewed the ReST API, and discussed how we might be able to utilize them in our own work. Our team then accepted the task of implementing offline encryption for the application, and got in contact with some of the people at Ampath to get their input on their preferred encryption libraries.
Our team members collaborated well with one another and the other development team we worked with. We were able to gain more of an understanding of how the Ampath application works, through our reviews, and we were able to begin planning our course of action as we head into the coming sprints. We devoted a majority of this sprint to review and planning, so we have yet to start working on any kind implementation. We hope to begin coding once we have some more structure and concrete direction, in the next sprint.
Toward the end of the sprint, we had some free-time and began working on the offline encryption task and we found 3 suitable libraries that we could use in our implementation. We wanted input from the Ampath people before we chose a library to begin working with, so we sent them the 3 that we selected. In their response, they commented on the fact that the encryption library ‘forge’ seems to be the most popular on GitHub, but stated that we could use whichever one we think would work best. Our team does not have much experience with implementing encryption services, so we decided that it would be a good idea to create a test-application for each of the 3 libraries we selected. We divided the labor of creating these test-applications among 3 of our team members – I chose to take on the task of creating a test-application that implements some kind of offline-encryption using bcryptjs. After the 3 test-applications have been created, we will choose the 1 that has the best balance of effectiveness and ease of implementation. In our correspondence with the people at Ampath, we were also provided the main ReST API calls that are used within the application. This will be extremely useful in the future when we have to begin sending and retrieving medical data in the implementation of the other offline features.
It was, once again, a fairly straight forward sprint. I think that all of the development teams could use a bit more direction right now, but the coming sprints will certainly be more productive now that we are more familiar with our team members and the application itself. I also feel much more comfortable with the Scrum lifecycle, enough so that I have been including it on my resume as I apply for internships, which I think will be quite helpful. I have enjoyed working on this application thus far and I am excited to begin coding.
This week, I will be writing a reflection on the “Nurture Your Passion” pattern. This pattern addresses developers who feel that their work environment is stifling their passion for the craft. I don’t have any personal experience with this problem, but I wanted to reflect on this pattern because I found the advice about how to nurture your passion to be quite useful.
The first bit of advice, provided by Oshineye and Hoover, is to work on things that you like and spend time building Breakable Toys, which I reflected on in the previous post of this series. The second bit of advice they provide is to seek out kindred spirits, or, other people who are also passionate about software development. They recommend seeking out a group that focuses on something you want to learn about, and keeping a blog about things that interest you in the field of software development. The third bit of advice they provide is to immerse yourself in the literature of software development. This tip, in particular, felt relevant and useful to me because I have begun seeking out literature that can help me acquire knowledge and skills that will improve my employability. Oshineye and Hoover make the point that studying the classes and becoming immersed in relevant literature can help reignite your passion for the craft. I still feel very passionate about software development, but I will heed this advice and refer to it in the future if I ever find myself in a rough place. The next piece of advice they provide is to draw your own map, which means to seek out organizations that will offer career paths that you have a passion for. Their final piece of advice is to not be discouraged by demoralizing tasks and coworkers, and to set clear boundaries that define the kind of environment you are willing to work in.
I think that I have been doing a good job of nurturing my passion, so it is a positive reinforcement to find patterns like this one, in the book. I am still passionate about software craftsmanship, and I don’t see it diminishing anytime in the near future. This pattern has further strengthened my foundation and provided me with advice that I will continue to carry with me, as a developer.