Unleash Your Enthusiasm

For this week’s individual apprenticeship pattern, I chose Unleash Your Enthusiasm. This pattern talks about how to handle the enthusiasm you have for work. As a software developer, you will most likely work as part of a team. Most teams are not as passionate or overly enthusiastic about technologies anymore. Most of them are focused on delivering the next project and trying to improve aspects of the development life cycle that are causing them hindrances. That is why sometimes, unleashing your enthusiasm can get people rolling their eyes on you. Some teams are particularly not welcoming of newcomers. You should be careful when unleashing your enthusiasm. It is best to observe the team first.

I found it interesting that unleashing your enthusiasm is in the pattern. I was never really an enthusiastic person, I am more on the analyze first before I do anything side when it comes to enthusiasm. I am actually envious of enthusiastic people since they just speak their minds out and seem to not care what would happen. I always thought that being an enthusiastic person was really great but after reading this pattern it makes sense that you should be careful when unleashing your enthusiasm. Some people do not want to get bothered while working and can get easily annoyed by people asking them questions all the time. But there are also the opposites who loves hearing questions and giving you advice on what to do.

This pattern has caused me to think about ways to approach different people in the team. I think most teams have a diversity of behaviors and some would be welcoming than the other. I think that trying to get the feel for your team before you unleash your enthusiasm would be the best solution to this problem.

I totally agree with this pattern. I think it is good to know that not everybody is willing to listen to you and that you should approach the team carefully. I think you should still be enthusiastic, just be mindful of others. This pattern would definitely help anyone, not just software developers in their life.

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

Why Doctors Hate Their Computers

I thought that the article Why Doctors Hate Their Computers was incredibly interesting and eye-opening. Working in the software development industry, it is easy to think that software can easily replace many systems that are in use across a wide variety of industries. But as this article shows, complex software systems are not always a perfect solution. For example, the Epic electronic medical record system ended up creating more work for doctors because the software made the note-taking process longer and more redundant. While the system did increase patient benefits, those working in the medical field faced negative consequences that created more work, stifled innovation, and decreased face-to-face interaction with patients.

I thought that the most interesting part of this article was the idea that adaptation requires mutation and selection. The pre-computer systems of medical practice were all mutation and no selection, while computerization is all selection and no mutation. This analogy is a very succinct way of describing the advantages and disadvantages of using software systems. I think that software development companies and those in the medical field should work closer together to develop systems that are more customizable and less restrictive on doctors.

I think that the real customer for the system is the hospital administration. While the system did lead to better treatment for patients, which is obviously a good thing, it came at a large cost for the actual doctors. The system was developed mainly with input from the administration, so the focus was on decreasing costs and improving patient outcomes while the opinions of the doctors was ignored. I think that they should have worked more closely with doctors because they are the ones who actually have to use the software every day.

The lessons from the implementation of the Epic system apply everywhere. When developing any type of software, one of the most important goals should be usability. If a software program is not intuitive and easy to use, rather than being a powerful tool it becomes more of a burden. It is always relevant to take input from the actual people who will be using the software while it is being developed. As seen with the Epic system, if this is not done implementation of the software can have opposite of the desired outcomes.

Reading this article reinforced the idea that usability should be a primary goal when developing software. It is important to have other people use the software you are developing and take input from them. I think this article was very well-written. The author backed up his points well and I don’t disagree with anything in the reading. Overall I’m glad I read this article as it offered an interesting perspective and was both informative and entertaining to read.

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

Why Doctors Hate Their Computers

This blog is about the article “Why Doctors Hate Their Computers” in the New Yorker by Atul Gawande. The article talks about the complications the doctors encountered after upgrading the electronic medical record system they used to Epic.

There were some tensions that caused the system to make doctors’ lives harder than easier. It became more political than technical. Staff and doctors had different views on what should be included. Now they added more questions that are “field required” that doctors used to skip that added more time to finish. Another tension was that different doctors can modify a patients profile. Three people will list the same diagnostic in different ways. Some will just list what is required just so the system does not alert them, some are not useful to the doctors who need to know a specific diagnosis.

I agree with Gregg Meyer. He said that “But we think of this as a system for us and it’s not,”  “It is for the patients.” After reading the article, it really seems like it was not made for doctors but for the patients. It was made in a way that every patient should have a record on every required field which made it harder for the doctors to do their work. The system was also used so that patients can log into it to look up their lab results, remind them of the medications they are supposed to take and read the doctors note to the patients. There are more patients than doctors so I think Epic was made so that the patients can easily access it. 

 

This article was long but it was interesting to read. As someone who is trying to work on the field of software development, I found it interesting how important it was to know the customers we are building it for. I think for us developers, it is easy to make a system that we could understand and use relatively easy, but without the perspective of the end user or the real customer for these systems, it might not be the same scenario for them. There are still a lot of people who are not tech savvy. This lesson of implementation of this system does not only apply to Electronic Medical records systems. For example, there is a show called Silicon Valley, where they made this software for a middle-out compression solution. It was the talk of the town. It was the fastest algorithm at the time. The developer asked his friends (other developers) to look at the finished product, and they all liked it. Then the time came when they were trying to release the software. They had ordinary people testing the software and they couldn’t understand how to use it and what it does. They had to teach them for weeks and there were only a couple testers who learned from it. Moral of the story was the same in the article, for us developers, we have to pretend that we do not know anything about our system sometimes and see if it is friendly enough for others.

From the blog cs-wsu – Computer Science by csrenz 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.

B3: Be The Worst

          The “Be The Worst” pattern is described as a way be able to keep learning after you begin to hit a roadblock and your rate of learning has plateaued. The book explains that the solution to this problem is to make sure you are around developers who are better than you and can help you identify your weaknesses by comparison. It removes the sense of comfort that builds up once an individual performs better and makes you recover faster from mistakes with more competent team members at your side. The learning process can become smoother through this pattern and allows the individual a better sense of understanding of their skills before and after joining the team. The goal is to not remain the weakest team member and to be constantly working hard to make sure that you can surpass your team members. This can lead to sudden risks of dragging the team down if you cannot catch up quickly enough and affect how you view yourself. The motivation of an individual is tested here as well how much stress one can endure and to push through for the eventual endgame.

          I found that this pattern is very relatable to me which in turn could be useful to apply into my daily life. I find it interesting how much of the situations the book brought up were so similar to problems I’ve faced in the past in terms of moving my skills up to the net level. I found that my learning had plateaued as well and didn’t really understand how to deal with it. The idea of removing my sense of comfort form my first language is thought-provoking because it seems to be very difficult for me to let go of my first language and move on to more difficult concepts. I have always loved learning Java, but this pattern as shown me to look past a single language and continue to grow with the industry. I still am hesitant to let go of my coding habits from Java but realize that I have to make this change immediately. I should surround myself with those that are better than me and try to survive in that environment to evolve my understanding of code at a faster rate. I agree with this pattern completely after fully understanding how it works and how to better my skills through my environment.

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

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.