Final sprint, final push with the goal of completing our problem and committing our fix. The dreams were crushed. We bit off a bit more than we could chew by trying to recreate the module to make it look better. But if we didn’t attempt that, I highly doubt our simple fix would’ve been accepted.
Unfortunately we never received a response with our questions regarding the problem. We weren’t able to climb over that wall, but overall looking back on this class we gained some knowledge working remotely for a company (especially difficulties in communication). I had fun working with Angular 2, and definitely had fun with the scrum team.
This chapter is all about interviewing practices that tend to lead to the wrong candidates being hired. The basic theory questions are valid, however it does not give the candidate the chance to showcase their skill-set by breaking down a problem, or displaying communication skills.
The Cost of Low Morale:
This chapter revisits the Agile Hangover problem and 9-5 developers. Eventually the morale of the team plummets, but there are ways to boost passion among the team to have a positive effect in the long run.
In this chapter, the author tells about how finding the right developer for a certain position is tough to find, but job descriptions are part of the problem. He goes on in detail about how we need to get rid of job descriptions; they’re anti patterns. They’re anti-talent and anti-diversity along with being terrible predictors of future success.
Interviewing Software Craftsmen:
This chapter is all about the process from the perspective of the interviewer, and the interviewee. The modern methods of this process lost sight that the purpose is for both parties to gain a better view of what the working arrangement might be so that there can be a mutual idea of what would work well for each of them. A big red flag on the for the interviewer is when the candidate does not ask any questions.
This chapter speaks about the art of technical practices, mainly Extreme Programming (XP). XP technical practices that are discussed individually include Test Driven Development, Continuous Integration, Pair Programming and Refactoring.
The Long Road:
The author tells another personal story in this chapter where he talks about the long road, and a developers goals in the long haul. He gives examples of things that we can do to create opportunities for ourselves. He speaks about Autonomy, Mastery and Purpose.
Splitting into teams proved to be a wise decision on our part. We are able to tackle three problems at once, and although my pair’s problem isn’t ready for a push yet, we have made much progress. My specific problem involves letting the user know if their contact information saved correctly upon clicking the save feature. We were able to locate the save feature in the code, and adding a basic browser alert window was pretty simple however we decided it did not fit well with the structure of the website. We are now attempting to recreate the small module that the contact information appears in, in order to have our save message display as well. Overall we believe it will fit much better with the flow and look of the site. We are heading into our final full sprint on top of finals and papers piling up, but we are determined to finish the bugs we have assigned to us.
Heroes, Goodwill and Professionalism:
This chapter consists of several personal stories that leads to the idea for the need to learn how to say “no”. Do not push yourself past your limit. Always saying no is not professional however there’s a happy medium where you will not overdo yourself.
Working software is not the end point. It’s the constant fight against the threats that you can not see. The chapter covers a common Agile anti-pattern, the Unit Test task card, and explains why it is a bad practice. Also goes on to define legacy code. Legacy code is essentially code that gets inherited by a team or programmer from somewhere else (external or internal). Almost every company has legacy code to an extent and there has a to be a professional attitude around that idea to deal with it.
Sprint 4 was partially overrun by spring break causing a lack of progress. However, our team was able to fix our problem and make our first push. That push was sadly not accepted because the problem has been updated with some new information. The team is back to the drawing board to find the prime location for this button before we make our next push. On top of that we picked up two more problems to tackle this sprint. I believe we are going to split into pairs to be more efficient with our time. On a different note, our team’s attendance significantly improved leading to a better review sheet at the end of the sprint. We are definitely progressing as a team.