The Beginnings of my Map

I’m typically not much of a long-term planner. While I have defined some goals and aspirations, they sometimes seem more like rambling dreams than achievable objectives. Although I may know what I want, defining actionable items for getting there is a different and far more challenging accomplishment. I like to make the most of every day, doing the best that I can and hoping that hard work and positivity will take me somewhere amazing, wherever that may be.

Much like the story told by Desi in the Draw Your Own Map pattern in Hoover and Oshineye’s Apprenticeship Patterns, I have begun my Information Technology career in a sort of hybrid role in Systems/Application Administration. The differences between my experiences so far, thankfully, have been far different from those described by Desi. Rather than facing pressure to concentrate only on furthering the interests of others, I am encouraged to create a valuable experience for myself.

While I am well aware that it is not the responsibility of anyone else, employer, professor, or colleague, to give me a hand out, I am extremely grateful for all of the support that I have received in that regard. I feel as though I have a good sense of my career position  and potential options for the future because of the support that I’ve received and the experiences that I’ve had.

Although I see absolutely no need to consider other paths at this time, the Draw Your Own Map and the stories shared by Desi and Chris were somewhat reassuring. It is comforting to know that even if there comes a time when it may feel like it, you are never really stuck. I feel extremely grateful to currently be in a position where my goals and desires for professional advancement are not only heard and considered, but seem to be top priorities. I am in a supportive, flexible environment, where I’m encouraged to set and work to achieve goals for personal and professional growth, development, and learning. Right now, the possibilities and prospects seem to be wide open. The next step for me is to use this opportunity to discover the values that are important to me.

Looking Back on Sprint 3

During the third sprint, we began digging into the code of the ng2-amrs application and really started to attempt to gain an understanding of the existing implementation. There were quite a few hurdles throughout this sprint, including the cancellation of both the second in-class work day and the in-class review and retrospective day. This made communicating ideas between team members significantly more difficult, and I think this has also impacted our performance for this sprint. I still believe that we are working well as a team, and doing the best that we can given the circumstances. Standup participation was 100% for this sprint, which (I believe) is a first for the team.

For sprint planning this time around, we chose the “Offline Login Service” story from the product backlog, as this most closely aligned with what we had begun researching during the second sprint. We broke this story up into tasks, some of which were assigned to everyone on the team, and some of which were assigned to individual members.

One of these tasks, assigned to Dominique, was the “Collaborate with ‘Field Idiots’ to determine how to decrypt and encrypt user data/passwords” task. I am interested in learning more about what Dominique discovered about the encryption implementation that the Field Idiots team will be using, but am unsure if she was able to do much collaboration because of the cancellations.

The “Collaborate with ‘Everyone Else’ about API for retrieving offline data/user information” task was assigned to Luigi and Matt. Once again, I am unsure whether or not they were able to achieve much collaboration due to the cancellations. This collaboration is critical to our progress moving forward, as we must be aware of the requests that we should be sending to the local storage databases in order to implement an offline login.

The “Investigate session management” task was assigned to myself. The main discovery that I made while investigating how the ng2-amrs application handles sessions is that we may not need to change much about the session itself. If the existing code for session management can be modified for usage offline, this would be a far more effective solution than rewriting an entire session manager ourselves.

The remaining tasks were assigned to all of the team members, and were more for big-picture existing implementation understanding and design strategy. The first task was to “Investigate current logon process,” something that we started as a group on the first in-class work day. While we made some progress, I was hoping to use the second in-class work day to share what I had discovered independently and also hear what others had discovered.

The design-strategy task that we created based on the advice of Dr. Wurst was to “Look into ‘Bridge’ design pattern”. I remember looking at the pattern briefly last semester, but needed to refresh myself. I found some online resources that seemed to give a good overview of the pattern and shared them with the rest of the team in our Slack channel.

The final task shared by all team members was the “Create overall architecture/design of offline login feature using Balsamiq.” This task was started during our first in-class work day by Matthew. The design that he created gives a good high-level picture of what our service should accomplish. While I was hoping to discuss possible additions to our design with the rest of the team, this was impacted by the cancellation of class last Thursday.

While there were certainly some hurdles to overcome during the third sprint, I think that we did a good job of making the best of the situation. We communicated more through Slack during this sprint than in previous sprints, and the quality of information that was shared during the standups has improved significantly. Overall, I am happy with our progress and looking forward to getting more in-person collaboration time in the near future.


Money Shouldn’t be the (Only) Motivator

While money is certainly important, and should be a consideration – it should never be the primary motivator for choosing a particular career or even for choosing particular projects or roles in a position. Making decisions based on financial considerations alone is a quick way to end up hating what you do and having little opportunity to improve your situation. Making the correct choices about what you use at motivating factors to drive decision-making can help make software craftsmanship a more rewarding and valuable career. Following some of the advice given by Hoover and Oshineye in Apprenticeship Patterns should allow a new or aspiring software craftsman to identify the motivating factors that drive success in the position and lead to a satisfying career.

It is easy to stay motivated when things are going your way and you are working on projects that you find engaging, fun, and adequately challenging without being overly difficult. The problem that the Sustainable Motivations pattern is hoping to address, rather, is when things get a bit more difficult. Sometimes it becomes difficult to see the passion in software craftsmanship. For example, sometimes in the course of developing the necessary technical skills to become a master craftsman, the aspiring develop will be faced with hurdles such as ambiguously specified projects, or shifting and conflicting demands of customers. It’s times like these, argue Hoover and Oshineye, where the motivation and determination of the aspiring craftsman are truly tested.

While I feel lucky to be actively interested and continuously challenged by my current work, I am sure that my luck will run out at some time in the future. I will be presented with a project that I find tedious, frustrating, and maybe even exhausting. I am confident in my ability to remain focused and motivated on working towards the end goal of becoming a craftsman, however. I feel that as Hoover and Oshineye mention, if I ever begin to have doubts they will easily be overcome by a need to continue earning money or the desire to maintain a reputation as a technologist. These motivators should keep me in the craft until my situation improves and passion returns as my primary motivating factor.

Looking Back on Sprint 2

The second sprint was a bit more open ended, with far fewer discrete tasks to complete than during the first sprint. This meant that rather than working independently during class to complete individual environment set up tasks, we worked as a team during class to discuss the user stories contained in the Google Doc. I feel that once again the team worked well together and everyone contributed to achieving the goals for this sprint. There are a few places where I see room for improvement, and this was discussed during our in class retrospective meeting.

One of the first tasks that I personally completed this sprint was looking at the mockup tool, Balsamiq. While I was a little unsure about this at first, seeing some of the mockups that other teams did later on in the sprint helped me to better understand the tool. I think that for the next sprint, using Balsamiq as a team to visualize our ideas will be extremely helpful.

Although I had already completed the build ng2-amrs and connect your ng2-amrs to the server tasks, these tasks remained on the sprint backlog because not everyone on the team completed them during the first sprint. By the end of sprint 2, however, all members of the team had completed both of these tasks and they were moved to the completed board. This was important because these tasks are essential to beginning actual development, which will likely occur as early as the next sprint.

Another task that was left over after the first sprint was learning how tests work in Angular. Although we were told at the end of last sprint that this task was probably not essential, we decided as a team to include it in the second sprint because the majority of the team had already completed it. Members of the team who had already looked at resources on Angular testing shared their sources with those who had not yet completed the task.

The most significant tasks for this sprint had to do with generating design ideas from the user stories shared by the AMPATH team through the Google Doc. We met as a team during class time and began by reading the user stories together as a group. Although much of the team had already read the user stories independently before class, I feel that talking them out was helpful in providing clarification. Members of the team shared their individual understanding of different parts of the document, and asked questions where understanding was lacking.

After we felt we had a general understanding of the user stories, we looked as a team to the tasks that were listed further in the document. We then brainstormed ideas in a document for the first task on the list. This is the task that addresses offline login and offline data storage. We collaborated with the group directly behind us to share our thoughts and also get a better idea of how they were planning on going about development.

I think that we as a team are becoming more comfortable collaborating with one another, and also with sharing our ideas with among the other teams. I think that in future sprints we need to continue to attempt to clearly communicate our intentions with other teams so as not to do overlapping work. Although the effects of duplicated work were not very severe during this sprint, it could result in a lot of wasted effort in the future. I am looking forward to continuing to work with my team in the third sprint and using what we have learned to work effectively and efficiently.

Software Development as an Art

Hoover and Oshineye make some excellent points that I strongly agree with in the Craft Over Art design pattern in Apprenticeship Patterns. Although I had never thought about software development in terms of art, I found their discussion of art versus fine art to be interesting and well supported. While it is relatively simple to argue that software development is a craft, I would imagine that claiming that it is art would generate a bit more controversy. In my opinion, Hoover and Oshineye do an excellent job of supporting their claims that software development, by nature of being a craft, is also an art – but not a fine art. The distinction that they make between craft and fine art has to do with purpose. Because software development’s purpose is to make a useful product for customers, it can be seen as utilitarian in a sense. The purpose of producing fine art is purely for beauty.

The important caveat that Hoover and Oshineye introduce in the Craft Over Art pattern is that the craft of software development may produce something beautiful, but it must produce something useful. This may mean that craftsmen must choose utility over beauty when it is necessary. Considering the interests of the customer over personal interests and balancing conflicting demands is important in building and maintaining strong relationships with the customer.

This pattern applies in a couple of ways to my current undertakings. The importance of creating software that addresses real problems for real people is something that is somewhat new to me. Writing code for AMPATH Informatics is exciting because of the real-world significance that my contributions have. The other place where this pattern applies is in my independent study web development project for Massachusetts HOSA. While the customer-development relationship is a bit different in both of these cases, many of the same tips from the Craft Over Art pattern apply. While I may not be paid for my services, I still have expectations placed on me by the instructors and organizations involved in these projects. Understanding and carefully considering my responsibility to deliver a product that is first and foremost useful will help me to foster strong relationships with the collaborators on these projects.

The One Thing All Newcomers Can Offer: Enthusiasm

The one thing that just about any recent college graduate has to offer a prospective employer is enthusiasm. While enthusiasm may help with getting in the door somewhere, once starting out on a new team of experienced developers the newcomer may be less willing to express that same enthusiasm. Although it may sound juvenile, the desire to fit in applies just as much in the workplace. This desire may prevent a newcomer from sharing valuable excitement and new perspectives with the team. Overcoming this fear of and sharing your excitement and creative ideas will be far more beneficial in increasing learning and value throughout your apprenticeship. In Apprenticeship Patterns, Hoover and Oshineye cover this topic under the Unleash Your Enthusiasm pattern.

If there is one thing that I am sure about, it is my desire to make a real difference through software development. I am passionate about making a difference and excited to begin this journey. I will admit, however, that I would be a bit hesitant to express this eagerness if other members of the team seemed to be skeptical of me. It would be far easier to take the conservative approach and try to match the excitement level of the team. Taking this approach is not the most effective strategy in these situations. It would be far more valuable to both the team and to the apprentice to fully embrace that enthusiasm and use it to inspire and motivate the team. Rather than viewing your excitement as an annoyance to the team, you should view it as an asset that will help the team.

When first starting out, it may be difficult to find ways to make any meaningful contributions to the team. You will need to earn the trust of the team before taking on risky tasks that may jeopardize the integrity of the work as a whole. One way to make contributions while also gaining the respect and trust of the team is to ask questions and unleash your enthusiasm. If you’ve found the right mentor, your enthusiasm for the craft of software development will be rewarded. This mentor will guide you, and you will give him or her a renewed excitement for the craft.

Starting out by Sweeping the Floor

As I will soon be starting out in a new position at an unfamiliar company, I was more than happy to look to Apprenticeship Patterns for help in making the most of my apprenticeship. While the position may not be exactly what Hoover and Oshineye had in mind when they wrote the pattern, I found the Sweep the Floor pattern to be almost universally applicable to any entry-level position. When you are just starting out, you may not feel comfortable taking on some of the more complex tasks. You may be unsure of where you fit in as part of the team, and the team may be unsure of you. The Sweep the Floor pattern offers advice on how to contribute to and earn the team’s trust as well as growing professionally when you are just starting out as an apprentice.

I found the inclusion of the story from Paul Pagal to be comical and also informative. As mentioned, there are certain less glamorous tasks that simply need to get done in order for the team to be able to function. While they may not be glamorous, they provide an opportunity to make yourself useful and appear motivated. This most certainly will not go unnoticed, and should lead to progressively more interesting and complex tasks. As your skill level as well as comfort level increases, you will begin to take on riskier tasks.

Hoover and Oshineye follow the story by saying that having to do less glamorous work to get your foot in the door may be tough to swallow for some apprentices who feel they’ve already paid their dues. While I’m not trying to discount the value that I feel my formal education has, I’m not sure that I agree that this counts as paying your dues. Until you’re part of an actual team facing real-world problems, you haven’t paid your dues. This is part of the reason that I feel completely content starting off with more menial tasks. I am more than happy to begin proving my worth and showing my team that I am ready for bigger challenges by starting off with some of the less glamorous tasks. After all, somebody has to do it.

Looking Back on Sprint 1

The first sprint contained a lot of small tasks for setting up the environment and getting familiar with the ng2-amrs system. While some of these tasks were simple, others that originally seemed simple became difficult and took more time than the team and I originally expected. Overall, I feel that the team worked well together and that we were able to complete the bulk of the story items for this sprint. There were a few areas where I think we could improve for the next sprint, and these topics were discussed during our retrospective meeting in class.

One of the first tasks that was completed for the sprint was to Create a GitHub organization for your team. Dominique assigned herself to this task, and created the organization. She invited all of the other team members to the organization during a class work day and ensured that we were all able to access the organization.

Another task that was completed quickly due to its relative simplicity was the Choose a label color for your team. Matt assigned himself to this task and changed the label color on the appropriate card on the Class Scrum Board.

I assigned myself to the Fork ‘ng2-amrs’ from CS-Worcester-CS-448-SP-2018 to your organization task. I was able to complete this task only because Dominique had already created an organization for our team and gave me the necessary permissions.

The Read and Read tasks were relatively simple, and all members of the team completed these tasks early in the sprint.

The Decide how you want to manage your team’s GitHub repository was completed as a class rather than as a team, so little effort was required on the part of our team.

Everyone on the team was able to complete the Clone ng2-amrs to your computer task, as Dominique gave all of the members of the team access to the organization’s fork of the project.

Some of the tasks that gave the team a little more difficulty were the Learn how tests work for AngularBuild ng2-amrs on your computer, and Connect your ng2-amrs to the server. While the team members that had the project built and connected to the server attempted to help other team members get up and running, there were a few different and unique problems that gave people trouble in building and connecting ng2-amrs to the server.

Matt was able to fix one of the most severe of these problems, namely that of the ladda module complaining about missing files. Matt shared his solution with the team and the rest of the class, and was able to help many people in successfully building the project.

We were initially waiting on the Ampath Informatics team to provide us with a link to a server that we could connect to. When this link was provided midway through the sprint, we chose to add the task to our sprint backlog as some members of the team were ready to accept more tasks. For this reason, it was not a concern that the entire team was unable to complete this task.

The final task that was not completed by everyone in the team was to learn about tests in Angular. Once again, this task was not of critical concern because we likely won’t be using testing heavily early on in the development process.

I think that the team worked well together, and that members supported one another throughout the sprint. One thing that we may be able to improve upon is communicating when we are having difficulty so that others are able to offer assistance. Or, on the flip side, asking and offering assistance when another member of the team seems to be struggling. I am looking forward to working with my team and getting into some of the more technical parts of the Ampath project.

Constructing a Curriculum

After recently completing a difficult, humbling and valuable phone interview for a position that I thought I was well qualified for, I decided to make a renewed effort in educating myself outside of the classroom. The discussion helped me to realize the areas where my skill set was lacking, and where to focus my educational efforts. While some classes offer information of a specific, desirable topic, I often find that I cannot find the exact topic that I want to learn as part of a course. I perform a quick search on Amazon, which reveals multiple books on the topic, and I quickly order one according to user reviews and ratings. This is the process that has occured time and time again, leading to a bookshelf full of books on varying programming topics. For many of these books, I have only just begun reading (or I got halfway through and was distracted by something else), and never fully gained an understanding of the topic that I set out to learn.

For these reasons, I found the problem statement of the Reading List pattern in Hoover and Oshineye’s Apprenticeship Patterns to be especially applicable to my current situation. The problem statement says, “The number of books you need to read is increasing faster than you can read them.” While I am constantly increasing my understanding of certain topics, new and improved methods are constantly being developed. Keeping up with the rapid pace at which software development changes is difficult, but following the advice of Hoover and Oshineye will undoubtedly give me a leg up on the competition. I like that the Reading List that they propose is essentially a priority queue, with the books that are most important at the top of the list and the ones that may not be as important towards the bottom.

It was reassuring to me to know that I was not alone in feeling overwhelmed by the amount of information that I need to attempt to gain an understanding of. The strategies in the Reading List pattern are sure to help me in organizing and creating a plan for learning new software development techniques and improving my skill set. Setting goals and prioritizing what I read will allow me to use books as a tool rather than simply being overwhelmed by what I don’t yet know.


Mastery as a Lifelong Endeavor

While I think that it is relatively straightforward to begin the software development journey, it is another thing entirely to become a master. Mastery is nearly impossible to measure and may require a lifetime of dedication to the craft to achieve. While these facts may be almost universally applied to any craft, I think that when applied to software development in particular they are especially telling. In Hoover and Oshineye’s Apprenticeship Patterns, they discuss a pattern termed The Long Road. It is this Long Road that is representative of the lifelong journey that is mastering the craft of developing software.

Hoover and Oshineye urge that the true value of mastery lies not in making more money or gaining status and power, but in, “comprehend[ing] and appreciat[ing] the deeper truths of software development.” This focus on the craft rather than on typical indicators of success such as promotions or high salaries is what sets truly great software craftsmen apart from the mediocre. I found it both inspiring and a bit comedic that Hoover and Oshineye included the parts about surpassing legendary software craftsmen such as Donald Knuth or Linus Torvalds. When you think about it, however, such feats do not seem entirely unrealistic considering that anyone truly hoping to become a master software craftsman will likely dedicate over forty years to that end.

I feel that this pattern would likely be offensive to developers who chose computer programming simply because of the abundance of jobs or relatively high starting salaries, not because of a genuine appreciation of the craft. These software developer posers would have no desire to become masters of the craft, and would jump ship at the first opportunity for a promotion or raise. This is also where the lack of knowledge transfer between generations of developers mentioned in the pattern’s introduction originates. If developers are waiting for any opportunity to move on, then the void that they leave is constantly being filled with new developers, leaving few veterans to show them the ropes.

I can certainly appreciate why a promotion to project lead or some executive position would be a tempting opportunity for career advancement. These roles, however, often require giving up the very things that make software development such an exciting and rewarding job to begin with. The feelings of pride and excitement after finally figuring out a difficult piece of a program or passing every test case is something that software craftsmen on their journeys to becoming masters will continually experience.