Author Archives: dcantonblog

Why Doctors Hate their Computer

This week, we were asked to read “Why Doctors Hate Their Computers“, and article written by Atul Gawande. It was a wonderfully written article that gave insight into the period of time where hospitals adopted the new Epic software system, and how they suffered through the process. It gave different outlooks on the computerization of enterprises, the pros and cons, and the contrast between human-centric work environments (adaptable ones) and computer-centric work environments. Adopting this technological overhaul was a major step in healthcare that hospitals across the nation decided to undertake. It came with training for nearly all employees, the hiring of technical staff, policy and routine changes for care providers, and a tremendous amount of headache.

The article dove into statistics of career satisfaction that healthcare providers in different specializations report. On average, doctors spent about 2 hours on their computer for every patient-facing hour the spend in the clinic. There was correlation found between this and job dissatisfaction, and especially between time spent on the computer and burnout rate, as reported using the Maslach Burnout Inventory. Doctors in specialties such as Emergency Medicine, who spend large amount of their time logging information into computers, reported significantly higher rates of burnout and job dissatisfaction when compared to a specialty like Neurosurgeons, even when they spent significantly less time at work. With the overhaul of Epic, doctors had to spend even more time on their computers logging patient information, often after hours and at home. Patients were booked for double the time slots they had previously been booked for, effectively halving the amount of patients seen per day. Not only this, but in a study done by the University of Wisconsin, it was found that the average workday for doctors increased to around 11.5 hours. While reading, it was pretty concerning to think about how these people who are trying to take care of others are doing so on such extreme schedules.

It wasn’t just learning curves that seemed to make the job harder on doctors. The senior vice-president at Epic, Sumit Rana, called one issue “the Revenge of the Ancillaries.” Since Epic was a system that would be used in every position in the hierarchy of the hospital, there were often disagreements regarding what administrative staff wanted the software to do and what doctors wanted the software to do. Since doctors had been used to calling the shots (for the most part) regarding patient healthcare, having restrictions placed upon them was a difficult thing. Not only was there the tension of having to learn and implement a new software system into their daily routine, but there was also tension “politically” in their work environment due to administration.

So who was the real customer for the system? I think it is clear to say it was hospitals, and the technology from a sales perspective was aimed at ease of use for doctors and administrative staff. However, Gregg Meyer, the chief clinical officer at Partner’s Healthcare who oversaw the introduction of Epic, put it really well in my opinion. “‘…we think of this as a system for us, and it’s not’, he said. ‘It is for the patients.’” Meyer is convinced that it will improve over time. The Epic system is new and absolutely massive. In 10 or 15 years, national EMRs will be far better than they are even today. There will be many of the same issues, however there is a tremendous amount of benefit that comes from it. According to the article, “In the first year of the study, deaths actually increased 0.11 per cent for every new function added—an apparent cost of the digital learning curve. But after that deaths dropped 0.21 per cent a year for every function added.” A system that does that seems worth the headache in my eyes. I hadn’t at all considered this viewpoint before reading this article, and it made great sense to me.

I think there is a lot that can be learned from this article far past the domain of hospitals, EMR, or even software in healthcare. The article referenced “The Mythical Man-Month” by Frederick Brooks which I found pretty interesting. It dives into the human aspects of software engineering and working in a computerized workspace. The actual development environment and technology used within the workspace has changed, however things like the scaling of collaboration and teamwork in a project-based environment have remained largely the same. Within the book, Brooks coined something called Brooks’ Law, which states that “adding human resources to a late software project makes it later.” Clearly even back in 1975, they knew a thing or two about the complexity of introducing and launching software products on a large scale — and the implementation of Epic was another example of exactly that.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Be the Worst

This pattern, “be the worst” to my understanding means, we should surround ourselves with people who are very clever or know more about the subject or field you are in.

From the readings under “be the worst ” which says “what do i do when my rate of learning has leveled off?” You have taken the time to learn something new, immersed yourself in the subject matter, practiced diligently for a period of time and look up and see that you are ahead of those around you. Now what? There are only so many books, blogs, and other resources you can learn from until you reach a point where you must learn new skills from other humans. We are social creatures, by nature. We rely on each other to survive and part of that survival involves learning from each other. It’s difficult to imagine a world where we all had to learn everything on our own and couldn’t benefit from the knowledge and insight of those around us. So for us be connected with the world we need to learn from others. And also the is a saying not everything that we know, we learn from each other and by that we grow. So the more we learn from other developers, there more we grow as a developer. We can look for people who know more than we do and learn from them. We can also be in a team were you a the least among them. Knowing you are the least, you tend to work harder to keep up with them and also you get to learn new skill from them too.

From the readings “weakest member of the team, you should be working harder than anyone else”. There are risks associated with this strategy. You will be the least effective developer or person around the team. This also means your contributions will not be sufficient whereby dragging the team down. Because of this situation, team members may not put up with you very long. So putting all these risks into consideration, if you are really determined to learn, you will have to strive harder. In other sense, the only choice for you to stay in the team is to learn harder. That also means extra work for you.

Apart from all the risk involve, being the worst is a great way to improve your effectiveness in a given subject area quickly

Reading this pattern has made me know that in my own world i may feel i know everything till it get out of my world to see if really know everything or not. which knowing everything will never be the case. We all learn from each other. And knowing this idea, I will have to surround with people who are more challenging or better that me. Through that i get to learn new skill and better my self.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Finding a Mentor

As we will be looking for the best skill or training from masters, we need mentors or a mentors who we can look up to.

From the readings and with the understanding if got, finding a mentor is not all that easy, let alone mentors. As someone who want to be an apprentice or who is already an apprentice, he or she must be very careful choosing a mentor. Some of the things he or she must know before choosing a mentor(s).

  1. He or she must know her or his needs and also be very ready to be committed. Once he or she knows what he wants from the mentor then he starts searching. Only he know what things like dreams or desires and what type of person can help him get to where he wants to be. I also learnt from the readings, mentors do not have to be from the same company/industry, country or gender. One has to be more open minded to new possibilities by working outside of your comfort zone.
  2. To really succeed in the working world, one has to search for many mentors as possible. This helps you gain more skills from different areas. For example, you can be learning networking from a particular mentor whilst also learning another area like software programming from a different mentor. With that you are gaining a lot which does not limit you to a particular field or area.
  3. You need to choose very carefully when selecting a mentor. You don’t want to waste all your time learning things that will never be useful in your career. Also while carefully choosing for a mentor, one has to be sure he is very comfortable with the mentor.
  4.  As time passes on, your life evolves, your needs change and the desire for a new mentor may become apparent.  However, the mentors that helped you grow and prosper should never be ignored. Though you may now have different mentors, the relationships you formed with those from the previous chapters in your life must remain active.

From the readings, I got the understating i need not to rush in getting a mentor. When choosing one, i have to be very careful. I should not limit myself to only one mentor but to learn from many mentors. In that case, at least i gain a bit of knowledge in every field. One particular thing that interested me was “Passing along what you have learned from your mentors is one of the ways in which you can begin the transition to journeyman status.” From, i come to understand that in order for me to get to the top or to be a master, i have to also search the knowledge I have gain to others.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns CH. 1 & CH.2-6

Welcome back to Dcanton’s Blog, today I will going over my takeaways from the Apprenticeship Patterns book by Adewale Oshineye and Dave Hoover. The reading described the 3 roles in software craftsmanship, these roles are the apprentice, the journeyman, and the master. Reading about this helped me realize the depth and responsibilities that come along when going through each role. I think the role that intrigued me the most was the Journeyman, it seems like the most challenges are encountered at this stage. Oshineye says “he moves between projects and masters, seeking to diversify and deepen his portfolio; he seeks to elevate his status within the community;”. From the reading I gathered that this role takes up the most time and that this is the role that many people can get stuck on but the reward of making it to the Master role is worth it. All 3 of these roles play off of each other and chapters 2-6 give insights to some of the problem people might encounter and solutions to help improve in different areas.

In Chapter 2 ’emptying the cup’ it talks about having one solid programming language under your belt to solve problems. This is something that I completely agree because with the amount of languages out there, it can be daunting and make you feel that you need to know a lot of these languages to solve a problem. When I first started learning to program I had the mindset that if I try to learn multiple languages then the problems I run into will be easier to solve but I have since learned that sticking to one language at a helps you grasp and apple more techniques about that language.

Another chapter that I learned from is chapter 4 ‘Accurate Self Assessment’. This chapter talks about the problem that affects to many people which is, the rate of learning has leveled off. Finding motivation to strive to get better is only half of the battle because motivation can only take you so far, Its discipline and drive that are the key to constantly improving. The chapter also says its better to be a small fish in a big pond than a big fish in a small pond. By surrounding yourself with developers better than you, you can learn much more and see yourself grow to their level. That is why it is crucial to not get complaisant when you reach achievements, keep setting goals and record the milestones. An issue I struggle with is that after I solve a problem or finish a project i’ll get laid back and try to ride the success for as long as possible and the result is I get too comfortable. This chapter gave great advice and I recommend you check it out.

Overall the content in the book is great for developers of all different levels. After only 6 chapters I have taken a lot away and plan to continue reading. I plan to apply what I learn on my road to becoming a master! I will link the book below, Thank you for reading and I will be back again next week.


From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

CS-448 Introduction

Hey everybody, my name is Dexter Canton. This blog is for CS-448, Im looking forward to sharing my posts with you all.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Hashmaps Blog 2

Today I read an article on about HashMaps. I have used HashMaps before in Data Structures as well as Unix systems and have found them to be a very resourceful way to store and retrieve data. Most developers know about HashMaps but don’t completely understand how they work, in todays blog we will be cover HashMaps in JAVA.

HashMaps have an inner class called an Entry Class which holds the key, values and will return a value at the end. Two important main methods in the class are put() and get(). put() associates the specified value with the specified key in the map, it checks if the key given is null or not. If the given key is null, it will be stored in the zero position. The next internal part of the put method is that it fits the values inside of the limits of the array. The get() method is very similar to the put method but instead of storing, it returns a value. Get() gets the hashcode of the main object and finds the location of it in the array. If the right value is discovered, then it returns the value but if it cannot find it then it returns null. Put() and get() are two major internal parts of HashMaps and looking back at some of my old projects with HashMaps I now fully understand what is going on internally when I execute the program. I will use HashMaps more frequently in my projects now and I hope that after reading this you will be able to understand HashMaps better and will be able to give them a shot.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

White Box Testing Blog 2

Welcome back to Dcanton’s blog. This week I’m going to be talking about  a blog posted on Apiumhub, a tech hub that specializes in software architecture. The blog talks about the benefits of unit testing. The author starts by giving the goal of unit testing which is to segregate each part of the program and test that the individual parts are working correctly. He then continues to list why it is beneficial. One of the benefits is that it improves the design of the program, it makes you think about if your code is well defined and if it reflects what the outcome is supposed to be. Another benefit of unit testing is that reduces cost long term, since bugs are found earlier in the process, they won’t be as costly and much easier to fix than later in the process.

I chose this blog to discuss this week because it has a lot of information on how effective unit testing is. Since there are other ways of test such as black box testing and grey box testing, this gave me a good understanding of it and the benefits that come from using this method. One thing I learned is that white box is tested by tester while others are tested by developers. Thank you, Dcanton blog will be back next week with another blog

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Clean Code Blog 1

This week I decided to read a blog post for my blog entry. The blog post I read is titles “These tools will help you write clean code” by Adeel Imran. Before finding this blog post, I’ve had a general and basic idea about coding and how it should be written, but I haven’t understood in great detail how to properly write clean code. The reason I chose this blog is to learn and be able to use the clean coding techniques on my future projects so it will be easier for other people read.

Clean code is extremely important in becoming a strong software engineer and when working in a team having clean code is a must so your teammates can understand your code. The blog opens up by saying that in more or less all software engineering jobs you will be working with a new code base at one point or another and that inconsistency is a big fundamental problem when working with different code bases. The author ends the blog by saying “In the end, coding is writing” and as a developer our responsibility is to maintain a consistently so it will make our code easy to follow when being looked over.

Besides all of the great resources that it gives, a major takeaway from this blog that I will apply immediately to my next project is using clearer names. Before reading this blog if I wouldn’t put much effort into naming things in my project but I learned that applying clear names not only improves readability, but boosts the context making the intent of the code easier to read. If I am to use clear names it will help the reader understand more quickly.

My goal is to become a software engineer and in the CS program sometimes it is hard for me to write clean code because I am focusing on other parts of the assignment or don’t have this labeled well. This article has given me ways to write clean, effective code in the future and I hope it can do the same for you.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Code Reviews -Blog 1

Hello readers, welcome back. This week I will be talking about code reviews and why they are essential to the testing process in computer science. I read  a blog titled “what is code review and why is it so important” by Eugene L. who is a project manager. He begins his blog by talking about how code reviews is a great form of communication between team members and for junior developers, they can become more proficient through this communication and at the same time help improve the code. Although code reviews are used to spot bugs, they have resulted in teams understanding each other better which companies enjoy. Another point brought up in Eugene’s post is that code reviews increase productivity. Because the code will be reviewed by someone else  the developer will be motivated to write better code and make sure its flawless. Finally another reason code reviews are essential is that it helps the developer understand the product better and as a result will be able to communicate better .

This blog had great points and helped me understand why code reviews are  so important to when testing. When it comes to myself, sharing code hasn’t always been a strong suit with me because I tend to get nervous when other people view. I understand that I’m not the best and I understand after reading the blog that one of the ways to improve is by having my peers review my code. Feedback is necessary to have successful code reviews. If you’re working on a project with someone else or a team, you would want to make sure that everyone understands your code and how it effects the product, as a result it will improve the team chemistry. In my recent projects that I have had in my, I try to make sure that my code is understandable. Code reviews are a crucial part in testing and with them, the product will be much better than it would be without it.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.

Introduction CS-343

Hey everybody, my name is Dexter Canton. This blog is for CS-343 FA 2018, Im looking forward to sharing my posts with you all.

From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.