Category Archives: CS448

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.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

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

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

“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

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Your First Language

The apprenticeship pattern “Your First Language” is a pattern that specifically focuses on people who are just starting out and only have a shallow understanding of one of two programming languages. For people in this situation who don’t feel like they have very in-depth knowledge in any particular language, the solution is simply to pick a language and become fluent in it. However, what language should you choose?

I think that this pattern pretty interesting and still somewhat relevant even to people who are comfortable in a specific language. For me, even though I feel that I’m pretty comfortable with writing in Java, I can say without a doubt that I’m still very inexperienced and will run into problems that I’ve never encountered before. According the the pattern, one of the most fundamental ways of improving your experience with a language is the solve an actual problem with it. Being able to encounter roadblocks naturally and discovering a solution to it is something that you won’t be able to effectively recreate through learning from small, self-contained examples in learning resources.

One thing that stood out to me in this pattern was what was considered the most important factor in choosing your first language. It states that you should choose a language that someone around you is an expert in. By having someone with that expertise within reach, you are able to learn at a much faster rate than if you were trying to learn it by yourself. Preferably, you would be able to work on a project with them using the language regularly, but as long as you can get feedback from them, it will still be immensely helpful. While I think that this should definitely be the major factor in your decision, I’m sure many people may not know an expert of a language that they would feel comfortable enough working with or seeking feedback from. For those people, it’s important to seek out those opportunities and expand your network, but I suppose that’s easier said than done.

Overall, I feel that for those in that situation, this pattern is something that should definitely be followed if you want to learn as quickly and effectively as you can.

Source: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02.html#your_first_language

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns

After reading Chapter 1 and the introductions for Chapters 2 through 6 of Dave Hoovers and Adewale Oshineye’s Apprenticeship Patterns, I feel that I was really fascinated about some of the topics and ideas that I saw.

Entering the industry following the ideas of being an apprentice (not necessarily in the literal sense or an actual apprenticeship program) is something that I think is really interesting as well as being a good mindset to have regardless of where you are in your career. As was stated in the reading, many of the patterns many not apply as much to you depending on your experience, but I think having the mentality to constantly seek to improve yourself is something that really applies to every part of life.

The story about the Zen master and the young philosopher in the introduction to Chapter 2 was really interesting because the idea of “emptying your cup” in order to open yourself up to different approaches is something that would be difficult to do without a strong self-awareness. I think that for many people, reading this could be the first step in reaching a point where you’re able to put down your pride and your past experiences/habits and just listen. If you were to act like the philosopher in the story, you’re not as likely to have more experienced colleagues want to continue to teach you. I imagine most people aren’t as patient as a Zen master.

The idea of perpetual learning brought up in the introduction to Chapter 5, while a good mindset to have throughout your entire career, is something that is really important for people who will soon enter the industry (or even before that). To someone about the start their career, if you begin your journey following this path, then you’re sure to be able improve and find yourself in a much better position that if you didn’t. If you don’t focus on improving yourself early on, you might end up stagnating and finding that after years in the industry that you’ve been standing still the whole time.

Overall, these readings have been immensely useful in improving my mindset. I can see why this was assigned at a critical point in the Computer Science curriculum. I can also see why people would end up reading the whole thing, because I’m sure that learning about many of the patterns found in this book will continue to help me in the future. Once someone finishes up their degree, there will no longer be any external force pushing them to continue learning, so being able to continue to seek out knowledge is something that you’ll have to do on your own. Finding topics to study that interest you and will help to improve yourself is something that shouldn’t be overlooked.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Be The Worst

The apprenticeship pattern “Be The Worst” refers to the situation where you’ve outgrown your team and possibly your entire development organization and now you’re no longer learning at a rate that is acceptable to you. The solution to this is the find another group made up of developers where you are the weakest member so you have more room to grow. The quote used in the article to represent this is “Be the lion’s tail rather than the fox’s head!” Another quote that emphasizes this idea is “If you’re the smartest person in the room, you’re in the wrong room.”

I think that while it’s true that being surrounded by developers who are smarter or more experienced than you will definitely accelerate your growth or learning, if everyone followed this idea then the “junior” team members wouldn’t have anyone above their experience level to learn from because they would have already moved on to greener pastures. That being said, everyone doesn’t follow this pattern. There are likely many experienced developers who are happy with the level that they’re at and have no interest in switching teams giving less experienced members of their team a mentor to learn from.

Reading this pattern hasn’t really changed my mindset, as it bears some similarities how I had already thought about my intended profession, albeit a little more extreme. While I agree with the pattern as it refers to switching teams when you feel like you’re no longer growing, I feel that it can potentially be an unhealthy mindset to have. I think a better mindset would to start looking for new opportunities once you’re no longer satisfied with your work. The wording here is very similar to the original pattern, however it also takes into account those who enjoy their jobs, even if they might not be learning as fast as they could be had they joined a new team.

Overall, while I’d say that following this pattern would likely accelerate your growth, I don’t think it’s the be-all and end-all solution to a successful and rewarding career. Being the “smartest” person in the room doesn’t mean you have nothing to learn, especially when it comes to learning how to be a good mentor.

Source: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch04.html#be_the_worst

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.