Author Archives: rdentremont58

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.

Sprint 2 Retrospective

This week’s Sprint was relatively uneventful due to a combination of reasons. First, due to the weather, we had snow days which interrupted our meeting. Second, we had issues communicating with the Ampath people, and we had classes cancelled for a week, so there were no concrete assignments for us to add to the product backlog to create our definition of done to deliver value. Finally, and this is a more personal reason, I caught a stomach bug so I was unfortunately not able to show up to the few classes we met up in.

Even though we weren’t able to produce any solid units of work, we still kept our team on track for our Scrum related tasks such as our stand-ups and kept our overall plan pretty solid. We are still in the process of completing the tour of heroes tutorial for angular, as well as installing and finishing the tutorials for the two testing frameworks Karma and Protractor.

After we began that, we took a look further at the tutorial for Karma, and installed the code into our computers. The Karma tutorial is relatively short, although we are expecting to have to allocate some extra time to researching about the Jasmine framework and syntax that both Karma and Protractor use in their testing commands. One thing we noted while looking through the tutorial is the fact that Karma tends to look similar to junit unit tests, so we are hopeful that Karma will feel somewhat intuitive when designing our unit tests.

The first major decision our group made based on the tutorials was that we are going to go with the tour of heroes for brushing up on our angular skills. We are allocating the most amount of practice time to completing the tour of heroes because we all believe that brushing up on our angular skills will be the primary force behind our whole project, while we can learn the testing frameworks slightly easier, is what we are hopeful for.

In light of the fact that our group was not able to produce any direct value this sprint, I still believe that we will be an efficient team. Even though we had no tasks, a few of our team members kept us on track for due dates of stand-ups, CATME surveys, and blog posts. The rest of us kept on track for preparing for when we had work to do so everyone in our group would be ready to hit the ground running.

So what I learned is that even though we did not contribute anything to the project during this sprint, I do not believe that we need to change anything about how we proceed or group organization or splitting of tasks. I am happy to have learned that team roles are naturally starting to develop due to the personalities of our team members, as one of us is adept at time management and keeping the group on track, while some of us can help out more with technical skills and troubleshooting skills. That is great because we will have less difficulties.

 

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

Craft Over Art

When I read Apprenticeship Patterns, the patterns which tend to stand out to me the most are those patterns which offer a unique perspective and an illustrative focus that is clear and easy to follow. Oftentimes when I am deciding how to proceed with my learning or implementation of code, I get lost in the possibilities, and the guidance the authors provide in this book gives me some much needed clarity.

This apprenticeship pattern is called “craft over art”, because the point of our vocation is to in the end provide a useful product to customers. The value the authors place in this section is on the practical and usable skills that makes up a good developer. The authors illustrate this point well by reasserting and contrasting what it means to be a software craft-person.

At its heart, craftsmanship is making something useful or necessary with an additional style or beneficial features that are added based on the creator’s methods. The authors definitely make this point clear when comparing software development to a craft, and even more so by comparing crafts with the arts. The key difference is that while crafts focus on making a functional product, the fine arts are focused on pure beauty itself.

So what the authors suggest we focus on as apprentices is not the beauty of the product but the functionality of it. Additionally, they describe how often in practice in order to deliver value in time a compromise might need to be made between utility and beauty.

This pattern definitely helped me hone in on which particular skill sets and goals I should be orienting myself around to be successful. Often I worry that I need to be focusing on making the most elegant code or learning the newest fanciest technology, which are definitely good things to aspire for, but in the moment of me beginning my professional journey, it is more important that I pick up practical, concrete skills, and that I focus on delivering the most value and utility. What I gained most from reading this was understanding that bells and whistles will make a product shine, but you famously cannot polish a turd.

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 1 Review

Our very first sprint went successfully by our measurement of done. We had five objectives to accomplish in the week long sprint; creating a trello board for our product and sprint backlogs, creating a github organization for our group, forking and cloning the AMPATH repository, setting up our environments to run the project, and learning about testing frameworks Karma and Protractor.

As it was our first sprint ever, we all learned about setting up and organizing the foundation of a group project, particularly through the lens of Scrum. We familiarized ourselves with the tools and processes Scrum uses that keep our team on track, such as the trello board and standups.

Also, we learned the value of inter-group communication, as our success is in large part due to the help of the entire class when it came to resolving errors. The organization skills and teamwork we have been practicing will definitely set the tone for how we will approach our goals in the future.

The beginning objectives of our sprint were straightforward and we accomplished them in a short amount of time. By the end of the first class we had set up our trello and github groups, forked and cloned the APMATH repository, and prepared to set up our environments to build the project.

That is where we ran into problems. When initiating nodejs to build and run the application, we all had completely different errors from each other. In my case, the first problem I had was building some of the modules. Thankfully,  Professor Wurst was able to help me solve the issue with the node –rebuild command, which drastically reduced the amount of errors I was getting.

Still though I had a few more issues. I knew we were getting close to being able to build the project because every member of our team was getting the exact same error messages. Sam, collaborating with others in different groups, was able to solve the issues by using the combination of ng build –prod and npm start commands. I admit I’m not entirely sure why that solved the problem, and it would be wise for me in the future to take a closer look into what these commands exactly do, will help me avoid errors in the future.

After a few more troubleshooting attempts, everyone in our team was able to build the project on our own computers. I was relieved at this because we were at the end of the sprint, and I was concerned that solving the errors would take all the time we had, and not allow us to learn about the testing frameworks.

Thankfully, Sam was able to help me with my remaining errors, so I had some extra time before the end of the sprint, so I did research and compiled summary notes for testing in Karma and Protractor. That really worked out well for us because we were able to essentially split the job and kill two birds with one stone. If possible I would like to apply this process in the future. While we definitely need to get more hands on and technical about learning the testing frameworks, I am satisfied to say that we realistically accomplished all of our goals in this sprint.

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

The Value of “Toy” Programs

This Apprenticeship pattern “Breakable Toys” highlights the importance of creating an environment to experiment with important software development concepts, while affording us the opportunity to fail at no risk to ourselves.  The philosophy behind this apprenticeship pattern is the best way to gain meaningful experience is to practice and fail and learn from our mistakes.

In the context of software engineering, that means to create “breakable toy” programs that we can use to hone our skill set, while not having the pressure of success in the workplace get in the way of the learning process. We can experiment at our own pace, and practice the concepts that are integral to our careers in an environment where we are entirely in control.

What stands out to me the most about this pattern is the unique solution the authors suggest; create a “toy” program that is meaningful to you that you will use. Sure the goal is to practice the skills that will make us successful in our careers, but the authors suggest that by creating a program that we will actually have fun making will add to the motivation of the creative process.

The authors provide a few examples of people who create their own wikis to learn fundamental concepts of front end development and web design like HTML or REST, or those who make games when they learn different languages to cement the fundamental concepts. The emphasis is on creating a safe environment to test and experiment with different tools while still having fun and fostering creativity.

The main point I took away from this pattern is the importance of creating a safe environment to practice my craft, without having to worry about the scope or the severity of the task, while at the same time being intrinsically motivated to create something of personal value. Real learning and experience isn’t something that can be gotten on the first pass or on the fly; trial by error by far is the best teacher. After all, it would be illogical to expect a musician to perform in front of an audience without rehearsing first.

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

Why Doctors Hate Their Computers

As we all progress through the software development track, learning new skills and how to implement solutions to modern problems, we rarely stop to evaluate how our work or programs we create will affect other people. Yes, we have goals of efficiency, security, and user friendliness which guide us to develop the most useful technologies we can. However, even in following all of our rules to a T, we may create unforeseen consequences on the clients we develop for.

This article Why Doctors Hate Their Computers is a great demonstration of unintended consequences of modern software development as it behaves in the real world, being used on a large-scale. Essentially, the article describes a new electronic medical record software called Epic, whose goal was to create a single interface which doctors, patients, and hospital staff can share information and carry out their work more efficiently. The problem with this software was the scale of which it was being implemented. The upgrade from the old system was just too big with too many factors, and the robustness of the program actually served to make medical professionals jobs even harder and more tedious than before.

While they described Epic’s features and goals, my first impression was that it seemed like an excellent idea. Take all of the doctor’s online work tasks, bring them into a single program where patients and hospital staff can add information; it seemed like a grand unifying software that could easily be an industry standard. However, as I read the author’s experience with the hospital actually implementing the software, I became less convinced.

One aspect of this implementation which shocked me was the hospitals plans to compensate for the reduction in productivity that would accompany any large-scale change. According to the author, his hospital group allocated $1.6 billion on the transition – while the cost of the software itself was around $100 million. The majority of the cost was either being paid out to IT professionals who would install and train staff, or wrote off as lost patient revenues from temporary loss of productivity. This is a tremendous amount of investment to get the systems updated. The problem was with the scale of implementation. A possible solution is having “ambassadors” implement the change and then train the rest of their coworkers would be a better system. At least this way people could ease into the transition and get feedback.

This astronomical cost would be arguably worth it if it really cut down on the complexity of the existing system and resulted in a more efficient experience for the customers and a better workday for the staff. Unfortunately this wasn’t the case. The author’s colleagues experienced frustration, cluttered data, and longer hours at the computer. Significant time and energy that should have been given to the patients were now being spent on learning and/or fixing the system, which defeats the purpose of the upgrading the system in the first place.

Though the developers aren’t necessarily to blame. Without a first hand understanding of the needs and bottlenecks of the medical industry, developers rely on our tried and true model of efficiency, which may unintentionally have the opposite effect if complexity becomes too much. Large scale software updates like this should be taken slowly, where developers work closely with clients to fully understand their needs. When the system is ready to be released, it should be live tested with a few “ambassadors”, who can give constructive feedback and train their coworkers, rather than a company wide transition that can be exorbitantly expensive and time-consuming.

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