Monthly Archives: June 2018

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.