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 Daniel Mahoney and used with permission of the author. All other rights reserved by the author.