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.

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.

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.

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.

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.

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.

Have you ever heard of the Single Responsibility Principle? What does it sound like when it comes to mind? To me it kind of sounds like an object is tasked to do one thing.

In Jon Reid’s “Single responsibility Principle: Is it a fundamental mistake?”, he talks about the different problems that arises when applying the SRP. He starts off explaining that in order to apply the principle, we must keep subdividing until the class cannot be subdivided any further. That task sounds like a nightmare right? It gets worse. He goes on talking about classes and an important concept called “Cohesion”. Simply put, cohesion expresses how closely related parts of your code are with one another. For example the more each method uses the same instance variable the more cohesive the class is therefore that class must be narrowed down according to Reid. There is a such thing however as extracting too much from classes but he doesn’t really go into detail describing when you know you’ve narrowed down too far he only states you’ll know when you’re there which doesn’t help much.

I thought this blog was sort of confusing because he didn’t go into detail about how to not make the mistake about breaking down your code too far; I guess he just wants us to learn through trial and error which makes sense over time. I don’t think I will try to change my way of coding because the way he described SRP kind of made me want to sway away from the idea. There just seems to be too much room for error in my opinion. Yes I agree it is good to narrow down your code but you do run into the problems he mentioned.

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.