Category Archives: cs-wsu

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.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Use Your Title

While you work in the software industry, you can be promoted, formally or informally, to some high position that sometimes do not fit to your knowledge. You can be promoted to senior or lead positions, but on the other hand you have to explain away tue difference between your skill level and your job description. … Continue reading Use Your Title →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Concrete Skills

This week’s blog is about Concrete Skills from the Apprenticeship Patterns book. It talks about what to do when you are looking for a role on a talented team that will provide you with better practice and enhances your learning, but sometimes these teams do not want to be bothered. Sometimes, having a new hire means you are going to be teaching them again from the beginning and these new hires do not offer anything to the company or team yet since they do not know how things work. This section of the book talks about how to deal with it.

In this section, they talked about concrete skills. They said that it is important to have some concrete skills so that you will be trusted to contribute indirectly until you start to gain their trust. It will help reassure your team members that you can be put to good use rather than being a burden that they have to babysit. They added skills like writing build files in various languages, basic web design, JavaScript, and knowing some standard libraries in the language of choice.

I find it interesting that the book suggests that you look at the CVs of the people whose skills you respect and identify the skills noted on the CV and determine which of these skills would be useful on the team that you want to join. Implement these skills on your own project, make sure that you know how to do them and how they work.

I completely agree with this pattern. I think knowing some concrete skills will come a long way when looking for a job or when starting one. You can’t always rely on your team to teach you stuff and they can’t also just ask you to do things that you have never done before right away since they are also working on stuff and not just there to babysit you. They will expect you to work and you have to prove to them that you are capable of being on the team. That’s why I think having concrete skills is good.

 

From the blog cs-wsu – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

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.

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

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

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.

The Long Road

When we start thinking about the future we should know that the journey will be long. In the software development field things are a little bit more challenging. This field is full of information that gets updated frequently and to many technologies to learn. If we want to develop strong skills in software crafts it … Continue reading The Long Road →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Confront Your Ignorance

Learning is something that you should never stop doing. The more you know the more you will feel the independence in you workplace. As you go through the college you learn e lot, but nothing compared to what your career needs. It is instinctive to show more than you know when you stand in front … Continue reading Confront Your Ignorance →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm

To go through the long road of Software Craftsmanship we should be eager apprentices, so a superior enthusiasm should be with us since the first day of the long journey. Enthusiasm is the first factor that will accelerate your learning. Being a software developer you cannot avoid working with a team in your workplace. As … Continue reading Unleash Your Enthusiasm →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Intro

As you decide to follow a Software Development or Engineering career path, you should consider this path has lot of knowledge that need to be accumulate in case you want to move forward. You could be a Computer Science student or an entirely self taught developer, you should learn how to take advantage from other … Continue reading Apprenticeship Intro →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.