Why Doctors Hate Their Computers Summary

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

In the article link listed above, surgeon Atul Gawande describes his frustrations with a recently developed new software which he and many others must adapt to. Initially one might assume this person just isn’t good at using software, like your grandmother trying to send an email. However, professionals in the medical field are typically especially adept at technology, their patients lives depend on their ability to update themselves on the latest development in the industry. That being said, the problem must lie in an inefficient new system.

The earlier stages of the switch to the new software are especially problematic. Firstly, medical professionals in all areas are required to spend a lot of time at training sessions when they could be spending it for their patients, which costs efficiency right off the bat.

Next, as everybody learns how to use the system, multiple problems can occur. It can take hours for somebody new to complete a complicated task, or minutes for one who is experienced in it, so the most obvious option is to get help from the IT department. The system is also new as a software product, new software products contain unknown bugs and glitches. I assume there is a rigorous testing process for any new tech when patients lives are effected by them, still, the software can be found at fault in the early stages. Both of these scenarios contribute to hundreds of tickets flood the IT departments inbox. In response, the hospital hires more IT people to help but ultimately a backlog keeps issues in waiting. Some of these issues can be especially serious in the medical field.

These early problems are expected, with the assumption that after a few months the system will be seen as an improvement. In this case however, even after getting use to the system, Gawande and his colleagues notice setbacks compared to the old software. For example, it added the ability for everyone across the organization to edit the “problem list.” The list use to be a quick way for clinicians to assess their patients at a glance, now it is filled with redundant notes from each person who accesses it. The same diagnosis is listed three times by three different people, long descriptions make it difficult to read the few things that actually matter, all contributing to more inefficient overhead. Furthermore, filling out diagnosis sheets has become more time consuming with the addition of new required fields. Whereas it use to take one click to order a mammogram, now it takes three.

What can be done about these inefficiencies? The article elaborates by explaining the concept of the “tar pit.” This describes a state of software development where a program becomes so large, it must be rigorously defined and spelled out for every specific situation so that it can encompass each scenario the same way. Users find themselves slowed down by these specifics, but cannot escape them, much like a tar pit. The result is that professionals spend so much time working through the system, they spend less time actually doing their jobs.

Software progress trends like these have serious consequences, professionals in this situation are more likely to experience burnout. Burnout is a state of emotional exhaustion, depersonalization, and personal ineffectiveness, this is caused by the pointless bureaucratic work that professionals must endure with their daily career. This eats up much more time than they are willing to give up. In 2014, only a third of physicians stated their work schedule “leaves me enough time for my personal/family life.”

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

Journey into Sustainable Motivations (A Individual Apprenticeship Pattern)

On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my third individual Apprenticeship pattern I have chosen “Sustainable Motivations”. I will first summarize the pattern and then I will state my reaction of this pattern.

Sustainable Motivations summarized

Sometimes we are hit with the harsh reality of the “real world” you will run in to overwhelming programming projects. These programming projects would have you in all sorts of negative feelings more often then not. Other times there would be just about anything in your job that would have you feeling all sorts of ways as well. This pattern is guided to helping you get through these hurdles and preventing your programming motivation to be stump. That is why ” it is crucial that your motivations to program are aligned with walking The Long Road” [1]. In order to be able to achieve that you must ” it is crucial that your motivations to program are aligned with walking The Long Road“[1]. Otherwise “you will find yourself trapped in a Golden Lock”[1]. This pattern advises you to first make a list of at least 15 things that will keep you motivated and then after waiting a while add 5 more to the list. Then you are to answer the following question to help you with the eliminating process… “How many of your motivations are about what other people think rather than what you feel? Are the percentages different between your first 15 and the final 5? How many of the motivating factors can you do without?”. Your final step is to list, the 5 most important goals that would keep you motivated.

My Reaction

This pattern guides you with the ability to narrow down your goal to 5 things that would keep you motivated. It also, makes you aware of the danger of being too complicit by not desiring for mastery could lead you to being trapped in a Golden Lock. I agree with this idea. I found that this idea is not just interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think because it has made me realize that I need 5 important motivation that will keep me motivated on this long road of Software Craftsmanship.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

 

 

“Some programmers become inadvertently trapped by their motivations. In More Secrets of Consulting, Dorset House, Jerry Weinberg describes this phenomenon as the Golden Lock: “I’d like to learn something new, but what I already know pays too well.” “[1]
[1] Quote is from the book Apprenticeship Patterns by Adewale Oshineye, Dave Hoover from the Sustainable Motivations pattern chapter.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

Concrete Skills

For today’s blog I will be writing about the Concrete Skills chapter in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The problem that is summed up perfectly in the context section of the chapter, which is summarized as the fact that you have knowledge does not necessarily mean you are knowledgeable. This meaning that your knowledge can be useless without the real-life implementations and skills. But how does one obtain these skills and practice since we are only college students who have never had a “real-world” experience in information technology.

The problem presented in the book is this: you are looking to join a team but do not have the experience desired. The team may not want to hire you at all because the risk of you not being able to contribute or you messing up and or breaking stuff is far too high. So what is the workaround for this? The book says to use your time wisely and to obtain some concrete skills. Not necessarily always software development related, even just some sort of skills such as social interaction and networking. This is important because it does not take a lot of knowledge to do these actions and they can make you seem much more invested in the team and marketable to other companies that are hiring. What needs to be done is to bridge the gap with the hiring managers because honestly they know you have little to no experience and they will have to take blind faith in you, hoping that you pull your weight on the team. But if nobody hires you because of your lack of experience, how exactly are you supposed to get experience to get a job? Practice gaining concrete skills, social skills, networking skills, any skills that do not require coding knowledge that will make hiring managers warm up to you more, and therefore more willing to take that leap of faith in hiring you. I relate directly to this chapter because this is where I currently find myself in life. I have been applying for full time jobs while finishing my last semester of college. Trying to “bridge the gap” to make a seamless transition from school to work is hard. Many employers see you’re still in school and flat our reject your application, and some will humor you with an interview but are very reserved because after all you still do not have a bachelor’s yet. After reading this chapter I feel more confident in my job searching and I will continue to search and apply for jobs.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Why Doctors Hate Their Computers” by Atul Gawande

 

 

On the readings, what I really found interesting was how doctors have to change the way they use to work to another way of working. That is to be using the computers. Which most were finding it very difficult. Imagine if I were a pilot and very good at it, and I was told the plane I have been flying for the past many years has to be updated with new software and I was told to fly the plane that has been updated with new software. At that moment, I will be very frustrated even though I am a very good pilot. And at this point you I will have to learn everything, get used to the new updates and if possible get someone to train me on how to use the plane.

So because of all the huddle I will go, I will prefer to use the old way than the new way even though the new way may help in the long run. In the same way why most doctors hate their computers. Not as if the computer will not help them in the long run but getting used to it becomes very difficult for them. And that’s in another way, giving them extra work to do.

From the reading the customers of the system were Seventy thousand employees of partners HealthCare. The reason is because from the same readings, it states that eighteen thousand other doctors, nurses, pharmacists, lab techs, administrators, etc. were going to adopt to the new software. The lessons from the implementation of the system applies to only the EMR (electronic Medical Record)

With my opinions on the reading, I believe for this kind of huddle most employees face, when it comes to computers, it is the luck of basic computer knowledge. As new things coming to the system which will help boost the company or the country, people in general have to get use with computer. If possible get the fundamentals of computer.

From the readings some of the things where not really clear not me. And also don’t disagree with what the writer wrote. All sounded on point. The reason why all are on point is because from my understanding and the things that I do hear. Most of the things that doctors face when it comes to computer are true.

With the topic, I do have a little problem with it. Because not all doctors really hate their computers. Actually, from what I have heard. Most scientists are lazy or maybe all of them. So if the computer can make their work easier, why will not they go through the a little mile to understand how the computer works so that their work will be easy for them. And also most doctors do know much about computers. So not all doctors hate the computer but some. I guess those who hate the computers, are the ones who don’t want to adopt to new changes and always want to stick to the old way.

I enjoy reading it and also got some useful tips on who the working environment at the health sectors deal with computer systems.

 

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

Why Doctors Hate Their Computers

My reaction to the reading of “Why Doctors Hate their Computers” is that while the program implemented by Epic to try to help streamline the process for doctors, it only made it harder for the doctors, more time consuming, and less revealing about the state of the patients themselves. Overall, the computer systems seemed to make the lives of the doctors, much harder rather then simplifying and streamlining their work. An example of this is when Epic arranged meetings between doctors and administrative staff, and in doing so added more fields to the program to help make the staff’s job easier. In trying to make the job easier for the staff though, it created more work for doctors with questions that previously were an afterthought were now required fields to finish the form for that patient. Another issue that was highlighted in the article was by the author talking to “Susan Sadoughi”, which she highlights the problems with each patient’s “problem list”. While previously this could be used by the doctors to know what to expect when seeing a patient. However after the installation of the medical programs, anyone in the organization could modify these problem lists, and worse there was no conformity amongst those making the changes. “Three people will list the same diagnosis three different ways” is not very helpful to the doctors trying to make the decisions that will help people’s lives. Another problem that I see in this system by Epic is the “stay in your lane” mentality in which ways that assistants would be able to help doctors was removed. For minor things that the assistants were taking care of there should of been cross-training of some sort to help reduce the high workload of the doctor in comparison to the already relatively light workload of the assistant. Despite all of these hardships on the doctors, the real users of this program was not just the doctors but the patients themselves. This program, while it was meant to help the doctors in their job, was really meant to make sure patients had a place to check what medication to use, when their next checkup was, reminders to seek treatment for cancer patients, etc, etc.. While I do not agree with the hardships that are being put on the doctors, I do agree with the sentiment of the man who had this system implement, Gregg Meyer, when he stated, “If computers causes doctors some annoying but improves patient convenience and saves lives isn’t it time we all got on board?”. This hospital system was not the only one affected by technological advances, with the author’s example of the construction supervisor, who also faced almost all of the same problems that doctors faced with their computer systems in his own field. Ultimately I feel that these incorporated systems can cause major headaches to those who have to use them. However, if they are designed properly with the focus on the job itself, simplicity, and no extra ancillary information, then these programs can be massively beneficial. It is when there are too many inputs from too many sources asking for too much out of the program that the true problems with these systems come around.

From the blog CS@Worcester – James' Blog by jdenesha 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.

“The Long Road”

In the third chapter “Walking the Long Road”, Dave have a bunch of certificates from his education. Then he starts connect to broader developer, he discover that he had barely scratched the surface of what it meant to be a great software developer. He inspired by the power of these hackers’ abilities. He threw himself into side projects and began to read anything he could get his hands on. The more Dave learned, the more he recognized how far he had to go. This is what I image I will be going though once I get into the work force. I am looking for the motivation to learn and see great things.

Speaking of work force, this is what everyone facing once they are doing job for money. We aspire to become a master software craftsman, yet your aspiration conflicts with what people expect from you. Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills. Everyone have their own road, that why we can not follow the successes step by step. I do believe the shorter road you take, the sooner it will be end road. I am agreeing with imagine my own long-term road. What step we are going to take, what experiences we want to try. We don’t want in the future to look back and wish we could take different road. This is always conflict between job and money, they are connected but also affect each other negatively. We are doing what we love but we also want to be successful. On our road of career, sometimes money and promotion could get you turn to different road. Maybe the road that you weren’t to take, this is difficult decision we will face at some point. I agreed with the chapter, no matter which road are we will take. Make sure that’s the road for long term and keep doing what we love.

From the blog CS@Worcester – Nhat's Blog by Nhat Truong Le and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Be the Worst

Consider yourself in the situation where you’ve joined a company, spent some time there, and learned quite a bit. You’ve climbed the craftsmanship ladder and others recognize your work as that of high quality, maybe even some of the best amongst the developers you work alongside. Your hard work has paid off and you’re a legitimately good developer. This is exactly what the pattern Be the Worst from Chapter 4 focuses on.

The problem with reaching this status is that you’re may likely find yourself at the pinnacle of growth in your work environment. Everyone turns to you for learning opportunities, and you’ve definitively established yourself as a leader in your workspace. However, you’ve found yourself unable to absorb information from your professional environment like you used to. Your rate of learning has stalled, and you’re no longer finding yourself continually developing and expanding your skillset.

The solution is something we’ve all heard before — surround yourself with those more skilled than you. Do so constantly. When you find yourself feeling like your learning has stalled, it may be time to locate another team whose skills outmatch your own (or at least, are in some kind of different field that you have lesser experience with.) Not only this, but keeping yourself in the ‘bottom-tier’ of your coworkers will “unlock” other patterns, which will help you keep yourself in the apprenticeship mindset. This is key because it ensures that, if you’re motivated, you’ll have continuous growth. Now, don’t get this pattern confused — Your goal is not to stay the worst on your team. It is to climb the rungs of the ladder until you’re an absolute coding machine, equipped with a host of skills that you’ve picked up from the time you’ve spent chasing craftsmanship. Then, once you’re at the top of the ladder, find another to climb all over again. Eventually, you’ll find yourself to be a developer skilled enough to guide others through the same process.

What action can you take to push yourself towards this goal? I may have been implying that it’s wise to up and leave every group that is slowing you down, but that’s not entirely what I meant. There’s no reason to forgo professional relationships in the search of career development if you’re happy where you work. Instead, search for elite teams across the world (via the internet) who you can be a part of. Get involved in more communities, different projects, etc. Staying in communities seeking growth will encourage you to do the same.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Software Capstone: Computers in Healthcare

We have a few required readings for our course this semester, one reading being “Why Doctors Hate Their Computers” by Atul Gawande (November 12, 2018 issue of The New Yorker.)

One interesting complaint in the article is that with some of the new technology being implemented, extra jobs (like scribes, who would take notes for the doctor while the doctor worked with their patients) were being implemented (so instead of resources being saved by using new software, they needed to hire more people to account for the new software’s complexity.)

Doctors who had gotten used to an older system were finding the newer system harder to adapt to, to use more efficiently, and to save time with. Newer doctors could pick up the new architecture of the software relatively quickly, and non-medically inclined scribes could work the system with ease. There was a defined split between new users to the system who had prior experience with another system, and those who had approached the new software with fresh eyes.

I think that this system was targeted towards improving the patients experience at each hospital the system is implemented in. The doctors have been left to learn a more complex way of going about patient care with the desired result being that information is more accurate and up to date for each patient.

I personally believe that hospitals should invest more in training veteran doctors to use the newer systems, and in improving ease of use for those involved with the system each day. The biggest issue in my view is that time is wasted when the system is too confusing for a doctor to be able to efficiently operate; the patients experience is dampened when the doctors cannot work at the speed they used to be able to.

From the blog CS@Worcester – Sean Raleigh's CS Blog by sraleigh62 and used with permission of the author. All other rights reserved by the author.

Why Doctors Hate Their Computers Blog

          I found the article, “Why Doctors Hate Their Computers”, very interesting and though-provoking for a variety of reasons. The main reason I found this article interesting was because of all the frustration these EMRs can cause doctors and pile extra work on top of them. It was interesting to see how these systems affect different parts of the medical field such as surgeons and emergency care. The complex tensions from the extra typing and learning curve really makes doctors’ lives harder rather than easier. Many of the doctors within the article stated that they would start to bring work home, something they usually never did. This was due to the extensive learning curve of the system at first but even as time went on, many doctors that mastered the system still had a large workload. Another tension is the fact that nurses and assistants cannot take some of the workload for the doctors since they aren’t authorized to use the system or have had any extensive training on it. They must sit on their thumbs while the doctors get swamped with work. This leads to a harder personal life for doctors which can lead to worse mental health as the article stated. I was very surprised to see that many doctors were going through depression because of these system implementations and continued to have issues with their work and personal life balancing. It seems that the real customer of system was the patients to help them stay informed of their health records through online electronic means. It was a way to allow remote communication between doctors and patients so that the patient could have an easier time accessing their health records and update from their doctor. The lessons from this system implementation don’t only apply to EMRs but rather to many applications that hold a complexity that only continues to grow and become more brittle. The idea of software not being flexible causes a mass disturbance for those that need to make changes on the go which is especially prevalent in medicine but can be applied to various other industries such as construction. The reading gave me better insight and allowed me to develop a better opinion on the subject matter by explaining the positive and negatives of the system. After reading about how the frustrating interface caused doctors more work and tension, I can understand that organization must be important for all users of a program. The system was designed for the patients, but it should also have been easier to use for the doctors by making their lives simpler than where it was in the article. I will keep all customers in mind when creating software so as to make sure that the scope of the programs can be understood by every user. I agreed with the reading because I personally understand how systems can be aggravating to deal with from a backdoor perspective. It makes sense how frustrating a new system can be and how much effort it takes to get acquainted with it. I thoroughly enjoyed reading this article and found it insightful to my software development practices.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.