Study the Classics

Before I became a Computer Science major and aspiring software craftsman, I was very much into reading what many people would consider “the classics”. Whether it was the Iliad and the Odyssey or A Brief History of Time, I have always been fascinated by works of literature that had such significant content or perspectives on the world that they were revered throughout centuries as “the classics”.

So when I came across this pattern, Study the Classics, I immediately resonated with the context they put forth and their motivation for including it in their book. The solution / action which they suggest to us budding apprentices is to collaborate with others and ask about a concept unfamiliar to us and to try and seek out the book which that concept was written about.

Immediately my mind drifted back to learning the Gang of Four’s software design pattern book, which I know for a fact to be highly revered and considered one of the “classic texts” in our craft. Even when I first read it for school assignments, I was enamored by how rich the concepts were and how articulately they were explained. My learning and overall understanding of software development as a whole is unquestionably markedly better than it ever would have been had I not been exposed to this book.

At the same time, I am aware that as good as this book is, and as valuable and timeless as the information in it is, it is definitely not a holy bible for software developers. There can not exist one text to rule them all, because there is no single entity capable of compiling everything we would possibly want or need to know into a single source. So in the future I will definitely seek out multiple individuals or groups of authors who are very well known and revered in our field, so I can add their works to the collection of books I need to read to be as knowledgeable and as prepared as possible for the uncertain road that lies ahead of me in my journey to competence in software development.

Sprint 6 Retrospective

After what feels to me as almost an eternity and an extremely short time all rolled up into one, we finally reached the end of our final sprint and are ready for our demonstration of our component and by extension work thus far. For me personally, this sprint was pretty chaotic, not because of the work itself but because of my personal situation. However, I have managed to overcome the adversity of my personal situation and am fully prepared to pull my weight at our final presentation. I am also confident with the plan of attack we formulated in the beginning of the sprint, and I have the utmost confidence in my team members as well. Even given my personal setbacks this last week, I would not proceed much differently as far as planning and preparation.

The first thing we did in the beginning of our sixth sprint was to begin preparations for our final presentation to the entire class. It took almost no time at all for Sam and I to decide on an approximate layout for how we are going to present our semesters’ worth of work, struggles, and achievements. Sam was adept at further refining our general topics until we were able to make rough estimations of how much time we should discuss all the topics we decided on.

After we had our foundation for the concepts we are going to cover, we had a full group discussion about who should and / or would prefer to discuss which sections. We divided the work among ourselves almost effortlessly, and then we began the process of fleshing out our skeleton presentation and decided which topics needed to be discussed with more attention to detail and time dedicated, and which topics we would not need the full standard allotted amount of time according to our original timetable. We did hit a bit of a snag trying to fill the criteria that every person in the group should discuss an even level of technical detail. This minor setback was just a consequence of the nature of presenting; somebody has to do the introduction and the wrap up. On top of that, we definitely didn’t want one person stuck with all the hard parts to discuss. Thankfully, we fleshed out a solid means of distributing the complicated parts of our project evenly among us. This part of the sprint I feel confidently that our group excelled at, as the plan came from a basic concept to an actual solid foundation in little time, expending little energy, and having no disagreements.

This point of the sprint however was when I became once more acquainted with Murphy’s law. Between having car troubles and blowing out a tire (twice in a 24 hour period), and having more personal issues to attend to with my family, I was not able to physically attend a few of our sessions. I made sure to let the group know about my absences, and they were of course very supportive. The silver lining was that we were done with the software developing at that point, so at least I could practice on my own and not leave any slack behind me.

Regardless of any personal or vehicular setbacks of mine this sprint, the work we did to prepare our presentation was spot on and efficient. I would definitely plan all future presentations in this way if possible, and I am excited to see tomorrow once and for all how our semester’s worth of planning, struggling, and ultimately our achievements have worked out.

Learn How You Fail

One of the many proverbs which I was raised on that I think about to this day when I am trying (and often struggling) to learn something new and master it, is “practice doesn’t make perfect; perfect practice makes perfect”. And while perfection is an impossible goal to set for oneself, the idea that it is important to analyze how you are practicing is instrumental in developing your skills.

This apprenticeship pattern “Learn How You Fail” speaks volumes to this idea. The main idea the authors are trying to impart is to not only accept that perfection is an impractical goal to strive towards, but to analyze and remember the qualities or areas that make you fail. By applying the practice of becoming aware of what you don’t know that you don’t know, my perspective and ultimate success will be much better for it.

Specifically, the authors make it a point to demonstrate this practice by suggesting to create an implementation of a common problem, in this case binary search, in a simple text editor. Once the problem is implemented we are to design tests and iterate the code until we believe it is perfect and only then can we compile and run the tests. The focus of this exercise is to illustrate that even when we think something is complete or as perfect as possible, there will be gaps in our knowledge that we are not aware of, and applying this practice will make you more familiar with the holes in our understanding, allowing us to get a better view of ourselves and our limitations, with the goal of overcoming them.

This apprenticeship pattern definitely spoke to me, because I am very interested with not only the concrete skills in software development, but also the process of learning and finding new ways to learn more efficiently. One quote from this section of the book which stuck with me because of its blunt honesty was “someone who has never failed at anything has either avoided pushing the boundaries of their abilities or has learned to overlook their own mistakes”. I will definitely be taking this lesson to heart and do my best to get as accurate of a self-assessment as possible, so I can practice honing my skills as perfectly as possible.

Sprint 5 Retrospective

This sprint posed a few challenges which I am not confident we will be able to solve by the end of the semester. While I am and I am willing to bet my team members would agree with me that we all have made good progress through the semester, however two major snags hit our project that will be difficult to solve given the time we had left.

At the beginning of the sprint, we were collaborating with the team who was working on the server, and they hit a significant issue when we found out that they weren’t able to make calls to the main server. For some reason, when they tried to access the server URL’s, they weren’t getting any data back from the server, but just a never ending stream of URL text return values. Without an ability to connect to their server, we won’t be able to integrate our component with the rest of the class.

While this snag would not directly impede our group in the progress of developing our component, we also hit another wall which I don’t have the faintest idea about the cause. When myself and my other teammates have our project forked onto our computers, and we run the application, we see exactly the component the way that we made it. However, when we tried to have a different team clone our component and run it, the output they saw was completely different. At the moment, I am not sure if that is an issue with dependencies on our end, or if the other team had a problem with forking our repository. This hindrance is by far the more significant problem because it affects the integrity of our component.

By the end of the sprint, our team decided that the best course of action was to improve as best as we can the usability errors, and to create a minimum viable product which we can use for our presentation. Given the multiple unexpected set backs, I will be happy creating a prototype component that is clear enough to understand so that we can pass it off to future students working on our component who will be able to focus solely on the integration with other teams’ components.

Although this sprint was definitely an exercise in patience and a refresher course in Murphy’s law, we definitely are continuing our march of progress regardless. As far as our component goes, we only have to throw on a few more bells and whistles to have a product which I can say for myself and with some degree of confidence for the rest of my team that we are happy with. I definitely expect set backs like this to be a common part of the job description. After all, nothing happens in a vacuum, and for every perfect plan there is a perfect failure.

At this point we are preparing for our final sprint, and getting ready for our final presentation. I’m sure that during our next sprint planning meeting tomorrow we will be beginning the process of wrapping up.

Retreat Into Competence

One thing that was brought to my attention when going through the computer science / software development major, was that many of us suffer from what I was told was “impostor syndrome”; the persistent feeling that I do not know anywhere near enough, and that fear that your are a hack or a fake. While this persistent fear is definitely a symptom of inexperience, it nevertheless is a challenge to gaining confidence in our abilities.

Thankfully the authors of Apprenticeship Patterns have developed a pattern for dealing with this fear in the real world. Their advice is when you feel overwhelmed by the volume of information you don’t understand yet, you should temporarily “retreat into competence”. By taking a short time to work on some problem which you do know well, you can reset your perspective and freshen your resolve to tackle the new challenges, bounding back like “a rock in a catapult”, using the backwards momentum to launch yourself even further than you would have gone originally.

While this is definitely a helpful strategy for compartmentalizing our learning experience, too much reliance on this pattern will result in mediocrity, as you would hardly make any meaningful progress and your skill as a craftsman will stagnate. The authors acknowledge this, and definitely warn against it, suggesting that retreating into competence should only be done with set time restrictions before we move forward again. Time boxing in this way will ensure we can regain our confidence and composure while at the same time making sure that we are always driving forward.

I definitely appreciate this pattern though and will definitely be applying it in the future to keep myself on track. It is remarkably helpful to be able to, as the authors put it “overcome the fear of your own incompetence”. By taking one step back and two steps forward, we can continue the march of progress at a more comfortable pace, and hopefully alleviate some of the fears and overwhelming feeling when facing the vastly expanding world of software development. This is definitely a pattern I have subconsciously been applying previously, but I will definitely make a more conscious effort to use it and time box myself properly to ensure stable progress.