Your First Programming Language

Hi everybody and welcome to another blog post for CS 448 Individual Apprenticeship Patterns. Today topic is going to be about one of the patterns in Individual apprenticeship patterns which is your first language. I learned a lot from this pattern like obtaining my first job will depend on my proficiency in a specific programming language. I started after reading this pattern to focus on one specific programming language which is swift. I chose this language because I been reading other articles and pattern that say to work on something, I going to be passionate about which is creating a fun application. The pattern advised me to become fluent in it, so I been coding problems and reading more about the language daily. I also feel more comfortable after reading this pattern when asking for help. I have always been too embarrassed in the past to ask for help because I felt like I should know how to solve the problem but now I will try to be more open with some of my programming errors but only if I desperately need it. The pattern talks about playing around in an environment with topics that I’m unfamiliar with which I totally agree with. XCode has an IDE call playground where I been just messing around with unfamiliar features and language. I have also been reading more about a testing framework after reading this pattern. I found this pattern helpful because I realize that there are many ways, I can improve in my programming skills. I learned that my first language is very important as a beginner programmer because the first language is going to be my building block for my career and foundation for future language that I will soon be learning. I think after reading this pattern your first language I really change the way I work and code. I have been more motivated to get a strong understand of the language I decided to invest in the most. I found this pattern interesting and I never knew the importance of the first language before because I been using every language and wasn’t focusing on a specific language which causes me to be decent in all of them instead of being proficient in one. All in all, this pattern was very inspiring.

From the blog CS@Worcester – Phan's CS by phancs and used with permission of the author. All other rights reserved by the author.

Journey into “Why Doctors Hate Their Computer”

On this Software Development Capstone journey part of this week assignment is to read an article about  “Why Doctors Hate Their Computers” by Atul Gawande, from the November 12, 2018 issue of The New Yorker. For this blog rather than writing a summary of what I just read with my reaction of it I would be doing a Q&A that was assigned by my professor. If you are interested in the story click on the link above to read the article.

What did you find interesting, useful, thought-provoking about the reading?

I found the idea that the Electronic Medical Record System should be more adaptive interesting. Meaning it should have the ability for mutation and selection. That way it could weed out bad ideas or practices. This is useful and thought-provoking because when developing software I should try to allowing my software to be able to some how have the ability of selection and not just mutation. I also, found what Greg Meyer said “If computerization causes doctors some annoyance but improves patient convenience and saves lives, Meyer is arguing, isn’t it time we all got on board?”, what he said was interesting, useful and thought-provoking. I another thing I found interesting a thought-provoking was the fact that doctors would spend a lot time behind a computer screen rather than with the patients.

What tensions caused the system to make doctors’ lives harder, rather than easier?

The system had a lot of things that made lives for doctors’ harder rather than easier. It did this by making simple things such as “viewing test results” difficult. This was done whenever searching for one thing a column of other identical terms would be showed on a tab to the left of the screen. Another thing was, the system tools made entering information more difficult and often made doctors irritable. The doctors’ found these tools requirement to be a nuances and time-consuming. The system also, increase work for physician causing them to spend extra time doing computer work. This system made finding patient history difficult. Once patient history was found there were often times where there was a lot of useless reading to do… since, some doctors would just copy and paste information. When it came to diagnoses the system would allow doctors to give patients the same diagnoses with different names. The problem list would be redundant and useless. The relative details would not often be posted. A lot of the things the system provided was either useless, pointless, and time-wasting causing doctors’ lives to be a lot harder.

Who do you feel was the real customer for the system? Why?

In a way I feel that the real customer for the system was the patients. The reason being that the system made it easier for the patient to view their own charts and receive better care. However, the system in some ways made work more difficult and more time-consuming for the medical personal such as the physician.

Do the lessons from the implementation of this system apply to only Electronic Medical Record systems?

The lessons from the implementation of the system does not apply only to Electronic Medical Record systems. It apply to many other type of system.

Has the reading caused you to change your opinion, the way you think about the topic, or how you work?

This topic did not really changed my opinion or the way I think about this topic. The only thing I might had changed would be the way I work. Since, I would try to make sure that when ever developing a software it must be efficient for everyone using it.

Do you disagree with something in the reading? And why?

There is honestly nothing disagreeable about this reading. The system talked about in this article has its flaws but it is outweighed by its advantages.

This article was pretty informing and pointed out problems that I honestly was not aware of. This sums up My reaction the article “Why Doctors Hate Their Computers” by Atul Gawande. Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

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.

Reflecting on “Apprenticeship Patterns” – Breakable Toys

When I was reading each of the introductions of the “Apprenticeship Patterns” book, the term “breakable toys” came up a couple of times. I wasn’t sure what the authors were trying to describe, so the Breakable Toys pattern was the next that I read. As it turns out, this pattern resonates deeply with me and my workstyle.

Breakable toys are essentially more private projects or spaces where practice is encouraged, without being concerned about the potential consequences of failing. For an apprentice who works in a high-stakes environment with no room for failure, this pattern is key to better understanding and learning about the tools used in their workplace. It removes the pressure of having to consistently be correct when developing software, which would be daunting not just for apprentices, but also for those with more experience. Breakable toys are great for anybody who simply wants a safe spot to work on projects away from their work environment.

Whenever I am writing code, or really doing anything in general, I am always nervous about failure. In conjunction with my previous post (which touches upon the apprenticeship pattern called Be the Worst), I also get intimidated when working with those with more experience, which in turn causes me to get worried about causing any failures when working with such individuals. For me, implementing a Breakable Toy would be great so that I could comfortably learn at my own pace, without fear of messing up in front of the development team and further affecting my ever-present impostor syndrome. I already have started various personal projects and courses, which I can now view as Breakable Toys of sorts.

Reading about this pattern didn’t really change the way I’m thinking about development and my apprenticeship process. Rather, it helped me realize that the kinds of activities that I’m already taking part in (like coding projects on my own or working my way through courses/textbooks outside of my schoolwork) are great steps that I should be taking in order to fine-tune my skills while also embracing any failures that may arise. By encountering these failures now, I can also better prepare for being a part of a development environment with less room for error.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Do Doctors Hate Their Computers?

Atul Gawande talks in great detail about his experience with Epic and the experience of others that he has talked with. Atul if a surgeon so his direct experience would differ from someone like Sadoughi who is a primary care doctor. He went on to explain what epic was, and that was a system that… Continue Reading →

From the blog CS@Worcester – Computing Finn by computingfinn and used with permission of the author. All other rights reserved by the author.

“Why Doctors Hate Their Computers”

For our capstone class, 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 – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Having Concrete Skills

For this week, I have decided to read “Concrete Skills” pattern from the Apprentice Patterns by Adevele Oshineye and Dave Hoover. I have chosen this one since it is a good refresher for understanding that knowledge known is not the same. I believe this will help me in making so that I can be sure to give more demonstration than telling by just writing it out.

This pattern starts with the context of seeking out a role in a group of talented people that will provide better learning opportunities than currently. The problem is that the team, when asked, they can not risk of bringing someone that would not be able to contribute for the intended workload. There is also when thinking further, the possibility of not being able to do even the simplest task when asked. The solution to that problem is concrete skills, acquiring and maintaining them. With these skills, demonstrating and having them will increase the possibility of being trustworthy and be able to reach the goals. Eventually, there will be less dependent on these set of skills as the possibilities increase in being hired for the jobs intended.

From this pattern, what I found useful is the listing for concrete skills as an example to give the point of giving trust to the employer. As we try to give a good impression and trust for the likes of employers, we want to be sure that we at least have a clear understanding and demonstration of the basic things to do like JavaScript and the standard libraries by choice for computing jobs. Skills may require more thoughts to give an even better impression than intended, but it does answer questions to which the employer may ask. This pattern has changed my way of thinking in my profession. As I read the short pattern, it has become clear to me that I should not only directly say as intended but also if needed, demonstrate what I can do even if it is the basic thing. For this pattern overall, there is nothing I don’t disagree upon and this is because the pattern was able to give good perspectives of knowing what to do with this concept.

Based on the content of this pattern, I will say this is a simple but effective one. This pattern has showed good examples of the real-life scenarios. It allows me to be aware in the future of demonstrating than telling by just paper. For practice, I will show some technical work to give good impressions.

 

Link to the pattern: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02s04.html

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

IndividualApprenticeship Patterns – Practice, Practice, Practice

Practice as they say, makes one perfect. Practice is the act of rehearsing a behavior over and over for the purpose of improving on it to be perfect. From the readings, i notice the statement which says “Your grandmother may have told you that practice makes perfect. She was wrong. In fact, practice makes permanent. ” which i think was quoted by George Leonard. Actually, i think he is getting the whole thing wrong. Practice actually make you perfect and also makes your permanent. Whether you are learning the good thing or the bad thing, you will eventually be very good at it, leading to perfection.

I also learned by practicing, you do not have to do it alone. Just by being at work or under a master, you will be learning a lot. By learning you are practicing at the same time. You should also be making sure you are learning the best stuff, since what you are learning, can be come permanent. You don’t want to learn being good at something that will not profit you in the long run. That will be a waste of time and resources. In order ways while you are searching for a good place to work or a mentor, you should make sure you picked the right person(s).

Also while getting used to things, make sure you are learning other new skill. You don’t get stuck on one thing. You need to know more, and by doing that, you will have to learn new skill when ever you thing are okay with others. Pick harder stuff or projects to practice on. Always check you strength, if too easy move to harder ones.

This pattern has not caused me to change the way i viewed practicing. But it has showed me there are ways i can practice in an excellent way or a better way.  And also types of practicing i can take. Also to my understanding, practicing with peers is more an effective way to be better at your skills. I really enjoyed this pattern and i know it will help me now and very well in the future.

 

 

 

 

 

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

Do You Hate Your Computer Too?

Sams Ships (3)Apparently doctors hate their computers, according to an article titled Why Doctors Hate Their Computers by Atul Gawande. Gawande started out the article by mentioning Epic, a company a lot of people know of because it is a leading provider of software for the healthcare industry. It’s funny because just the other day, a classmate who will not be named groaned when he heard Epic being mentioned by someone, as he works in a healthcare center.

I found the reading was interesting because I have no intentions of becoming a medical doctor one day but was able to hear about how it is being one while interacting with technology that exists today.

It seems like the tension of logging everything caused the system to make doctors’ lives harder instead of easier; this was noticeable when Sadoughi was talking about how she had to look over all notes from different doctors including herself per patient. Instead of being able to just see what is going on right away; it would take up time to gather all information and even then it was not always helpful because some notes were different than others and became dated. And then work-life balance had to be thrown off a little because people had to spend extra time, up to hours after-hours to catch up with the system and review things from the day.

The real customer for the system seemed to be patients because they have some benefits from using the system like logging when to take medications or see how they are doing. Doctors are also able to monitor how they are doing and communicate with them by being pinged.

The lessons from this system do not only apply to Electronic Medical Record systems; they also apply to working in life because burnout can happen to anyone in the workforce. I thought it was interesting how one of the ways doctors were trying to save time and prevent burnout from technology was by hiring in-hospital scribes or even virtual scribes when necessary.

The reading has caused me to changing the way I think I will work based on if I ever end up creating software that affects people’s healthcare by considering how much time it takes to interact with it, no matter how “cool” or “innovative” it may be. In terms of the topic itself, the reading has caused me to think more about software that has altered people’s professions as a whole; which I thought of before but never this deeply.

I do not disagree with anything in the reading for now as I do not personally know what it is like to work in a profession that is not traditionally non-technical and then gets transformed into something that relies on it.

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Doctors Don’t Like Their Computer’s Huh?

Good day again my fellow readers! Today, I have read (well more like listened but I digress) an article titled, “Why Doctors Hate Their Computers”, from the New Yorker. It tells the findings of a Massachusetts doctor and his experiences when his employing hospital sends him to, “16 hours of mandatory computer training,” to learn the new electronic medical record system, EPIC. This experience then kicks off a search for the reason why these systems make doctors hate them, and the effects it has on those doctors.

The hospital was switching from proprietary software to the EPIC software and as the author has used the system, it has worn him out. To make a long article short, EPIC had added many more steps, clicks, and time to processes that had in the past, gone much quicker. The author mentioned that in the first month of the EPIC rollout in the hospital the IT Helpdesk logged 27,000 tickets. Working in an IT department currently, I may have done a spit-take when I heard this. The author also mentioned that because of these new systems, for every hour of patient interaction there are two hours of paperwork that has to be entered in the system. There was also a Mayo Clinic study that discovered a link between the burnout of doctors and the amount of screentime that they are subjected to. Bad software is literally driving doctors out of their career. This really surprised me. All of us have come up against some bad software design before, but I would never guess that bad software would cause someone to quit their career. As the article went on, the writer revealed that the software creators of EPIC tailor the software to the hospital utilizing it. For his hospital, meetings were held where both doctors and administrators were invited. I immediately thought that the culprit here was the administrators. The folks higher up, or in a different department got their hands in the part and got their interests, prioritized over the doctor’s ones. Then later in the article, he talked to the chief clinical officer at Partner’s Healthcare, who turned the argument on its head. The software is not for the doctors or the administration. It’s for the patient as more patients look at their records and visit notes and want more understanding. This gave me pause as I myself take advantage of these features as a patient. Having access to all this information is very comforting. I had to mull this over for a bit but I came to the conclusion that the patient should be the main customer in this scenario. The whole point of a hospital is to serve the patient and with how care is extending beyond the hospital, the software is going to reflect this. For the Software Capstone, I will be working with AMPATH on their EMR for charity work in Africa. In that scenario, patient interaction will stay primarily in the hospital. In such a scenario I would say that the software should be directed towards the doctor. This reasoning is because the major usability that the patient will get out of it, is not an option for the patient due to their situation. We will definitely leave the option to shift the priority to the patient but, at the moment it appears that the doctors are the current priority in this situation.

This was definitely an interesting article and the next time I visit my doctor I do have an inclination to ask what EMR that they use and how they “like” it.

Until next time readers!

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

Why Doctors Hate Their Computers Response

A lot of the times in the office, people can get easily frustrated with their tech. This article talks about how there seems to be some sort of disconnect between the technologies and the doctors. To start off, when a software is developed for a certain field, there are certain expectations and requirements that should be met depending on what the service is for. if you are delivering a software for a food business, you should expect it to handle some sort of client interaction along with employee interaction. This also can translate to mass scales where more and more people are using it. When a lot of people are using the same software, there should be a type of initiative to make it simple yet effective to use. If the software that is being developed for a specific purpose isn’t developed correctly or with those things in mind, it can sometimes be detrimental to that business’s practices. In this case, it was a matter of updating a lot of records and technology to keep the systems “relevant”.

In the case of a hospital system, the records are computerized and the new system that was being put in place would be able to handle a lot more. This is the reason why the upgrade was good. The new system would be able to deliver a single platform for recording and communicating medical observations, sending prescriptions to a patient’s pharmacy, ordering tests and scans, viewing results, scheduling surgery, and sending insurance bills. However, with these new systems seem to come a lot of overhead for the people using it. There were quite a few tensions that actually made it more difficult for doctors to get their jobs done. One of these tensions was between the doctors and administrative staff. Often times they disagree on what should and should not be included in the software. Sometimes the staff said adding certain procedures would be more time consuming. Certain fields that doctors didn’t have to fill out before were now being required due to administration simply telling them that they had to be done.

I feel as though the real customer in this situation seems to be the administration. Whenever a new system is implanted, hospitals often have to schedule less appointments just to accommodate for training of the new system. This puts, not only the patients, but doctors and other faculty way behind. From the article, it states that in the first five weeks of a new 1.6 billion dollar system upgrade, there were about twenty-seven thousand help desk tickets were just simple how to questions about the system. The lessons from this implementation don’t only apply to the Electronic Medical Records systems, but other systems dealing with these same mass software upgrades for facilities similar to hospitals. This reading has changed the way I think about the topic because although upgrading something to make it current, doesn’t always necessarily mean it won’t add additional overhead. I agree with the fact that upgrading systems can be important, especially when dealing with thousands of medical records because you want to keep things secure. But at the same time it is important to understand that there should be more efficient ways of training with these software to make them more accessible and understandable for the people using them.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.