During this sprint there was not much for me and my team to get done other then getting the program to be able to work on all of our computers. I feel as part of this sprint was also combined with the first sprint, hence why we still trying to get the program to still work. At first there were several issues for all of us, with all of us getting a massive amount of errors when we first tried to “build” the program. It was during this sprint though that I was able to educate myself further on things that I had started to learn last semester with Angular design and testing of code. One of these errors that this program presented when we were first trying to get it to start was a problem of “circular dependency” which was one problem my program was having building. After looking for sources on this and learning about it I found it was essentially because in the files of the program, multiple files are depending on each other but had not been imported/exported properly(source). Another problem that my team and I had thought could be the problem for some people’s program not building was their version of NPM, or rather the dependencies they had installed with their current version. While everyone else in my group was on nearly the most recent version of NPM, I was still running on version 6.4.1. Yet I did not have issues with NPM because I believe I had installed the correct one with correct dependencies in the previous semester for CS-343. I had issues that my team couldnt help with because we were not experiencing any of those issues from a mac. I feel that this being the first time I had worked in a “scrum” type environment was interesting, having only just learned it in CS-348. Despite all being individually working on getting the program working, as a class we all worked together to try and solve each others problems. When one person would find a possible fix to an issue they would share it, and then through the collective effort someone would find a fix. Going into the next sprint though, something I will be looking for more is a better understanding of the goal of the sprint. This past sprint felt very scattered still with some people not being able to get their program working still at the end of the sprint.
For this weeks blog post I will be looking at the pattern called “The Deep End”. The context behind this one is that taking small safe steps leaves you unsatisfied and you are beginning to fear that you may be in a rut. Instead of diligence that could attain the next level you are in a rut where bland competence eventually will decay into mediocrity. The problem with this is that you need to grow your skills, confidence and portfolio of successful work. Challenging yourself with bigger things like bigger projects, larger teams and more difficult and complex tasks, new workplaces and more. This will again help you grow as a developer instead of settling for a rut. The solution to this is to jump in at the deep end, taking it head on almost. Waiting until you are “ready” can turn into a disaster or a pattern of never doing anything. When offered a higher profile role or a more difficult problem grab onto it with both hands take it head on. Personal growth will only occur if you are doing something out of your comfort zone and doing things that stretch your boundaries. This of course will have its risks without a doubt. If you get it wrong and way in over your head you could drown. But thankfully in the business there are many places where you can take risks without destroying your career if you were to fail. These risks are opportunities that will help you grow. It means taking a foreign assignment when its offered, even if the possibility of failure is staring in your face. Acting on this will be extremely beneficial to you when in a rut. Thinking of the biggest projects you have worked on and then writing down the answers to these questions pertaining to the difficulty of other projects is a good way to start. Using metrics to measure every project, in a sense, of your own projects. I find this pattern to be very on par with the be the worst mentality. In a sense you are putting yourself in an environment that may or may not cause you to fail miserably but if you succeed you will grow immensely.
My blog post this week will be on the chapter “Rubbing Elbows” of Apprenticeship Patterns, in which the reader is encouraged to seek out working with another fellow software developer. The basic thought behind this is that if you develop software alone you can reach points where your learning can stagnate, and cooperative work can get you to learn things in new ways. One very important point that the author made was the aspect of “micro-techniques” (small ways one developer has found to handle certain problems or situations) and how important learning them from other developers can be. This is important to me, and should be to others, because I feel I had to figure out how important those “micro-techniques” are first hand. When I first started working with software I was very independent, not wanting other people’s help. But, the longer that I have worked with software, and just worked in general, I have found out how important it is to see problems and fixes for them from other people’s perspectives. Towards the end of this pattern, the author again points out this importance of being able to see problems from others points of view, even if in the end you do not agree with another person’s perspective. One thing that I found interesting, and wound up doing more research into, was the idea of pair programming. The idea behind this programming technique is to have two programmers work together on one terminal with one programmer writing the code, while the other reviews each line written. This approach of matching a journeyman programmer with an apprentice I can see being very effective way for both the apprentice to gain critical knowledge and for the journeyman to progress further towards becoming a master by passing on his knowledge. One downside to implementing this technique with pair programming that the author points out is that the apprentice may often feel lost, but I feel this can be combined with another one of the patterns(Expose your Ignorance). In essence I feel that as the apprentice in this case, you have to be humble, acknowledge you won’t know much, and to ask a LOT of questions. Don’t ask just one person these questions too, but ask other’s the same questions to see their perspective on the same problems.
This week, we were asked to read “Why Doctors Hate Their Computers“, and article written by Atul Gawande. It was a wonderfully written article that gave insight into the period of time where hospitals adopted the new Epic software system, and how they suffered through the process. It gave different outlooks on the computerization of enterprises, the pros and cons, and the contrast between human-centric work environments (adaptable ones) and computer-centric work environments. Adopting this technological overhaul was a major step in healthcare that hospitals across the nation decided to undertake. It came with training for nearly all employees, the hiring of technical staff, policy and routine changes for care providers, and a tremendous amount of headache.
The article dove into statistics of career satisfaction that healthcare providers in different specializations report. On average, doctors spent about 2 hours on their computer for every patient-facing hour the spend in the clinic. There was correlation found between this and job dissatisfaction, and especially between time spent on the computer and burnout rate, as reported using the Maslach Burnout Inventory. Doctors in specialties such as Emergency Medicine, who spend large amount of their time logging information into computers, reported significantly higher rates of burnout and job dissatisfaction when compared to a specialty like Neurosurgeons, even when they spent significantly less time at work. With the overhaul of Epic, doctors had to spend even more time on their computers logging patient information, often after hours and at home. Patients were booked for double the time slots they had previously been booked for, effectively halving the amount of patients seen per day. Not only this, but in a study done by the University of Wisconsin, it was found that the average workday for doctors increased to around 11.5 hours. While reading, it was pretty concerning to think about how these people who are trying to take care of others are doing so on such extreme schedules.
It wasn’t just learning curves that seemed to make the job harder on doctors. The senior vice-president at Epic, Sumit Rana, called one issue “the Revenge of the Ancillaries.” Since Epic was a system that would be used in every position in the hierarchy of the hospital, there were often disagreements regarding what administrative staff wanted the software to do and what doctors wanted the software to do. Since doctors had been used to calling the shots (for the most part) regarding patient healthcare, having restrictions placed upon them was a difficult thing. Not only was there the tension of having to learn and implement a new software system into their daily routine, but there was also tension “politically” in their work environment due to administration.
So who was the real customer for the system? I think it is clear to say it was hospitals, and the technology from a sales perspective was aimed at ease of use for doctors and administrative staff. However, Gregg Meyer, the chief clinical officer at Partner’s Healthcare who oversaw the introduction of Epic, put it really well in my opinion. “‘…we think of this as a system for us, and it’s not’, he said. ‘It is for the patients.’” Meyer is convinced that it will improve over time. The Epic system is new and absolutely massive. In 10 or 15 years, national EMRs will be far better than they are even today. There will be many of the same issues, however there is a tremendous amount of benefit that comes from it. According to the article, “In the first year of the study, deaths actually increased 0.11 per cent for every new function added—an apparent cost of the digital learning curve. But after that deaths dropped 0.21 per cent a year for every function added.” A system that does that seems worth the headache in my eyes. I hadn’t at all considered this viewpoint before reading this article, and it made great sense to me.
I think there is a lot that can be learned from this article far past the domain of hospitals, EMR, or even software in healthcare. The article referenced “The Mythical Man-Month” by Frederick Brooks which I found pretty interesting. It dives into the human aspects of software engineering and working in a computerized workspace. The actual development environment and technology used within the workspace has changed, however things like the scaling of collaboration and teamwork in a project-based environment have remained largely the same. Within the book, Brooks coined something called Brooks’ Law, which states that “adding human resources to a late software project makes it later.” Clearly even back in 1975, they knew a thing or two about the complexity of introducing and launching software products on a large scale — and the implementation of Epic was another example of exactly that.
This pattern, “be the worst” to my understanding means, we should surround ourselves with people who are very clever or know more about the subject or field you are in.
From the readings under “be the worst ” which says “what do i do when my rate of learning has leveled off?” You have taken the time to learn something new, immersed yourself in the subject matter, practiced diligently for a period of time and look up and see that you are ahead of those around you. Now what? There are only so many books, blogs, and other resources you can learn from until you reach a point where you must learn new skills from other humans. We are social creatures, by nature. We rely on each other to survive and part of that survival involves learning from each other. It’s difficult to imagine a world where we all had to learn everything on our own and couldn’t benefit from the knowledge and insight of those around us. So for us be connected with the world we need to learn from others. And also the is a saying not everything that we know, we learn from each other and by that we grow. So the more we learn from other developers, there more we grow as a developer. We can look for people who know more than we do and learn from them. We can also be in a team were you a the least among them. Knowing you are the least, you tend to work harder to keep up with them and also you get to learn new skill from them too.
From the readings “weakest member of the team, you should be working harder than anyone else”. There are risks associated with this strategy. You will be the least effective developer or person around the team. This also means your contributions will not be sufficient whereby dragging the team down. Because of this situation, team members may not put up with you very long. So putting all these risks into consideration, if you are really determined to learn, you will have to strive harder. In other sense, the only choice for you to stay in the team is to learn harder. That also means extra work for you.
Apart from all the risk involve, being the worst is a great way to improve your effectiveness in a given subject area quickly
Reading this pattern has made me know that in my own world i may feel i know everything till it get out of my world to see if really know everything or not. which knowing everything will never be the case. We all learn from each other. And knowing this idea, I will have to surround with people who are more challenging or better that me. Through that i get to learn new skill and better my self.
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).
- 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.
- 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.
- 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.
- 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.
Welcome back to Dcanton’s Blog, today I will going over my takeaways from the Apprenticeship Patterns book by Adewale Oshineye and Dave Hoover. The reading described the 3 roles in software craftsmanship, these roles are the apprentice, the journeyman, and the master. Reading about this helped me realize the depth and responsibilities that come along when going through each role. I think the role that intrigued me the most was the Journeyman, it seems like the most challenges are encountered at this stage. Oshineye says “he moves between projects and masters, seeking to diversify and deepen his portfolio; he seeks to elevate his status within the community;”. From the reading I gathered that this role takes up the most time and that this is the role that many people can get stuck on but the reward of making it to the Master role is worth it. All 3 of these roles play off of each other and chapters 2-6 give insights to some of the problem people might encounter and solutions to help improve in different areas.
In Chapter 2 ’emptying the cup’ it talks about having one solid programming language under your belt to solve problems. This is something that I completely agree because with the amount of languages out there, it can be daunting and make you feel that you need to know a lot of these languages to solve a problem. When I first started learning to program I had the mindset that if I try to learn multiple languages then the problems I run into will be easier to solve but I have since learned that sticking to one language at a helps you grasp and apple more techniques about that language.
Another chapter that I learned from is chapter 4 ‘Accurate Self Assessment’. This chapter talks about the problem that affects to many people which is, the rate of learning has leveled off. Finding motivation to strive to get better is only half of the battle because motivation can only take you so far, Its discipline and drive that are the key to constantly improving. The chapter also says its better to be a small fish in a big pond than a big fish in a small pond. By surrounding yourself with developers better than you, you can learn much more and see yourself grow to their level. That is why it is crucial to not get complaisant when you reach achievements, keep setting goals and record the milestones. An issue I struggle with is that after I solve a problem or finish a project i’ll get laid back and try to ride the success for as long as possible and the result is I get too comfortable. This chapter gave great advice and I recommend you check it out.
Overall the content in the book is great for developers of all different levels. After only 6 chapters I have taken a lot away and plan to continue reading. I plan to apply what I learn on my road to becoming a master! I will link the book below, Thank you for reading and I will be back again next week.