Author Archives: rdentremont58

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.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Expand Your Bandwidth

In their chapter dedicated to Perceptual Learning, the authors offer some good advice under the apprenticeship pattern “Expand Your Bandwidth”. This pattern stood out to me because the main focus is on improving the learning process itself, not just skill building exercises.

The situation which the authors describe for us is an analogy which says that we as apprentices spend gain our knowledge by “drinking steadily through a straw”, and the fact that “there are seasons in an apprenticeship when one must drink from the fire hose of information”. This spoke to me because the fire hose metaphor is definitely how I feel. While it is important to take your time and learn the necessary development skills to their fullest extent, there are times in which we as apprentices need to open the flood gates of information and learn new skills and technologies as fast as humanly possible.

The reason why this pattern is called “Expand Your Bandwidth” is because that is the solution the authors provide for applying this pattern. They recommend a number of platforms such as a Google blog aggregator, following organizations on Twitter, as well as joining a technical conference whenever possible. I appreciate this advice, because it definitely makes sense to me to utilize the internet as much as possible as a vehicle for exposing us to as much information as possible, allowing us to accelerate our learning.

One important distinction or warning that the authors provide us budding apprentices is to not only know how to improve our volume and velocity of learning but to also know when to turn that off, and begin drinking from the proverbial straw again. While it is integral to be able to learn a vast amount of information efficiently, it is equally important to know when to slow down and focus more deeply on a smaller volume of data, allowing necessary skill development to accelerate as opposed to a broader learning approach.

This pattern definitely made an impression on me, and I will have to start applying that by taking up the authors advice to join a community or forum. Personally, I think I will begin by learning about contemporary industry related statistics provided by popular software development sites like stack overflow, etc.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective

I am confident that all my group members would agree that this fourth sprint has been by far the most productive sprint to date. We accomplished a lot of work, most notably creating a few different prototype components for our multiple patient list tab structure. We learned more about how to put together our component, as well as began to look at the Ampath specific services so we can adapt our model to their overall system.

The first thing we did was created an empty branch on the main Ampath Github repository which will serve as the connection branch between the master branch and the branch with our code. After we completed the pull request for our empty branch, we were able to use ng generate to create all the necessary files and folders for our tab component.

With all of the setup completed, we were able to start experimenting with angular’s given component materials, and after verifying that we were allowed to use them under the MIT license, we each created a basic model that best fulfilled the design goals of the multiple patient list tab component. While we still are a bit fuzzy on how to implement the tab component for the cards, we definitely have made significant progress in both producing a working model as well as further clarifying the concepts we need to implement.

At the end of the sprint, when we were reviewing the features of our prototype components, we committed our branch with out working model to github, and began to discuss with the team working on mocking the server about what types of data structures and Ampath services we need to use to make communication with the server easier. This is our current task, as we need to figure out how to communicate back and forth, so we can move on to the next step of our design. Once we have a clear understanding of what types of data need to be sent back and forth, we will be very close to creating our minimum viable product.

We as a team and me in particular hit a couple of road blocks which hindered our understanding or progress, but ultimately solving them led us to a deeper understanding of the specific needs of implementing our component. The first hiccup I stumbled on was the decision to use Google’s material design or Angular’s built in materials. After finding out that Google needed a wrapper class and a few extra dependencies, we reached a consensus to use the simpler angular materials. And as I said earlier, we are still hung up on deciding on and implementing Ampath’s services. Finally, we are still not sure exactly what type of data is needed to be displayed on the tabs components for each card.

I am very satisfied about the amount of progress that we achieved during this sprint. We not only have an interactive working model, we all also have a much better understanding of not only how to implement the features we desire, but also a clearer picture of our end-game design goals. The roadblocks we hit were only there because of the amount of progress we completed, which is a good sign to me. After we figure out what our next steps are and implementing them, we should be able to communicate with the server and start our later stages of development.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Find Mentors

While most of the Apprenticeship Patterns  I have read thus far are mainly focused on developing long term skills with an internal locus of control, as many of these patterns’ goal is to change our perspective to be more successful and adaptable to the software development industry. What I like most about this pattern, “find mentors”, is that the authors give good advice for branching out socially into the software development community by finding skilled individuals who can serve as mentors that can use their perspective and experience to catalyze the growth of our skills.

What spoke out most to me about this pattern and the reason I decided to write about it was their quote which seemed to me to encapsulate exactly the meaning of what they were going after; “Your apprenticeship is unlikely to happen in isolation”. While it is ultimately up to us as apprentices to take responsibility for our own development, there is an immense value in finding someone else who is worlds more experienced than you to show you the ropes and use the benefit of their experience to learn the best ways to do certain things or pitfalls to avoid.

The authors give a lot of good advice which I would not have thought about without reading this pattern. First, they highlight not only the importance of finding mentors but also the difficulties associated with finding something. Not only is there the risk that the individual is not interested in mentoring an apprentice, but it can also be difficult to find such a suitable person. The solution the authors provided is to start out by lurking at online forums related to the field and topics that we are going into. After lurking and getting a good sense of the community and their values, then it is good to start discussing on threads with people, and even asking for advice.

What I learned from this pattern is the importance of finding a skilled mentor to catalyze my professional development, as well as concrete strategies for finding people who might be willing to take on an apprentice. While the responsibility is on us as apprentices to gain the skills needed to succeed, finding a mentor is definitely a huge step forward in the journey to master the craft of software development.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

This sprint definitely was more productive than the last one, for the main reason that the scope and implementation of our project is beginning to take shape, and we are gaining more clarity about what we have to do to achieve our goals. At the end of the last sprint, everyone on our team decided that the component that we would be building would be the tab system for adding, modifying, and displaying information about patient records for multiple patients.

Early on in the sprint, Sam found some solid resources that angular provides with multiple variations of tab structures to choose from, and the skeleton codes were provided too. We took a little bit to decide which kind of style, animations, layout and otherwise we wanted to go with, taking into consideration that the everyday users for the project will be medical professionals who have to constantly have multiple tabs open and switching around. We didn’t want our component to feel cumbersome, we definitely value having a sleek easy to read style, and fast animations to streamline their workflow as much as possible. This design goal led us into ruling out certain features that would take a long time for animations or had unnecessary clutter.

After getting a consensus on our group’s design philosophy, seeing what tools angular had to offer us, and deciding on a general schema for our tab component, we discussed in class the need to use Ampath’s included services to make our project compatible with Ampath and useful in an electronic medical records system. Thankfully Andrew found all of that information in their core repository, which saved us a ton of investigative work. So what we have to do now is search through each of the services and their specification mocks to find which ones are relevant to our component and then we can begin creating our prototype.

At this point in our development, we have started to plan for creating a wireframe program which applies both the design we want, as well as the services we need to provide that contains the information and formatting that is relevant to the Ampath vision. Beginning the next sprint we all believe we should be ready to start coding and getting some demonstrable progress under our belts. We will have created a file with our skeleton code and we are hoping to push it to our local repository as soon as we can.

I am very pleased about the progress and mode of work with our group. We all seem to reach a consensus about what direction to go in quickly and effortlessly. We are all finding small ways to help further the progress of our team in our own ways, and at some point during the sprint each member of our group was able to contribute something helpful to all of us. We are all understanding and willing to divide and tackle any particular work tasks we need to get done. I definitely wouldn’t change anything about our group dynamics and I am satisfied that we are successful.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

Sweep the Floor

A good amount of the Apprenticeship Patterns that I see when choosing one to write my blog post about have contexts, situations, and descriptions of people who are confident in their programming abilities, have a defined role on a development team, and are eager to get in the meat of the problem.

However, this context does not describe me very well. I am not confident in my abilities as a programmer yet, I do have an apprenticeship opportunity, but I have no defined role or job title, and I am nervous to tackle important complex tasks because of my inexperience. Thankfully I came across a pattern which describes my situation pretty well.

The “Sweep the Floor” pattern is for people like me who are unsure of the team and vice versa. People who want to contribute to the meaningful work in order to grow their skills and find a defined place on the team, but have only just began their position in the group. This context really spoke to me and pretty much read my mind without my thinking it.

The solution they provide is so remarkably simple that I’m surprised I didn’t think about it before to put my mind at ease. The authors suggest that in order to gain trust and find your place in the team is to in the beginning “volunteer for simple, unglamorous, yet necessary, tasks.” Hence the pattern’s title sweep the floor. If I can’t contribute to the main problem yet, then I can demonstrate my usefulness by handling tasks that are either tedious, not fun, or otherwise that the team does not want to do.

“Typically, you’ll want to focus on the edges of the system where there is less risk, rather than the core where there are usually many dependencies and lots of complexity”. This quote from the authors gave me a lot of clarity about what steps I can take in my internship to make myself known and actually be useful to the company.

However, they do highlight a risk about applying this pattern which I know all too well from other jobs I’ve had in the past; if you constantly are taking the ugly tasks nobody wants to do, there is a risk the group will want to keep you doing the boring, menial tasks. I have had this happen to me to the point where my coworkers would jokingly call me what translates to “Cinderella boy”. To mitigate this risk, the authors suggest to advocate for yourself and look for every opportunity to prove that you can produce quality work on a higher level.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.