Author Archives: iharrynguyen

Why Doctors Hate Their Computers

After reading “Why Doctors Hate Their Computers” by Atul Gawande, I was intrigued on how technology was actually making lives of individuals harder; when the goal of technology moving forward is to actually lift the weight off your shoulders and make things more convenient. Another aspect that was interesting was why was it so universal that almost all doctors started to hate their job when they had to be in front of a computer screen for awhile longer? As a computer science student I could safely say I average about 6 – 8 hours a day in front of the computer and when going to work I am in front of a screen for a full 8 hours but that doesn’t make my life miserable; maybe it is something one has to get accustomed to.

As I was reading, I found that the system had many flaws, especially the fact that it made the doctors enter redundant data when it simply should know and automatically be filled in. Obviously as stated in the article this system was not meant for the doctors or health care professionals but instead for the patients. It was created so they could see what their diagnosis is, what doctors actually said, what medication to take, more information about what is going on, etc. Although this system is in its infancy stage and there are many flaws, I believe that in the future there will be much progress in the system and the way this system is implemented, the connection between doctor, patient, and technology will strengthen.

There are many things to walk away with after reading this article. The first would be our approach when it comes to creating technology and having it benefiting any parties involved without the cost of bringing down another. So when it comes to planning out our idea we must try our best to not sacrifice the possibility of creating a well rounded application; as easy as that sounds I know it is always difficult. There was not much I disagreed with because I was able to see both sides of the spectrum.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

The Long Road

Far too often you see individuals seeking a shortcut to something they want whether it be wealth, fame, the perfect body, learning, skills, etc. the list goes on.

The Long Road discusses the problem of you wanting to become a master software craftsman and accept each pay raise but leave behind the long term growth opportunities; sure accepting a higher paying position would be nice but the author tells us why sometimes it is better to focus on your long term journey and the abilities you will unlock if you take your time and not take shortcuts. He discusses the amount of knowledge and appreciate software development much more over time. This pattern is not targeted towards individuals that are aspiring to become CIOs or project managers; more towards those who are passionate about software development and being crafty.

One action that was suggested: “Close your eyes and imagine yourself in 10, 20, 30 and 40 years time.” What experiences do you as an apprentice desire? For me, many came to mind. I am expected to graduate in a few months and when I picture myself a year from now it is to be working as a software developer in a structured company learning and absorbing as much as possible but I do disagree the part where I would not want to move up positions. My goal is to start off as a junior developer and over the years move up to a senior developer and maybe one day just a project manager whose goal is to help the team when necessary. I believe even if you are no longer considered as a developer, your thirst for knowledge will continue. This pattern helps me realize that my journey is just beginning and it will be a very long road to look forward to and I can’t be any more excited for it to start!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice

Practice pattern:
You will learn by making mistakes and it is inevitable. How would you purposely make mistakes while on the job? This pattern suggests in order to do so you must find a mentor and have them hand you a task you are not comfortable with and move forward from there. Practice your skills and make improvements each time.

George Leonard says, “The people we know as masters don’t devote themselves to their particular skill just to get better at it. The truth is, they love to practice—and because of this they do get better. And then to complete the circle, the better they get the more they enjoy performing the basic moves over and over again.” I couldn’t agree with this quote more. Over the years we have completed numerous projects and learned many methods on solving problems we encounter while completing these projects. Over time we developed the skills of analyzing the way we go about writing code and fixing bugs without even realizing it.

10,000 hours. That is the amount of time it takes an individual to truly ‘master’ something. Now will that be the case for us? I wouldn’t say so to an extent due to the changes in technology but basic skills like planning, designing, problem solving and debugging would definitely improve given we put hours into working on these skills. The author also makes a very good point when he says practice does not make perfect if you are practicing the wrong skill over and over. There must be changes to improve on that skill each time one practices it.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship

Throughout our undergraduate studies we were taught how to read, write, test, debug and understand code. Data structures were drilled into our heads and knowing basic time complexity of methods were almost second nature to us. One thing we were never taught was the transition stage going from student to working in the industry that we have been preparing for. What is expected of new graduates and how much of the skills carry over from school? Countless questions to be answered but after reading the first chapter of ‘Apprenticeship Patterns’ it gave me a reassuring feeling that everything will work out eventually; if not ctrl+alt+del.

Right off the bat a read a sentence that intrigued me, ” Far too often, it ends with a promotion to middle management…just a few years later…”. It made me wonder if this is what the software industry is truly like. Do that many software developers crave the idea of ending their software development career so soon? For me, the feeling of being able to come up with a solution to a problem that has created a roadblock in one of my projects has got to be one of the best feelings ever so I was not quite sure why so many individuals choose to accept this management role. Was it because of a pay raise? Tired of thinking on days end? I guess I will find out in the near future.

When learning what it means to be an apprentice, I was able to put myself in the definition given, “Having the attitude that there’s always a better/smarter/faster way to do what you just did and what you’re currently doing.” This definition is true to this day because learning is part of the life of a developer no matter if you’ve just started programming or have been programming all your life; technology will always be changing and you must change with it. What I took away from this passage was that there is always an apprentice side of a developer even though the author suggest that apprenticeship is the beginning of your journey as a software craftsman. I guess in some ways our apprenticeship has already started, learning from our professors and seeking their guidance to fulfill our thirst for knowledge they could provide us.

Chapter 2:
The patterns in this chapter describes how many students graduate and go into their first job believing they know everything and how things should be done but that is not the case. One must go in with an open mind and absorb as much knowledge we can in the first few years.

Chapter 3:
This chapter teaches us to not be too caught up on the things we achieved in the past but to be able to move forward and learn new material. It also teaches us that by communicating with our team we may be able to unravel the things we don’t know even exists.

Chapter 4:
“If you are the smartest person in the room, you are in the wrong room” – Some guy. On our journey we will come to this point eventually. We have learned mostly everything our company can teach us but becoming comfortable or not is up to us. We must desire to continually grow and in order to do so sometimes we must seek different organizations.

Chapter 5:
Learning a new skill is always hard at first but learning how to learn may seem even more daunting. This chapter teaches you the methods on how to learn new information and apply it to whatever you’re trying to do.

Chapter 6:
Simply seek knowledge in books for a book is worth decades of knowledge by the author.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Nurture Your Passion

I understand there will be a point in time where your team will be assigned a project that does not necessarily excite you. Sometimes it becomes quite difficult to work on something that you are not passionate about or the environment surrounding you is too hostile. From this chapter I learned that by working on one of your passions outside of work, you are in fact nurturing your passion and giving yourself a sense of fulfillment.

The author illustrates the important of setting clear boundaries that define the environment you are willing to work in. Steer clear of settings that disrupt your good mood; always try to stay positive.

I agree with this pattern because things may get overwhelming at times and this is the time where you have to take a step back and breathe. It allows you to connect with yourself again. I actually am not looking forward to experiencing times where an outside source impacts me and my work negatively and am curious as to how I will handle it.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Software Dev Capstone

Hello all,

This is the last semester of my CS journey; Spring 2019. This post is for CS 448, the software dev capstone course.

Stay tuned,

Harry

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Proper Documentation

We’re computer science seniors at Worcester State University so that means we should be able to write a full fledged technical documentation for the program we have written am I correct? Yes and no. We were taught the importance of writing documentation and very lightly touched upon what should be included in documentation but after reading ‘Software Documentation Types and Best Practices’ I learned there are actually different types of documentations for different projects.

The image below shows a general guideline for the steps to be taken when it comes to writing a project documentation.

Project-Documentation

We know that the main goal of effective documentation is to ensure that developers and stakeholders are headed in the same direction to accomplish the objectives of the project. The image below is a breakdown of the two main categories of software documentation:

Documentation-Types-1

The author then goes on and describes the different types of documentation:

System documentation represents documents that describe the system itself and its parts. It includes requirements documents, design decisions, architecture descriptions, program source code, and help guides.

User documentation covers manuals that are mainly prepared for end-users of the product and system administrators. User documentation includes tutorials, user guides, troubleshooting manuals, installation, and reference manuals.

Process documentation represents all documents produced during development and maintenance that describe… well, process. The common examples of process-related documents are standards, project documentation, such as project plans, test schedules, reports, meeting notes, or even business correspondence.

All in all I learned that there is not one special or main way to write documentation but there are actually many.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Angular

After finishing our final project I was still curious on many things about angular and how we would use it in future projects if we were to transition over to becoming a front end developer. This blog ‘Why should you learn Angular in 2018?’ by Aman Goel talks about Angular is, the different types, and the advantages.

From what I’ve learned, Angular is a framework that developers use to build applications (a simplified view). Goel talks about the development of angular applications and how it incorporates Typescript along with HTML and CSS. I know I built my project with the latest version of angular when I created it with the @angular-cli/@latest command but apparently there are versions from Angular 1 to Angular 7 and skipping Angular 3.

Some advantages of using Angular is that it supports Single Page Applications which is what we did for our project. A single HTML page that is updated dynamically according to the interaction of the user.

He lists the advantages of using Angular as seen down below:

– Supports Single Page Applications
– Two-way data binding
– Modularity in Angular
– Reduced coding
– Declarative User Interface
– Easy Integration
– Cross Platform

Before reading this blog I did not know how much we learned from doing this project but after reading it, I realized that all of the advantages listed in this blog were used in the process.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Are we now Full-Stack Web Developers?

As you may know, for our end of semester senior project we worked in groups of two in charge of developing a web application that had some sort of functionality. When we were first introduced to this we didn’t know whether to feel scared, nervous, excited or all of the above. What is HTML, CSS, angular, boostrap, etc.? So many things were thrown at us but in the end we made it. We learned all of it and no the question is.. are we full-stack devs? Maybe Eric An can answer that question in his article, ‘What is a full-stack web developer?’

The article begins with a big red T shaped image. The T-shaped model is a concept that describes the abilities/characteristics of an individual where a person has many generalized skills with a specialization in few. The full-stack web developer supposedly knows many technologies but specializes in few which is front-end development and back-end development.

Front-End web development is the presentation of the website which includes HTML and CSS and sometimes JavaScript; pretty much everything that the user sees when clicking a link. The goal is for users to provide a platform for users to interact with. Some other skills may be UE/UI design. For our project we learned the basics of HTML and CSS and I also learned how to use bootstrap to make things much simpler. Front-end development was a success!

Onto the back-end web development.. The creation of data collection processes haunts us to this day. We redefined the definition of struggle when it came to the back-end part of this project. Back-end development is associated with the front-end where as a server is being created to communicate with that the user is trying to do on the front end.

The definition of a Full-stack web developer is an individual who is in charge of performing both front-end and back-end so that all of the technologies put together makes up a website. After reading this article, although we are not experts in front-end/back-end development we could be considered full-stack developers!

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

How QA Engineers actually test code

CS 443 has taught me many things: how to test code, the different ways to test code, collaboration among peers, what is possible/not possible in Java, mockito, the list goes on. What it has not taught me is how code is actually tested in the field professionally; what should I expect to do or know if I were to shift towards the QA Engineer path?

‘A Day in the Life of a QA Engineer’ by AJ Larson talks about what he does in a professional setting and I compared it to the daily tasks we performed in class and it seems it is not completely opposite. He starts off by comparing software developers to QA engineers and stating that it is not too different; some companies even combine the two into one where you are a dev and a tester. He talks about how the team communicates; telling each other where they are in the project, what their plan is and if they have been encountering any problems. I guess in a way we have been doing that in class.

Onto the more important part of this blog is where he talks about testing ‘stuff’. He spends his time running manual tests and when he encounters a failed test how he goes about it. I learned that communication is key in both school and professional work environment; pretty much anywhere there is teamwork there must be communication.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.