Week 2 Capstone

For week 2 many of the tasks were aimed at getting set up for the rest of the semester. This week is our first real Sprint following the Scrum cycle. The first sprint planning meeting was a little unconventional because all the stories really needed to be completed by each group member. Therefore there wasn’t really a division of work. The first story I completed was creating a Trello login and figuring out how to use the tool. Basically Trello is used for project management and consists of boards made up of lists filled with cards. This setup is acting as our Sprint Backlog and Task Board. We have 3 lists titled Backlog, Doing, and Done. Under each of these lists are the cards which represent a story that was assigned to the current sprint. The tool has an easy drag and drop feature for moving the stories to the correct columns. Next, the team integrated our Trello board with our Slack channel so we can modify the board and get notifications in Slack. There is a built in app for Trello in Slack so the integration is pretty easy and notifications can be configured to the team’s preferences. Next I created my OpenMRS ID so that I can communicate within the development community for the project. I then posted my introduction to the OpenMRS talk page which is basically a communication forum for the project. Lastly I installed WebStorm on my computer which is a JavaScript IDE built by JetBrains. I made a JetBrains student account which gave me access to all of JetBrains tools for free. I thought this was pretty cool and plan to revisit the site to see what other software they have. As for now I haven’t really started using WebStorm but plan to do some kind of tutorial to ensure I am using the IDE to its potential. Lastly, I realized I did not post my Daily Scrum in my slack channel on Friday so I need to make sure I am doing this in the future. As a team, each individual should be posting their stand-up in the channel Monday, Wednesday, and Friday. As this is our first sprint it will take a few cycles before we all are proficient in the sprint process. Looking into this upcoming week I still have the Angular Tour of Heroes to complete and I’m sure the team will be getting more familiar with the OpenMRS source code as well.

The Clean Coder: Chapters 3 & 4

Chapter 3 covers the general topic of when and how to say yes as a professional at work. The stand out message is three simple rules: “You say you’ll do it. You mean it. You actually do it.” Avoiding phrases like “let’s” and “we” are crucial because they almost always hint at non-commitment. It said to make more definitive and personal statements. These include using “I” and giving a specific task which will be completed at a designated time. This chapter also reinforced a theme from chapter 2 in regards to only committing to what you can truly deliver. That is if you depend on another team or individual only make real statements about yourself however work with that other party as best you can to get closer to the target goal. Also another idea mentioned previously was early communication. Specifically mentioned in this chapter is to raise a red flag as early as possible because this gives the best chance at a work-around that still allows you to follow through with an expected task. The strongest point of the chapter is to be clear and definitive when saying yes, similar in how to say no in chapter 2.

After reading chapter 3 I have a few takeaways to reflect on. The first is to be more definitive in my own statements. I am definitely guilty of using the “I’ll do my best” mentality and after reading this chapter I realize that way of thinking won’t cut it in the long run. I also think an important message was to not commit to something that is out of your control. Looking forward I will take more time to think about what I am actually promising will get done and ensure it is fully within my power to do so. I also think the last scenario in the chapter was a good lesson. The employee promises that he will meet a Monday deadline knowing he is fully capable of doing so. It was his confident negotiating of taking a day off after his task was complete that I found worthy of remembering. This shows it’s sometimes okay to put in that extra work for an earlier deadline but not to be afraid to take that time to reset afterwards. Once again I believe applying the Scrum development process could help avoid some of these situations and improve your saying yes skills. By having semi-regular sprints you are saying yes and being held to your word on a more frequent basis. This development framework should help keep everyone honest and committed.

Chapter 4 talks about a wide spectrum of factors to keep in mind when actually coding to maintain the professional character the book strives for. One of the main factors mentioned is distractions while coding. This could be that you didn’t get enough sleep, a personal issue at home, or possibly just writers block. You should take some time away from the desk and see if there’s anything that can be resolved regarding the issue so that your mind will be able to focus on your code. Secondly, the author mentions “the zone” where programmers may feel like they are on a roll and have tunnel vision. He warns that you should never code in this state because you lose sight of big picture concepts and will likely return to the written code to fix mistakes. Overall the theme of this chapter is that you should recognize when you are not doing your best coding. It’s suggested to meet with a pairing partner or maybe just walk away for a few minutes so that only the best code gets written.

After reading chapter 4 I think there is a lot of good advice to keep in mind when coding in the future. This being said I’m not sure everything is as easy as it is told. Life distractions will always be present and I’m not sure trying to solve them at work would look professional among my peers. I do agree however with the idea of stepping away and taking a break if I feel like I’m not writing good code. Having a mentor, as the author mentions towards the end of the chapter, could be a great way to stay on track by meeting regularly with that mentor or even a partner. In regards to the author’s mention of false delivery and defining done the Scrum framework once again would help prevent the shortcomings mentioned in the chapter. Throughout the book so far Scrum has proven to address many of the concerns in each chapter. I am starting to see why this form of agile development has been so widely adopted.

Week 1 Capstone

We’ve only had two classes so nothing too detailed to cover for the week. Basically we had an intro class where we learned the work for this class will involve the OpenMRS project and more specifically the AMPATH sub project. I reviewed the SCRUM fundamentals because that framework is how our class teams will be approaching work flow. Additionally we chose the teams we will be working with and I am on Team Loading… for the duration of the project. Lastly I got familiar with Slack which is basically an effective messenger for development and professional teams. This is where my team and the rest of the class will post important project information and communicate among each other. Looking into next week I expect to start setting up my environment for JavaScript and Angular 2 as these will be required to contribute to the project.

The Clean Coder: Chapters 1 & 2

Chapter 1 gives a layout of what a true professional software developer should be and highlights a broad spectrum of attributes one should possess. The first major trait is accountability. More specifically, while bugs are certain to occur it is up to the developer to do everything in their power to see their employer’s problems as their own and take all measures to avoid bugs and errors. When a QA team comes back with a bug, a professional developer should be surprised. The second major trait of a professional developer is testing. It is even suggested to use test driven development (TDD) where tests are basically written before the actual program. There should always be some form of automated testing to ensure software is working correctly prior to QA. Also along with the coding aspect, a professional is always making small changes to the structure of their software to ensure continuous improvement. Lastly, a true professional pursues knowledge and information outside of working hours. It is said to dedicate the 40 normal working hours to your employer and 20 hours for self-growth every week. Within those 20 hours it is also not only important to learn new skills but also practice and sharpen skills already obtained.

After reading chapter 1 I believe there are a lot of takeaways, especially for a student who is seeking good habits before letting bad ones set in. One thing that I am going to look into further is the test driven development approach. I lack the experience and knowledge of appropriate testing and by writing tests first I think it would have nothing but positive effects on my development. I also think the 40/20 hour split is an important habit to start now. Even though as students we are learning many hours already, I still strive to learn outside of the curriculum and this chapter has reconfirmed my actions. I will try to continue if not increase my time spent learning more skills outside classroom studies. Lastly I definitely need to practice more of the skills I have already learned. I often find myself only using something when I need it, forcing me to look simple things up that should be committed to memory. This chapter showed me what I really need to be doing if I want to consider myself a professional by the right definition.
Chapter 2 highlighted a lot of situational awareness of when to say no as a professional software developer. One key point is to search for the best possible outcome when dealing with a supervisor. Additionally, never make false estimates and always stay honest in what you truly believe. Saying or working with the “I’ll try” attitude is recipe for disaster and not the trait of a true professional. Lastly, the chapter is clear that being upfront and consistent with your abilities and timelines is best for everyone involved.

After reading chapter 2 I can definitely see how this advice may come as more of a challenge to a junior developer. They lack the experience to accurately and confidently set time tables for themselves. I think there may be an unavoidable learning curve to the “saying no” mindset however it definitely seems like great advice to follow. Having a systematic approach to development such as using Scrum could also alleviate many of the issues described in this chapter. Working in shorter sprints with continuous contact with the client in the Scrum manner should for the most part prevent a team or developer from being coerced into an impossible task. Also, it is much easier to say no as a team rather as an individual to a supervisor. Great content to think about and to keep in mind when you know you are being pushed to accomplish an impossible task on time.