During Sprint3 I kept learning more and more about Angular2 because I still don’t have strong hold on the language. I got couple of tasks done successfully: I accepted invitation from Jira and successfully connected to AMPATH test2 server. Our group also picked NGPOC-184 issue, started researching and tried to solve it.

I watched couple of videos on Angular2 which extended my knowledge on Angualr2. I also started looking at the ng2-amrs code and tried to understand and navigate through the code. I spent most of the time on learning about Angular2 and navigating through the existing code. Our team started working on NGPOC-184 issue. We spent some time on figuring out when, where and how to approach the issue.  Sudarshan found an informative blog that pushed us to the right direction.

I do not know if it was the issue or it is just our team, but we still need to work on our communication. Most of the NGPOC-184 issue was handled by Sudarshan. The rest of team members spent most of the time on researching and trying to help. I remember Sudarshan saying that this issue is a one-man issue. So, it might have been the issue, but I’m looking forward to more collaboration with my team members.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.

The focus of this week read was: Chapter 11: Pressure and Chapter 12: Collaboration, from The Clean Coder by Robert C. Martin. I can personally relate to these two topics covered in these chapters because I have been in these situations in my life. In chapter 11, Uncle Bob explains the creation, managing and avoidance of pressure. In chapter 12, he stresses on collaborating with other people and caring about your career, employer and colleagues.

All of us have been under pressure one way or another during our lives. Most people get panic, angry or messes everything up without thinking, slowing down and evaluating the situation with cold brain. This is exactly what Uncle Bob is trying to explain. Avoid pressure situations if you can, but if not, then the biggest accelerator to worsen the situation is to get panic and blaming others with anger. I have been in pressure situations where I have contributed to worsen it, then taking a back-step and understanding the full scope of the situation, and try to come up with a best solution. I personally feel like the four ways of handling pressure mentioned in chapter 11 would work great in avoiding and controlling pressure professionally. I specially agree with not panicking, communicate with others and get help. I have tried the communication and get help technique in the past and it worked great for me, but staying calm is a huge problem for me. I need to work on controlling my panic attacks during stressful situations.

Throughout my academic career, I believe that I have learn more through collaborating with others than I have learned individually by myself. That is why I strongly agree with Uncle Bob when he states that professionals pair-program because it is the best way to share knowledge with each other. I am a strong supporter of group projects and team collaboration because I feel like every person has something different to offer in a group or team which proves the point that two heads are better than one head.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.

This week, I read chapter 9 and 10 from the book title, The Clean Coder by Robert C. Martin. The focus of chapter 9: Time Management was how to manage your time effectively and efficiently in the workplace? How to deal with meetings and other chaos going on in office? Chapter 10: Estimation, covers an important topic closely relating to time management. Uncle Bob explains how professionals deal with commitment, estimation and honoring their commitment.

There were some great points pointed out in chapter 9 regarding time management. Some of the most interested points to me were: when to go, decline or leave a meeting; habits that can help and accelerate bringing back focus and getting important tasks done on time; and most importantly his explanation of the priority inversion.

I agree with the author saying that when a meeting gets boring, leave. I feel like there would be lots of meetings in the business world where it gets boring quickly and there would be people who might be able to politely excuse themselves and move on with their usual day, but I am wondering how would it turn out for people who are in an entry-level jobs or new to the environment. I mean… what if he/she has to be there the entire time, no matter what?

I really liked the three suggestions that can contribute to sharp mind and better performance: good night sleep, limited caffeine intake and muscle focus. I have personally tried these and it helps me enormously with my studies and daily life. I could not be more agree with the author when he said that muscle focus increases capacity for mental focus.

Author talks about priority inversion, when I read this part of the chapter I saw myself as one of the victim of this habit. Until this point, I did not know what I was doing, but after reading this chapter, it explained that I am engaging in an unprofessional behavior that is effecting me in ways that I don’t know how to control. From now on, I will be a professional. I will evaluate my priorities, disregard my personal fears and desires, and perform every tasks.

In chapter 10, uncle Bob explains the importance of estimation as commitment to a task. When professionals make a commitment then they are bound to honor that commitment. Professionals do not make commitments unless they are certain about getting it done. I believe there comes lots of responsibility and pressure on individual when they make a commitment. It means that he/she is willing to sacrifice everything that comes in the way of their commitment.

Lesson that I learned from these two chapters are to fight against priority inversion and avoid commitments unless I am 100% certain.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.

Sprint 2 was our introduction to the OpenMRS project Ampath. Our main goal for the sprint was to build and install ng2-amrs, and install openmrs standalone 2.5. As a team, we all were successful in completing everything individually with each other collaboration.

For me personally, sprint 2 started very problematically. I could not build or install ng2-amrs on my local machine. I consulted with my team, the class and Dr. Wurst for help, but we could not figure out what was wrong? During the extended one week of sprint 2, Dr. Wurst introduced us to the different ways of organizing and contributing to projects on GitHub. Out of the three options, our group decided to go with the organizational flow of work. One of our team member made fork from ampath to organization and we all forked from organization. Then, we cloned our individual forked into our local machine. Applying this methodology helped me built and installed ng2-amrs on my machine with obstacles. What I was doing wrong in the beginning of sprint 2 is still mystery to me.

The lesson that I learned from Sprint 2 is that it is true that I was responsible for building and installing ng2-amrs on my laptop, but it really made things better and resulted in maximum outcome when our team collaborated with positive energy with each other. Team members were not thinking about themselves, but rather made sure that everybody in the team has built and installed ng2-amrs. I believe it was this team contribution that led to more discussions on the subject and challenges we were facing, and for that matter it resulted in more clarification of information and ideas. This proves that more can be solved and achieved with each other help and collaboration.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.

This week of reading: Chapter 7: Acceptance Testing and Chapter 8: Testing Strategies from The Clean Coder by Robert C. Martin, covered importance of acceptance testing and the role of Quality Assurance (QA) in the designing, building and delivering of a successful product.

In chapter 7, Uncle Bob explained that there is often misinterpretation and miscommunication between the stakeholders and programmers. One remedy to clear this uncertainty between stakeholders and programmers is to use acceptance testing. Acceptance tests eliminates communication errors between programmers and stakeholders. As Uncle Bob stated, “They are completely unambiguous”. Acceptance tests clears up the communication between what the stakeholders wants and what the programs should deliver. These tests can also be looked as a perfect requirements document.

In chapter 8, Uncle Bob elaborates on the different testing strategies in order to strive for an attempt that QA should find no bugs or defects in the software/product. For this Uncle Bob suggests that first, development team in an organization have to count QA team as part of their team rather than treat them as their adversaries. Development team have to work closely with QA to arrange hierarchy of unit, component, integration, system and exploratory tests. These tests should be run as often as possible which will assure clean system with maximum feedback.

So far in the semester, we been constantly discussing and defining what do we mean when we say we are done? By reading these chapters, it cleared up what does ‘done’ means for a professional developer. Uncle Bob states, “Done means all code written, all tests pass, QA, and the stakeholders have accepted.” Normally, every person or team has their own meaning and definition of done, but when it comes to the business world we have to be on top of our game. We have to be responsible for not only ourselves, but we have to make sure that the team thrives too, and is successful in completion of the project. I believe, I can apply this strategy to our own team projects at university and in professional career that my team’s success is my success. In order to do this, I should be as transparent, positive and open as I can be with my team members. We should reach the ‘done’ part together, not individually.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.

In chapter 5 and 6 of The Clean Coder, author Robert Martin explains two very important habits of a professional and successful programmer i.e. testing code following Test Driven Development (TDD) and practicing your craft. In chapter 5, Martin goes into detail on how he was introduced to TDD and what are the key benefits of TDD. In chapter 6, Martin explains the most important ingredient that I believe is necessary for any field in order to be successful in that field, practicing. Practicing is an exercise that can keep programmer’s skills sharp and can eventually result in perfection with great confidence and accuracy.

There were few great points that the author mentioned about TDD. First point that TDD is a three step-by-step testing process which assures that the new code added did not break the preexisting working code. Second point was that TDD gives programmers courage. If a programmer believes in his tests and is confident about his tests, then this trust eliminates any fear from making changes to his/her or someone else’s code. I believe all the benefits of TDD can be summarize in this one quote, “It is a discipline that enhances certainty, courage, defect reduction, documentation, and design.” TDD does give programmers to test their code on time and helps them break down problem into small pieces which enhances their problem solving skills. A single practice that makes TDD different and interesting from other testing practices is that in TDD programmers have to write their tests before their production code. I have learned about TDD in my Software Construction and Software Quality Assurance courses, and from my personal experience as a beginner, it is a little weird. But after reading this author’s take on TDD, I understand that it will be very helpful in the long run. In other words, I did not had enough practice with TDD which made me a little uncomfortable.

About any field out there, if people do not practice and keep their skills up-to-date and sharp, their demand in the market will degrade dramatically over time. One major point that the author mentioned was that it is not the employers who should be allowing employees to practice. It is employee’s responsibility to keep their skills sharp. I strongly agree with this point because practicing should be fun and exciting. It should be done outside work and on your own time. I believe practicing is very crucial to any field, but for programmers it should be a natural thing because without practice we tend to freeze in time and previously learn knowledge tends to escape from our mind. More practice gives you an automated and instinctive ability where your body and fingers react with your mind directly, without thinking, with perfection. As the author suggests, “We choose a repertoire of problem/solution in pair and execute them over and over again until we know them cold.” For me, lesson learn is that practice a problem over and over again until I know it cold.

From the blog Software Learning and Development – Haider Hussain by hhussainsite and used with permission of the author. All other rights reserved by the author.