To start our fourth sprint we divided the NGPOC-185 issue into distinct parts so that everyone on our team could dig their hands into the issue.  We broke the task into six parts and everyone picked a piece they thought they would do best.  I was going to take everyone’s individual piece and combine them into the final solution.  Unfortunately, we were mistaken.  Our solution was incorrect because our approach was all wrong.  Over Spring Break one of the members of our group determined that the solution was much more simple than what we were attempting.  Once I returned from Spring Break, I had a chance to review his approach.  Apparently we were looking at the wrong thing and once we received some clarification the solution came together in a couple of days.

With our solution complete, we determined that these issues were not as complicated as we originally thought, and broke our group into groups of three.  This way we can complete twice as many issues per sprint.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

This past sprint our class was assigned four issues on JIRA, an issue-tracking software. AMPATH set all of us up with our own login information so that we could view, assign, and comment on the issues.  The issue we wanted to work on was given to another group, so we ended up getting our second choice, called NGPOC-185.  The title of NGPOC-185 was “Logout not working when editing a form” and had the description “if you are in the middle of editing a form, but you decide to cancel and logout (may not be a practical case) , after accepting to cancel, it should log you out.”

As a team we determined that the issue was asking us to have a confirmation window pop up when a user tries to logout while they are editing a form.  So we figured our first step would be try to recreate the issue.  We booted up our local server and determined what the issue was describing.  Our next step was to find the code the corresponded to the issue.  After some searching we think we figured out where to begin.  We decided our best course of action was to read up on Materialize CSS and then attempt the issue next sprint.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Chapter 13 is all about creating a culture of learning at your company. Here are some of the things that the author thinks can be done to improve the morale and create a culture of learning:

1. Start a book club.
2. Have a tech lunch.
3. Have group discussions.
4. Conduct group code reviews.
5. Have hands-on coding sessions.
6. Start internal communities of practice.
7. Encourage pet-project time.
8. Engage with external technical communities.

Creating a culture of learning and motivating developers is important for a company as it directly impacts the code developers write. Ultimately, this depends on the developers; hiring passionate developers and providing them with a good environment would improve the innovation of the company.

Chapter 14 is about how to convince skeptics into adopting new practices or changing the culture. The first step according to the book is to identify the type of skeptics. The following are the types of skeptics the book talks about:

1. The uninformed.
2. The herd.
3. The cynic.
4. The burned.
5. The time crunched.
6. The boss.
7. The irrational.
8. The indifferent.
9. The wronged.
10. The inept.
11. The ivory-tower architect.
12. The insecure.
13. The fanboy.

The chapter goes on and on about how to convince these skeptics to adopt something. Overall, what I got out of this chapter is that I must be good at what I do, I must communicate clearly, and I must establish trust to drive change.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

We picked four issues to work on this sprint. We made some progress into fixing them, but it turned out that the AMPATH team had fixed them. At the end of the sprint we decided what needs to be done to complete the presentation. We plan on meeting somewhere before our presentation and work on our presentation.

The only thing I learnt this sprint is that always ask questions when in doubt. If we had not asked the AMPATH team for guidance on the issue we would never have known the issue was already solved.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

I found this chapter 11 really interesting and useful. Most of the scenarios that the author describes I have experienced.

The author mentions that before talented developers accept a offer they consider the financial offer, autonomy, mastery, purpose, productive partnership, talented and passionate people, and a good working environment. Of all the factors involved, I think working with talented and passionate people is the most important. I know what it feels like to work with unpassionate people. Working with unpassionate developers is not very productive and can be quite irritating. The only reason that I am a Software Engineer is because I LOVE Computer Science and I LOVE the craft of developing software. It is hard to work with other developers on creating software who do NOT share the same LOVE. You would not grow as a developer if you stick with unpassionate developers.

The author then talks about interview anti-patterns. The following are the interview anti-patterns mentioned in the chapter: don’t be a smart-ass interviewer, don’t use brainteasers, don’t ask questions to which you don’t know the answers, don’t try to make the candidate look like a fool, don’t block the internet, don’t code on a piece of paper, don’t use algorithms, and don’t conduct phone interviews. I have experienced all of these anti-patterns on my interviews for a year now. I would love to share some of my experiences, but unfortunately I don’t think it would be wise to do it.

The most important thing to understand from this chapter is that you as a software engineer are not a slave to your employer.

Chapter 11 is all about how important the morale of a team is. Low morale can destroy a company; and unmotivated people do a lousy job. A company must bring the best out an employee.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.