“Practice, Practice, Practice” Apprenticeship Pattern

I am writing this blog post about the “Practice, Practice, Practice” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about the desire to improve and learn despite not having the opportunity to do so while working. The obvious solution that the book presents is to practice on your own time, while not working. Practicing something is certainly important; the process of practicing working with some idea is actively developing experience with that topic, rather than just reading about it and recognizing it. I have spent a lot of time reading about many different algorithms, and a lot of it does not really stay until I make it relevant by directly implementing it myself. The only consequence of doing this is educational, though; doing this while working would not be the appropriate time. Practice generally does not yield some purposeful product, whatever it is that is created in the end is only for the sake of experience. The book brings up a point about practicing the wrong things. I think this can be important. I have spent a lot of time practicing trying to write programs using the fewest amount of characters possible, which for obvious reasons is not a good way in general to go about programming. The result is typically a barely readable mess of what amounts to glorified machine code. I became good at it, but certainly the time would have been much better spent practicing something more practical than code golf. After gaining a lot of experience with different topics that I found interesting, I have been able to recognize situations where things I have practiced in the past are relevant and knew how to implement them as a solution. What I have noticed along the way is that now I would rather spend my time applying what I know than taking the time to practice something new and not produce anything meaningful. I still am interested in learning about a lot of things, but practice takes a lot of time, so the only way to learn is to take the extra time.


“Be the Worst” Apprenticeship pattern

I am writing this blog post about the “Be the Worst” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of the pattern, it is about trying to be in the presence of people with more experience than you so that you can learn from them, as opposed to being experienced already and not having the opportunity to learn from others. I can see this being a useful way to learn, but at the same time it does seem a bit selfish to put your own education above the quality of whatever it is you happen to be working on with everyone else. To be the worst may indicate that you do not actually belong where you are while you exploit the opportunity to learn. If this does not turn out to be a concern then it is still the case that you would not be performing as well as anyone else, so it may be discouraging to have a responsibility and not be prepared for it. Maybe being the worst is taking it to the extreme, but the more general goal of not being the smartest person in the room is a good way to learn from the person who does have more experience. I have been programming in the same language for the last decade and I now know everything about the language down to the exact differences between each version, and that came from being involved with other people who had knowledge that I did not have. Now there is no learning opportunity after having mastered this language, so since I have not nearly the same level of experience in any other language, it would be a significant learning opportunity to surround myself with experts in another language that I intend to become versed in. Since I have learned everything I needed to know to do the things I want to do, I have stopped learning at the same rate. Moving forward into a career, I expect it will become necessary to be just as experienced in more languages, so engaging with experienced programmers who use those languages will be beneficial.

Sprint 2 Retrospective

Not a lot has happened in the last two weeks. There has not been a clear assignment given to be accomplished individually or as a team. On the first class meeting of this sprint, I helped Matt get through the final errors to get the ng2-amrs, since he was seeing the same errors that I had seen and figured out how to get through myself. After installing the right version of node, and then following the determined steps to fix the series of error messages that come up after trying to run npm start, it says compiled with warnings and does not error and the AMPATH login page comes up when visiting localhost:3000 in a browser.

Once he got it running, everyone on the team was able to run it without errors, so we had nothing left to do but vaguely review some miscellaneous information about JavaScript and angular. After that, our team did not meet in class for a couple of days or class had been canceled. It was not until Thursday during the sprint review that we started to get something to do, but that was the last meeting before spring break, so we did not get a chance to actually start anything, only to look at the new information that has been given and begin to process it.

From watching the first of the six AMPATH videos that we were sent, it looks like we are being given an existing user interface and it is up to us to implement the desired logic and behavior to have it interact with the medical records back end. The videos walk through some of the buttons and elements that were already placed together on the front end, and some specifics are described about what the elements are supposed to be for and how they should interact with the medical records data. From here on, we will finish watching the rest of the videos to better understand what they explain and what is expected of us, and we will have to decide among the other teams who is doing what, and figure out what it is we are actually going to be doing and how to do it. From what I have understood so far, I think that we are going to need to read a lot of the code that has been written so far, and then while we are writing more code to implement the new front end features, we will be referring to the existing code in order to find out how to access or manipulate certain data and objects. Depending on the amount of documentation that exists, it is possible that we may need to come up with our own documentation just to keep track of how everything works. I think that our previous experience programming in typescript during the last semester should be helpful while writing the code for this, although this does seem like it is going to be significantly more in-depth in certain areas.

Sprint 1 Retrospective

This past week has been about trying to get the ng2-amrs environment working, and trying to get through the errors that show up when running the npm start command. I have learned a lot of the steps to take in order to approach this problem, although I am still not finished with it. I am not sure that I would proceed differently, I just think it would have been better if these problems were already known, since everyone is having them, and it would have been better if there were more instructions to deal with these expected problems. Most of the approach involves googling error messages, which can definitely be applied in other situations.

Most of the week was spent looking up different npm, ng and node commands, googling error messages, and trying different combinations of the commands and re-installing things after nothing worked. The reason that I took these steps is because I really do not know what I am doing and running through permutations of commands seems to be the only way to move forward to get the program to run without errors. A lot of the process involved referring to the slack channels, where teammates and other teams have run into the same problems and found solutions.

The ng2-amrs readme on the github page says to run the ng serve command for a dev server. What it does not say is what to do when this does not work. A guess at the problem involves version issues with angular, npm and node. Different versions were attempted to try to solve errors. Most of the steps involve googling the error message, which leads to a stackoverflow post that says to install a certain thing that solves the problem. When it does not solve the problem, it becomes very unclear what to do next. Changing versions and re-installing things has not seemed to work.

I have deleted and re-cloned the ng2-amrs folder from github. When I run the ng serve command, I currently see an error Could not find module “@angular-devkit/build-angular”. I google this and stackoverflow tells me to run npm install –save-dev @angular-devkit/build-angular. After I do this and re-try ng serve, a few more errors show up that do not seem to be as easy to deal with. One teammate found npm-check that will list missing things and things that are out of date, so I installed and ran that and had it automatically install everything it found using npm-check -y. After that finished, I re-tried ng serve, and it came back with a new error about styles.scss. I searched the error and found a command npm rebuild node-sass to deal with it. Running ng serve again, now I get some typescript errors. I check the group slack channel and see the command npm start, so I try that, and the next error I see is Error: Can’t resolve ‘pouchdb/dist/pouchdb’. I try running npm install and that brings back the scss error, but this time the same command that fixed it before does not fix it anymore, and it complains that I use a 64-bit operating system. I downgraded to node 8.12.0 and re-tried fixing styles.scss and running npm start. It actually seems to be working now. It says compiled with warnings, I open localhost:3000 in my browser and the ampath page comes up.

Why Doctors Hate Their Computers Blog Post

I am writing this blog post in response to the The New Yorker article “Why Doctors Hate Their Computers” by Atul Gawande. I thought that it was an interesting story. In general it seemed to be a look into how doctors and other medical healthcare workers are fed up with the poorly designed software that they are being forced to use. Some shorter stories about scientists and engineers are also included, and they have similar complaints, which shows that this is not just a problem among doctors using electronic medical records systems.

The main problems that seemed to make the doctors’ jobs harder was the fact that the programs required them to fill out excessive amount of detailed information before they are able to move forward. Their workflow is being interrupted and they are unable to do their job in the same way that previously worked well. The new computer interface may have streamlined some of the process, but it became too bureaucratic and inflexible. The fact that some of them decided to work with the I.T. department to hack the system and write their own better interface was not surprising given how much complaining came before that. It is obvious that the users of the system are not the real customers. The real customers – the people who made the decisions about how the program should control how the doctors work – seem to be the hospital administrators. They worked with the software engineers to design a program that forces the doctors to pay more attention to what they need the doctors to do for them, instead of what the patients need.

I do not think this article will change how I work or how I think about the things I make at the moment, but that is just because I am not making any sort of widely used software for important applications like medical records systems. In the future, though, I might recall this article if I happen to be working on some software application that has a variety of different users with different needs and I am given only one perspective. I imagine the developers of the system that the article is referring to might have been wondering about some of the user experience details. If they recognized that the users of their software are not the same people as the ones telling them how to make the software work, then they might have already had some concerns of their own that they were not able to address because the users, the doctors, are not the ones in charge of how the program they are going to be using is going to work. Something I do wonder because of this article is about how these problems can be avoided.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

The first chapter and the next five chapter introductions draw an outline for a general guide to how to learn. The relevance of software development or of the term “software craftsmanship” seems to go away after the first chapter, where the rest is just about self improvement and how to learn. I agree with the points being made in each chapter, but I am also recognizing that these ideas seem to extend to literally every field of study, and not just software engineering. Throughout most of the reading, I was actually thinking about mathematics and not software development, and the ideas apply just the same.

I think that chapter 5 seems to be the most relevant to me. I know that I have learned a lot already, and I am also aware that there is a lot more that I do not know, and even more that I am not even aware of. There is a lot of content to learn about that I find interesting, and I always seem to find that I am preoccupied with other tasks such that I am unable to spend as much time looking into new interesting material as I would like. I started reading the beginning of chapter five just as I was thinking this, and the chapter opens with a quote, directly relevant to that thought, about how there will always be some distraction from learning, so it is necessary to seek knowledge anyway even when the conditions are unfavorable.

I think the idea of “emptying the cup” from chapter 2 is also relevant. Chapter 1 mentions that somebody may recognize that they are at the beginning, as a newcomer to software development, even if they have already been programming for several years. I think it would be likely to have been exposed to some software development projects and practices during the “several years” of programming, so the term “beginner” does not seem to fit very well for somebody with that much experience. On the other hand, somebody who has been actively learning to the extent described within these chapters will definitely have transcended their level of experience. The idea of a “full cup” comes into play when an experienced person is not inclusive of further experience and knowledge. There is the expression about teaching an old dog new tricks. It is necessary, in order to learn, to actually want to learn.

I can see myself applying the principles in these chapters more so toward my mathematical education than my software development education, only because I am more aware of what I do not know in regards to mathematics. I expect that the focus should shift more specifically toward software development in later chapters; knowledge of careers and how software development works on the level of employment is much less familiar to me than the computer science component of software development, although there is still much more to learn in computer science alone.