Apprenticeship Pattern – Breakable Toys

The Apprenticeship Pattern “Breakable Toys” refers to a scenario where the environment you’re working in doesn’t allow for you to fail, stifling your learning because failure is often the best way to learn anything. According to the author, the solution to this is to create your own “breakable toys” from which you’re able to learn through catastrophic failure that won’t have an effect on anyone but you.

The thing I find most interesting about this pattern is some of the examples it suggests to do in order to create opportunities to learn. For example, creating your own wiki and adding more interesting features without being bound by existing implementations. I can see how working on something like this from start to finish would greatly improve your ability as a software developer.

It would be great if you could be satisfied with the amount of learning that you’re able to do within your current work environment, but given the fact that businesses need to make money to survive, taking risks and learning through failure is typically not something that can consistently happen if a company wants to continue existing. That’s not to say that mistakes should never happen, but it makes sense that a company would want to avoid them as much as possible in order to retain the trust of their clients. If someone were to make a costly mistake for a company, it should be used as a opportunity to learn from it, rather than just firing that employee and moving on.

I recall there being a disruption in Amazon’s S3 service causing around 3 hours of downtime being attributed to human error. One of the employees on the S3 team was debugging an issue when he accidentally removed a larger set of servers than he had originally intended, all due to a small typo in his input. Regarding this incident, Amazon stated: “We will do everything we can to learn from this event and use it to improve our availability even further”, acknowledging that they would seek to prevent it from happening in the future. I would imagine that the employee who made the mistake may have learned a lot about the potential effects of something that seemed so insignificant.

Advertisements

Sprint 2 Retrospective Blog

Our second sprint was much more productive than the first, thanks to our meeting with the representative from the food pantry. During the meeting we were able to gather a lot of information about what they needed from us. Currently, new users fill out a Google form which determines what level of aid they qualify for. This is something that we would want saved and automatically determined when that user comes to the food pantry. One of the main issues they’re currently having is that employees have to manually track the weight of their current stock. So every donation they receive they have to measure its weight and then manually enter the weight of the donation as well as what types of items were received. This is the main task we’re working on finishing this sprint. For this we should be focusing on making small quality of life improvements (such as automatically adjusting the total weight) and work from there. I’m interested in seeing if it would be possible to connecting to a scale to do this automatically after weighing a donation, but that’s something that should come later.

From the meeting we were able to figure out some of the food pantry’s pressing needs that we could address. I feel like we were able to devise clear goals to work towards.

After the meeting was over I believe we may have ran out of time before assuring that everyone knew what tasks were assigned to them for the sprint. During the sprint I think this was cleared up as Nick had already begun re-purposing one of his previous projects for the food pantry and let us know what he needed help with. Although, since we missed a couple of meetings we ended up making less progress than we could have.

During our retrospective, Nick showed us and the representative from the food pantry the progress he made on the new worker intake form. It’s definitely a step in the right direction. Once it’s cleaned up a bit I think it’ll be better than what they’re currently using. One thing we need to do is to make sure that we create something that actually makes it easier for employees at the food pantry to do their job. For this project in particular, we need to solve the main bottlenecks that they described: manual data entry and calculations. These are things that can easily be solved by automating the process. It’s important that we create something that is an actual improvement from just sticking with the Google form.

Near the end of the sprint I was given a different task to work on. This was what we were initially working during the first sprint prior to the meeting with the employee from the food pantry. For this I need to create a REST API interface using the USDA’s FoodKeeper Data so Joshua Farrar can deploy it to Heroku. While we were working on this during the first sprint, we were all researching what we needed to do individually which I feel may have wasted a lot of time. The resources for REST APIs that Professor Wurst sent me have been useful, and hopefully I’ll be able to finish this during the next sprint.

Apprentice Pattern – Sustainable Motivations

The apprenticeship pattern “Sustainable Motivations” refers to the situation in which you want to develop your technical skills but are faced with the messy reality of ambiguously specified projects for customers with shifting and conflicting demands. This is often frustrating because the best motivator for a programmer is being able to do things their own way, but you often won’t be able to have this motivation because you’ll be forced to work on problems no one wants to do. It’s crucial that you find sustainable motivations that push you to achieve mastery.

What I found interesting about this pattern was that it talked about some of the “ugly” parts of the software development world: working on tedious tasks you don’t enjoy working on or becoming frustrated with ambiguous specifications or conflicting demands. It’s hard to stay motivated when you aren’t enjoying what you’re doing, but you need to remember why you’re doing what you’re doing. Being able to realize what motivates you to continue pushing yourself is something that’s very important if you ever find yourself questioning your commitment to the craft. I suppose that for some people, they may find that they don’t have many, if any, sustainable motivations and decide to quit in pursuit of another path. For them, it may be beneficial to figure out early on that this isn’t what they want to do. Others may be able to figure out why they continue to push beyond their frustrations.

This pattern caused me to consider what motivates me to continue what I’m doing. Obviously for someone who hasn’t fully experienced what frustrations are being referred to in the article, it’s hard to be able to decide if what motivates me outweighs the potential frustrations, so this is something that I’ll have to experience for myself before figuring out what I should do.

Writing down a list of things that motivate you and keeping that list with you is a great idea to be able to push you whenever your feeling frustrated. If you aren’t able to come up with sustainable motivations, perhaps it may be time to think about if you’re walking on the road that you actually want to walk on.

Sprint 1 – Retrospective

Our first sprint was less productive that I had hoped it would be. I feel that during the sprint planning phase we should have made sure that everyone was assigned a task to get done working towards a clear goal. For most of the sprint I think most of us were unsure what we should be doing and weren’t sure what we were doing was leading in the right direction. This is something we should have discussed with the product owner (Professor Wurst) set up clear goals. Tomorrow during our sprint planning meeting we should definitely not leave until everyone understands exactly what they need to be doing. If we’re still confused about the requirements we should open up a discussion with the product owner. I feel the team would benefit greatly with a team lead who could potentially answer any questions the team has by handling communication with the product owner. That being said, I’m not sure that anyone would be comfortable with and/or willing to take on that role. There’s definitely a lot to improve on from the first sprint. If we don’t, then we may end up continuing to use our time unproductively. I think everyone wants to do a good job on this project, but may need a bit of direction on what they should be doing.

During this sprint, we spent some time on getting everything set up, such as GitLab, Slack, Trello, etc. We have yet to set up the project itself, however. I think because of uncertainty, most of us spent our time researching by doing tutorials rather than diving into the project blind. Although, we should have confirmed with the product owner everyone’s responsibilities for the week in order to keep the project on track. I took a look at the JSON file to understand the structure of the data, which I think was a source of confusion for many members of the team given that it wasn’t formatted for space reasons. I spent most of my time for the sprint working with GSON to convert the JSON file containing the FoodKeeper Data into objects representing the data in Java. I’m not certain that this is a necessary step for making a REST API interface for this data as I hadn’t done the proper research beforehand, so there’s no guarantee that the work that I did this sprint was necessary. That’s something that can hopefully be resolved next sprint. Also, I spent a little time following through some example REST API tutorials to get a better understanding of what our project may end up looking like. Java 11 seems to have incorporated HTTP APIs directly into the Java SE API (found at java.net.HTTP.*), so this may be worth looking into. It may be beneficial to take a look at the repository put up by the team at Western New England University to see how they’ve set up their project.

Link to the repository for the JSON converter that I worked on for this sprint: https://gitlab.com/worcester/cs/cs-448-01-02-spring-2019/team-fig/food-pantry-json-converter

Apprenticeship Pattern – The Long Road

The apprenticeship pattern “The Long Road” is a pattern for those aspiring to become master software craftsmen. For these people, the path that should be taken differs from what is expected from them. Rather than trying to climb the wealth ladder by taking every promotion you can get and enter a less programming-oriented role, you should continue walking on “The Long Road” by focusing on learning and long-term growth.

This pattern is really interesting because it’s a path that focuses entirely on honing your craft rather than salary. I’m sure most people would jump at every opportunity that offered them more money, regardless of what the job actually entailed, so long as they considered it a “step up.” This is a different, legitimate path to take, but it won’t necessarily be the same path as the one to master software craftsmanship. It’s entirely possible that in the long term, focusing on learning and long-term growth would get you “further” down the path of mastering software craftsmanship.

I’m still not entirely sure if it’s the path that I want to take, as it’s difficult to pass up short-term gains. It’s easy to say that you want to walk the long road, but when facing a fork in the road it may be hard to continue. Although, I’ve heard many stories of people who took a higher paying job only to end up regretting it due to lack of growth, poor work-life balance, boring work, etc. That being said, I don’t think that I’ve experienced the industry enough to decide what path to walk. So it’s difficult to say whether I agree or disagree with the pattern, but focusing on improving yourself would likely not lead you down the wrong path.

Imagining strange roles that you could be in 10, 20, 30, or 40 years from now and what you did to end up at those points is an interesting exercise that I think would help people figure out what they want to do in life. Obviously it’s not necessarily guaranteed that you would have a breakthrough from just thinking about it, but you might realize that you don’t like the path that you’re on right now or maybe your dream role has an entirely different starting point from where you are now.

“Why Doctors Hate Their Computers” Reaction

The article “Why Doctors Hate Their Computers” by Atul Gawande discusses the effects of the computerization American hospitals over the past decade.

I found it interesting that the computerization of many of the processes that health professionals use, such as recording medical observations, sending prescriptions, ordering tests, etc., ended up actually causing doctors to spend more hours working than they had before (spending about two hours doing computer work for every hour spent with a patient). This is surprising to me because cutting out the overhead of physically performing these tasks should have done the opposite. Yet, in practice, it seems that that is not always the case. Small details that doctors would have been able to ignore now act as roadblocks. For example, commonly skipped questions in a form may now prevent the doctor from submitting the form until filled. Although these questions alone may only take a few seconds to get an answer to, this could potentially add up and take a lot of time away from actually talking to the patient instead of just requesting information to fill in a form.

Another interesting topic was some of the potential solutions to solving the lack of doctor-patient interaction caused by doctors having to check off boxes in a form on their computer. Having someone else, whether in-person or through a camera, transcribe all of the data from a visit is a great solution to the issue. Of course, the cost of paying someone to do that is something that hospitals may not be willing to provide. There’s also the factor of a patient feeling less comfortable knowing that someone else is listening in on their conversation.

I feel that the real customer for the system was the hospital system itself (Partners HealthCare). While I think keeping their technology up to date is a good investment in the long run, the ones seeing the adverse effects are the doctors themselves. Computerizing all of the data and processes helps the hospital to be able to protect confidential data and ensure that all legally required information is gathered from patients.

The lessons from the implementation of this system apply to much more than just Electronic Medical Record systems. It’s likely that the computerization of any industry would see many of the same issues such as the decrease in human interaction and the frustrations in the software decreasing productivity. Although, in less regulated industries, these frustrations may be more limited.

This reading brought up an issue that I hadn’t really considered before. A lot of people, especially computer science students, are probably of the opinion that the computerization of any industry is a good thing. To an extent I still think that this is true, but you should consider the possible effects it may have on all parties involved.

Source: https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-computers

Apprenticeship Pattern – Expose Your Ignorance

The apprenticeship pattern “Expose Your Ignorance” refers to the scenario in which you’re assigned a project but you are unfamiliar with some of the technologies that are required. Under the expectations of your colleagues, you may feel pressured to hide your ignorance so as not to seem incompetent as a developer. The best course of action, however, is to tell people the truth.

I can see why people might be uncomfortable with the idea of exposing their ignorance. However, I think that anyone who is more interested in actually becoming a better developer rather than focusing on what kind of developer they’re perceived as would be able to agree with this pattern. Sure, you could choose to pretend that you have the knowledge to complete any task already and then try to learn those technologies on your own, but there’s no guarantee that you’ll be successful. If you promise to deliver something and then later have to admit that you’re less knowledgeable than you initially let on, then you’re going to end up worse off. By admitting that you’re inexperienced with certain required technologies and asking questions, you’re able to show that you’re capable of learning while also being able to learn much faster with the assistance. One common phrase that I see commonly used is to “fake it till you make it”. I don’t doubt that there are some people who will look down on you for exposing your ignorance, but as long as you continue to focus on learning as effectively as you can, then you’ll be much better off in the long run.

One of the things I found interesting in the excerpt was to write down five things that you really don’t understand about your work and to put it where others can see it. This is definitely an extreme way of exposing your ignorance, but if people who see it are able to answer your questions and cross off an item on the list, then you’ll improve far faster than if you were to try to do the research alone. I’m not saying that you shouldn’t try to solve problems on your own, but it’s in everyone’s best interest to seek advice whenever they feel like they lack knowledge.