Author Archives: apham1

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.

CS-448 Introductory Blog Post

This is my introductory blog post for CS-448-02 Software Development Capstone.

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

Technical Interview Tips

Summary

In the article 5 things you need to know in a programming interview, Zhia Hwa Chong gives some useful tips for those starting their programming careers or those who are preparing for an interview. A quick summary of these tips are as follows:

  • “Always Think Ahead” – Referring to making sure when solving a problem to always look ahead and think about potential improvements. For example, he specifically says to think about edge cases, scaling issues, problem areas, and other topic-specific issues (e.g. handling collisions in a hash table).
  • “There’s more than one answer” – Each interview problem always has more than one solution, however, some of these solutions may not be optimal. It’s important to be able to write a working solution, but you should also look to improve upon it.
  • “OOP is not dead” – Make sure to think object-oriented (e.g. don’t cram everything into one method, don’t reuse code, etc.). Following these practices creates cleaner code, simplifying the code and makes it easier to understand.
  • “Craft your résumé” – Make sure to not skip preparing a great resume.
  • “Communicate early and communicate often” – Talk through the problem with your interviewer so they can understand your thought process and push you in the right direction.
  • “Use abstraction” – Using abstraction to hide complicated implementation details creates clean and easy to understand code. Afterwards if requested, you can implement any abstracted details.

Reaction to Content

I chose this topic because it’s something that is currently very relevant to me, as I’ll be graduating next May and hope to get something lined up before then. I had already seen many variations of these tips before, but I think reading this is useful for reinforcing them. While not necessarily applicable to all interviews, most popular tech companies follow the white-boarding process that this blog is giving tips for. For anyone looking to work for any of those companies, following these tips would definitely be valuable. However, they only cover things you should do during your interview, not topics that you would need to prepare for long before it, such as data structures, algorithms, general problem solving skills by solving similar problems, etc.

 

Source: https://medium.freecodecamp.org/the-most-important-things-you-need-to-know-for-a-programming-interview-3429ac2454b

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