Learn How You Fail

Hitting particularly close to home, the Learn How You Fail pattern seeks to instill in inexperienced developers the notion that failure is inevitable and manageable. As written in the Context of the pattern, “Someone who has never failed at anything has either avoided pushing the boundaries of their own abilities or has learned to overlook their own mistakes.” This is a problem that I think must certainly persist in all fields – not just for Computer Scientists. The presence of failure indicates to us that in some way, a person was lacking. That can be a dreadful thing to have to confront, depending on the nature of the failure and the attitude of the person who has failed. Even during the course of this very semester, I and my teammates have experienced numerous failed endeavors that required analysis and discussion to either repair or mitigate.

The suggested method for responding to failure is to actively seek to understand in oneself the patterns, conditions, habits and behaviors that lead to that failure. As that self-awareness is cultivated, it becomes much easier to operate in a way that consciously and productively considers relevant boundaries and limitations. It allows for the choice between either fixing the identified issues or cutting one’s losses; moreover, it vastly improves one’s ability to set realistic limitations on goals.

I think that in this project for Ampath in particular, my group has already been encountering this pattern and applying it in some capacity without realizing it. Each week at our retrospective, we have discussions that touch upon what could have been done better by each person, and we make/uphold plans to address those areas accordingly. This has resulted in each of us finding roles within the group that maximize on our usefulness – we are each focusing on the areas most attuned to our strengths, while minimizing the amount of weakness in those areas. Of course, by virtue of the unfamiliarity with Angular that persists throughout the group, we all have several areas that need refining. However, over time, we have identified which weaknesses are being addressed by which people, and assign ourselves work in accordance with those findings. Indeed, this seems to be a model that will be extremely effective beyond this project.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – 4 April 2018

This sprint was easily our best one yet. We were highly productive, completing a range of tasks concerning design, merging with other teams and test-driven development. Where the previous few sprints have illuminated the pitfalls and obstacles of Agile development to our team, this sprint gave us a feel for what it’s like when Agile development is running like a well-oiled machine.

Not long after the beginning of the sprint, we identified a design dilemma that had us scratching our heads. We noted that if we had the patient data encrypted with an algorithm that made use of the active user’s password (as all groups seemed to agree upon), then we would run into a problem:

Suppose Doctor A is logged into a machine, making use of the offline data module. He does his work, no problems, everything is fine; all patient data is encrypted with respect in some capacity to his password. Suppose, then, that Doctor B comes along and tries logging into the same device. In spite of having provided perfectly valid login credentials, Doctor B will be unable to access the patient data, due to the patient data being encrypted with respect to Doctor A’s password. We spent a few days trying to figure out exactly how to solve this predicament, but our ideas kept coming up unsatisfactorily for a number of reasons.

I take some pride in being the one to figure out the answer, and consider it one of my two major contributions to the team this sprint. It turns out that the way to both satisfy the specification (which lists that the login must feature encryption using the user’s password + a salt) and the dilemma we encountered was a split in what we were storing. Rather than a single offline database, we would have two. One of these would be responsible for storing the patient data – encrypted with its own algorithm, irrespective of the user’s login credentials. The second database, however, would consist of only strings. Specifically, each string would be the result of running the encryption algorithm with respect to the user’s password on their user ID. For login, the method would therefore be:

  1. User enters username/password
  2. Run the encryption service on the username provided, using the password provided
  3. Perform a database lookup for the result in database 2
  4. If there is a match, successful login. If there is not a match, unsuccessful.

This information was spread to the other groups and has been accepted as the plan for all encryption service use moving forward.

In addition to this important design step, my other major contribution this sprint was in writing test cases for the create, addDoc, and getDoc methods. In class, we were able to get tests to pass with the code written by other members of the team, and observed in browser that a PouchDB database had successfully been created, added to and read from.

The biggest takeaway from this sprint was easily that having specific roles in the group is a powerful motivational force. When it was determined that I would fall into the role of test writer, and the other members of the group picked their specific methods to focus on, it was clear that we had each found the direction we needed in order to get the ball rolling. Going forward, I hope we will continue this practice of providing concrete roles for one another, to make the project feel less like a behemoth and more like a set of separate goals to be achieved.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Concrete Skills

Concrete Skills is particularly relevant to those of us coming to the end of our college careers; the problem it talks about is one that is outside of the inexperienced developer’s bubble. Specifically, the pattern is concerned with hiring managers’ inherent level of risk when hiring somebody who may not be able to contribute to the workload of the team due to their lack of ability. Hoover and Oshineye make the point to distinguish between knowledge – the possession of information – and skill – the ability to acquire and implement one’s knowledge in a way that is useful.

The suggestion provided is to acquire a set of skills that are either universally useful, or indicate strongly one’s ability to obtain skill in an unfamiliar technology or environment. Moreover, the recommendation to new developers is to obtain the CVs of people whose skills they respect, and identifying five discrete skills listed on each. This way, one can determine the sorts of skills that are valuable across the industry, and effort can be focused directly into strengthening those skills.

I believe that these are worthwhile and sensible courses of actions. The Software Development is a wide blanket, with countless possibilities for beneficial skill sets across the countless media that demand developers. Personally, as someone who dreams of ending up in game development, I have a vested interest in attaining this kind of proficiency. I do not anticipate my beginnings in the workplace to be in game development, and therefore my focus must include skills that are applicable in as many forms as possible.

Of course, after reading through this pattern, I couldn’t help but read through my own résumé. In concordance, I have identified several skills which align with this pattern of thought, and several which did not. After making my edits to better reflect my universally transferable skills and experience, I feel much more confident reading my résumé. Going forward, I will seek out more ways in which I can obtain the technical, business and interpersonal skills that will make me not only more attractive to hiring managers, but more versatile as a software developer.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

Since I last read about Confronting My Ignorance, I thought that the natural next step (although in all likelihood, it was probably intended to be the previous step) would be to read about the Expose Your Ignorance pattern. I can certainly see where each of these ideas influences the other. Really, Expose Your Ignorance feels like a recommendation for the mindset to be in when applying the Confront Your Ignorance pattern in a public setting. The pattern is concerned with the idea that developers ought not to pretend that they have expertise in an area that they simply are not experts in. Rather, it suggests that developers ought to make their ability to learn viewed as an asset by presenting question to those with experience and applying their teachings effectively.

This doesn’t necessarily apply to the project at hand – I think there’s an understanding from all authoritative figures involved that there’s a general lack of experience among my classmates. This is, after all, the first serious project that many of us have been a part of. In my own experience, however, I have certainly encountered expectant product owners seeking my “expertise” as a software developer. I can recall my experience making a tournament management application for one of the clubs here at the school. I had begun the project for my Software Design, Construction & Architecture course, and reached out to the president of this particular club because I had in interest in the club itself. While this individual was aware that I was a student with particular deadlines and requirements to receive a passing grade, he also happened to vastly overestimate my capabilities at the time. He wanted features that I hadn’t even begun to research the libraries necessary for, while I was already in the middle of fiddling with other libraries I was using for the first time anyways.

Ultimately, it turned out to be a great idea to tell this individual that there were simply some requests he’d made that were beyond the scope of what I was able to do at that point in time. In addition to his understanding, his requests became much more concise and he was clearer about which features were optional. We came to a much clearer understanding of what the baseline he wanted was. And, as far as my end was concerned, I was able to get him a finished version that he was more than satisfied with. I will make conscious note of this pattern for the future. If used in tandem with Confronting My Ignorance, I am sure that there is no dark patch in my knowledge that I won’t be able to shed light upon.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Confront Your Ignorance

As we move forward in this Ampath project, I have found myself dissatisfied with how unimpressive my command of the technology available (or the lack thereof) is turning out to be. As I browsed the list of apprenticeship patterns, “Confront Your Ignorance” leaped out at me the moment I noticed it. If there is a better way that I can directly combat my weakness in Angular, PouchDB and WebStorms, then I would certainly like to know what it is. Confront Your Ignorance, it turns out, is concerned with exactly that.

The problem that Confront Your Ignorance seeks to address is an all-too-common one: When exposed to a new technology, a developer may become uncertain of how to go about learning the ropes. What’s more, it may be that people around them are already well-versed in the basic tasks you seek to perform, and there is a certain expectation that the unlearned developer also has the same knowledge. This can make it even more difficult to orient oneself in a direction that maximizes potential for learning, or learning the technology’s features in an effective order.

The solution provided is to identify a specific tool, skill or technique, and actively fill the gaps in knowledge regarding exactly that. Over time, as more is learned about the particular thing, it can be determined by the developer whether it is worth digging deeper for more in-depth knowledge, or if it would be more productive to direct attention to a different gap in knowledge that needs filling.

While I have not directly encountered an instance of this pattern in practice, I can absolutely identify the need for it in my current project. My group is in the process of learning to use PouchDB, Angular, the Jasmine testing framework, and several other technologies to develop this offline storage service. Up to this point, we have had a considerable degree of indirection, and the utility of Confronting Our Ignorance is obvious to me. In the coming weeks, I will more than likely pick a specific role within the group, and dedicate myself to learning about whichever role I happen to pick. Down the road, I expect to put this into practice whenever learning new languages or environments. Hopefully, if used in conjunction with Expose Your Ignorance (which I intend to read next), this will prove to be a highly effective mechanism for addressing whatever knowledge I lack.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – 14 March 2018

This sprint, unfortunately, was cleaved in twain by Father Winter. There were multiple white-out blizzards, which resulted in numerous missed class meetings. This proved to be a serious blow to productivity. In the face of nature’s obstacles, however, my group did manage to get more done than we would have anticipated had we known how little we would have been able to collaborate.

This sprint, we solidified much more of our understanding of PouchDB and the structure of our service. Due to the weather, much of our progress was done separately except for during a single impromptu meeting on Discord, so a gap in our respective grasps of the service has begun to form. However, in some capacity, each of us managed to learn and share with each other something new about PouchDB. As for me, I was concerned with the code itself. Much of my time in the first few days of the sprint was spent tinkering with the exercises we had completed during the previous sprint, in an effort to attain more than a working knowledge of PouchDB’s functionality. To this end, I redid the exercises from memory as best I could, but also framed the app in the context of Ampath’s patient data. The result was a rudimentary form of what the final service may look like – albeit without encryption, decryption, login, etc.

Of course, catastrophe managed to strike. As it happens, there are two versions of PouchDB: a JavaScript version, and a TypeScript version. We had been writing our code in the former, and wished to switch to the latter. In terms of syntax for the programs we’d written, this wasn’t all that major of a change, as we only really needed to change the import statement at the top of the file. Installation, however, was another issue. I spent hours with Fuve and Caleb one day, fighting with install errors that would pop up for one of us but not the other, until eventually Fuverion made some breakthrough that fixed everything. Admittedly, I still have no idea what he did, I’m just thankful that he did it.

Due to the inconsistent meeting times, coupled with the headaches brought about by switching to the TypeScript version of PouchDB, this was about as much as we were able to get done in this sprint. We have in fact discussed this already in an in-class retrospective, and have all agreed to make better use of our channels of communication: Slack, Discord, and a group text message thread between the five of us. In doing so, we hope that future unforeseen bouts of meteorological calamity will have far less power over our capacity for progress.

In this sprint, a very critical lesson was taught (or, perhaps a better word may be “reinforced”) to all of us: Do not assume that anything will go as planned. Do not assume that anything will be smooth, or easy. Because in the event that some blizzard comes along to remove two consecutive meeting periods, it’s far better to have modes of communication available for use and at the ready. In future sprints, I will work to ensure that my communication with my team is upheld in the times where I am, or any of them is, unable to be present.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – 28 February 2018

With now two full sprints under my belt, I think I’m beginning to grasp not only the aspects of team dynamics with which I have comfort, but also those aspects with which I have discomfort. I am glad to be encountering obstacles and pitfalls in an academic setting rather than in a much higher-stakes workplace environment.

Where last sprint was primarily concerned with setup tasks, this sprint was more geared toward design – be it the design of the user interface, the program structure, or the module as a whole. We determined as a team during our first meeting that we would take responsibility for developing the Offline Data Storage service. Much of the remaining class period was spent looking over user stories, and looking into the suggested service for offline storage: PouchDB. Over the next several meetings, we worked toward three goals in particular. Firstly, we wanted to figure out the best way to transition from the online state of the application to the offline state of the application. To this end, we drew up a few of our ideas, and posted a number of them to Balsamiq. In addition, we sought a better understanding of PouchDB, so many of us spent ample amounts of time doing online exercises from the PouchDB website and making small, basic offline applications for practice. Perhaps least importantly – but certainly still relevant – is that we spent time during each meeting reading through the code that Ampath has already written. We focused on their data storage service that is already in use for their online storage, and are looking to see if we can translate ideas from those sections of code to the ones we develop.

As far as my contributions to the team this week, I would say that the largest part I played was in the dissection of Ampath’s code, and in the assistance with PouchDB growing pains with the exercises. I would have liked to have spent more time working out a foundation of a plan for our service’s implementation. In the sprints to come, I hope to dedicate more resources toward the actual building of the service, so that we can get the ball rolling with the code.

The biggest takeaway I came to from this week is that self-management is a critical skill in the field of software development. Although we are not yet at the stage of writing the actual classes for the project, it is clear that each of us is not used to having a large task with no overseer. While Ampath is technically available via Slack, we haven’t had much success in getting additional information from them, such as a UML diagram for the existing project (which we were told does not exist). As a result, we have had to maintain a degree of discipline on our own without the extrinsically motivational forces we have grown used to. Going forward, I hope to develop a more productive and attentive attitude, and believe that such a change will greatly benefit the project.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm

Immediately following the White Belt pattern in Apprenticeship Patterns is the pattern of Unleashing Your Enthusiasm. As the name states, the idea of this pattern is for a developer to forgo the inhibition of his/her enthusiastic tendencies for fear of his/her own inexperience reflecting poorly on him/her within the group. Put more simply: new and inexperienced developers often bring a much-needed drive and passion to a team, which proves to be a vital element of the team’s success. Moreover, the very nature of high enthusiasm contributes greatly to the developer’s personal learning of the technologies at hand. Hoover and Oshineye point out that during this introductory period, there is a rare opportunity to provide a fresh perspective, which allows one to offer useful suggestions for improvement that may otherwise go overlooked.

One of the first relations I could think of to myself was my Fall 2017 semester, when I was taking Robotics. Our group was a 3-person team where each person had a solid foundation in one area, and inexperience in many of the others. We stagnated for about two weeks after receiving the final project – which was tremendously flexible in what we were allowed to construct – because there was a pervasive discomfort felt among each of us when it came to making a decision of what to actually build. When we ultimately agreed on something, and the fear of asking silly questions dissipated, we became staggeringly productive. In many ways, our enthusiasm for the project was the only reason it got done; most notably the final three days before our presentation, where we had to scrap and redesign the entire machine. If it weren’t for the excitement we felt every time we learned something new about the code we were writing, or thought up a more efficient way to construct the robot, we may not have been able to finish in time.

Overall, I can agree with the message of the Unleash Your Enthusiasm pattern. Even sitting here now, I can recall times where my excitement over a project or idea has been contagious, and I can see how that would be a powerful tool on a development team. After all, one tends to put out much higher quality when working voluntarily rather than compulsorily. Going forward, I will be making a greater effort to present my ideas, questions and concerns to people of greater experience, and hope to make strides in my learning through their responses as a result.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

The White Belt; Alarmingly Appropriate

The White Belt Pattern is a simple concept: the idea is that one who seeks to learn must take on the attitude of a beginner. It is the frame of mind that “while the black belt knows the way, the white belt has no choice but to learn the way.” The pattern dictates that one maintains a stance of unknowing, and actively seeks opportunities to “unlearn” the things that he/she is already familiar with. E.g., if you were to write a program in Java, a white belt pattern course of action might be to redo that program in a functional programming language rather than an object-oriented one.

This pattern struck me on multiple levels. I am a martial artist; I have been training since I was very young, and am quite familiar with the notion of emptying one’s cup. However, though I’ve been used to doing it with martial arts for years, it occurs to me that I have a very hard time doing it with programming. I had this problem when moving from a Kenpo school to a Tae Kwon Do school; I would keep trying to do things the way I’d been taught by my Kenpo instructor, in spite of the fact that I’d set out to learn a new style. I wonder if I’m doing the same thing with code.

There have been times when, in my process of learning a new language, I’ve made statements to the effect of “Oh, X language allows you to implement this in a much more efficient way,” or “This type of code would be much more readable in X language.” This, I think, gets to the crux of the issue that White Belt Pattern seeks to address: Excessive comfort in one language, development environment or paradigm can have the unfortunate effect of shrinking a developer’s capacity for pragmatism with less familiar technologies. Comparing two technologies’ level of practicality without giving oneself the proper time to work with and understand each of them is intellectually dishonest, and can avert someone’s eyes from potential advantages of one or both technologies. Going forward, I will be certain to keep these principles in mind as I seek to understand new technologies, both over the course of the semester and in my professional career.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

Messaging

The last chunk that I wanted to get done before the end of the semester was Messaging. It took me a while to wrap my head around how I was going to do it, and the way that I picked was definitely inefficient but it worked so I was happy.

This would require two tables in the sql server. Messages, which held the username of the person sending the message, the username of the person receiving the message, a timestamp and the actual message. The second table is the Message_Box. This had the to_user and from_user field and an incoming field which held an integer that specified the amount of messages sent by from_user to to_user that to_user hadn’t seen. Every time the message page was loaded the incoming field would be reset to 0 because all the messages from that user would be loaded. The real use of the incoming field is when two users are on their messaging pages and messaging each other. I have a method called StartMessageCheckingTask() that runs every second and checks if the incoming field for that user was higher than 0. If it was it would load the amount of incoming messages from from the bottom of the list of all messages sorted by their timestamp. Unfortunately this means that the sql server is being accessed every second while your on the messaging screen which isn’t the greatest but it was good enough for what I needed at the time.

Now a user could tap on a pin and a box saying “Message” would popup. Clicking on the popup would bring you to a messaging screen where you would be able to message the user who’s pin you had tapped.

From the blog Location App Blog by Anonymous and used with permission of the author. All other rights reserved by the author.