Over the past two weeks, my team continued to discuss what we are working on as usual. We have come to the conclusion that we will add our Search Bar component once there are updates and more of a base to work off of. This was concluded after we realized that the process would be much more efficient. The parameters and details on the search bar would be harder to figure out without making up a base anyways.
Some advice for others who may be working on the same thing would be to try and collaborate or discuss potential orders between groups if one thing may depend on another. That would make it much simpler from the start if possible so there aren’t any clashes or time wasted on doing extra work that could have just been done by one group or team.
In the meantime, I did a little more research on the AMPATH system out of curiosity since we are going to be building onto their work. I found out that there are 500+ care sites in Kenya! It is interesting to think about the potential impact our work may make on how AMPATH carries out their process. Their initiative reminds me of what Enactus at Worcester State strives for when they work on projects to help people or organizations in the community “sustain their own success, connect them with universal health insurance, train next generation medical professionals, and research new breakthroughs and best practices.” Being able to help a healthcare organization is pretty meaningful, especially as a project through my capstone.
A way to tie our 348 course (Software Process Management) with our 448 (Capstone) course would be through now being able to use Travis CI and Heroku. It was interesting being able to experience using these in class and help our peers use it and now be able to use them in our capstone. I think the practice we got was nice because I found that my peers and I were more comfortable with following steps that were written out and explained to us instead of just “going for it.” I have also noticed that our 348 course helped us pay more attention to how we interact with others, which is very useful for the future when we will be working in teams of developers to create or update new technologies. One more thing which I found useful was seeing Travis CI load, and the race against time when it came to classmates pushing code at the same time; it made me push myself to be a little faster while at the same time not be sloppy about what I was putting into my code.
Overall, we discussed what we will do in these coming weeks as the semester comes to a close. The project we are planning on presenting will feature a search bar which we plan to implement by then. I am excited to see what we end up with in terms of helping AMPATH and their healthcare system!
For my second sprint retrospective, there is something I would like to reflect on in terms of a change to my first sprint conclusion. It turns out my build environment was not completely set up properly so I had spent some time with assistance from my teammates on configuring that. I would like to note that I have a MacBook so that made things a little different to work our way around figuring out what to change or test out. A very helpful link was from a question someone asked on Stack Overflow. Through the process of not being able to install angular-cli on my mac, it led me to installing nvm, where there was another series of instructions to follow through Github.
It is very relieving whenever we get stuck on something and are able to find similar scenarios from people around the world who have run into the same roadblock and they share advice on how to work around it. Thanks to their input, I was able to resolve my terminal errors and/or warnings that resulted from trying to build something. It also helped me try and see if I could assist any of my other teammates who were running into errors as well even on Windows. I would definitely continue using the internet as a resource when I get stuck on mac-specific issues. The same thing happens when an installation that is only available in .exe files is required, I must find a mac-appropriate version.
However, if I were to proceed any differently; I would have double-or-triple-checked what is necessary to move forward. If someone else were to follow these steps; I would highly recommend checking out the links I provided above when I was unable to install angular-cli on my mac.
So far, we have been hit with some New England weather which shows how we were able to keep moving and working despite a roadblock that we could not control. It is very relieving to know we are now all on the same page and are working on moving forward together to contribute to the AMPATH system from now until the end of the semester. Who knew something could be more relieving than finally seeing the login screen after the ng command and going to the localhost url.
A big update is we got some more information on the AMPATH x WSU collab right around the end of this sprint so I am looking forward to exploring that with my team. It will allow us to analyze what has been given to us and decide where to move forward with the project.
Overall this past sprint included a lot more learning and collaborating with my team. I’m excited to begin watching the walk-through videos that Greg uploaded of the wire-frames. They look like they are broken down well and all of them are combined into a playlist so I would say we are going to be learning a lot more. Stay tuned for the Sprint 3 retrospective!
Imagine being several years into your role as a developer; you’ve had a long week, a big project to push tomorrow and suddenly… you’re stuck on something. And you’ve double-triple-quadruple checked to make sure everything is working by code review but you cannot put your finger on how it is not quite perfect. What’s wrong? Let’s find out.
This is the first course-related podcast I’ve listened to for a blog post and if this is one of the only podcasts you will listen to, I recommend this one.
Jonathan Cutrell started off the podcast by saying “If there’s one thing that makes developers self-conscious it’s probably their googling history–more specifically things that they google that they forgot how to do.”
People can talk about code for days but they do not talk about the toll of what a developer thinks of themself when they are stuck on a part of their code or need to rely on the internet for something. This honesty makes it easier for university students and entry-level developers to understand the pace they are learning at is their own and that not everyone is perfect at coding even after years of experience.
Something that changed the way I thought about this is how important it is to know the pattern or routine of a concept. Things Cutrell says great developers care about is how understanding patterns and principles transfers but not necessarily the actual code itself. “Great developers” focus on the overall concept instead of wasting time on the small details of a language.
Due to this thinking, I realized I never considered how a developer can be the best of the best in one language but if they had to convert it into another language, the translation would be a little different. The real life comparison to this would be if someone were speaking with broken English. This does not mean they are not smart in any way, it’s saying that they are focusing on the main idea instead of a small detail they are trying to get through. They use their time more efficiently by moving on to a big concept instead of worrying about the syntax that they can easily google.
Overall, I appreciate what this article brought up as I was expecting it to be about just googling things but it dug a little deeper and mentioned what a good developer should focus on.