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.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Interview Anti-Patterns:

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.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Recruitment:

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.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Technical Practices:

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.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

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:

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.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

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.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Software Craftsmanship: 

“Software Craftsmanship is about professionalism in software development”. It is about an approach to software development that puts emphasis on the coding skills of the software developers themselves. He speaks about Software Craftsmanship Manifesto where one not only creates working software or not only responds to change yet creates well-crafted software and constantly adds value.

The Software Craftsmanship Attitude:

This chapter stresses the importance of continual learning and self development. An individual has to take it upon themselves partially to progress towards bettering themselves. Coders can’t rely on employers to teach them everything.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

Software Development Nowadays:

Seniority is software development has no correlation to one’s skill set. The number of years one has worked is a poor indication of their ability to write code. “There is a huge difference between having ten years of experience and having one year of experience repeated ten times.” The need to explore different technologies and project is vital in this field. The industry is adapting towards needing more flexible coders.

Agile:

After the author goes over the principles of Agile manifesto, he says the statement “Many Agile projects are now, steadily and iteratively, producing crap code.” Roles became reversed, and everything was a mess working in an agile environment.  It has been a partial transformation in his words–or a transformation of the process but not of the technical practices. Software Craftsmanship is not meant to replace agile but to assist it.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

During Sprint 3 we were able to complete our small tasks, but upon approaching our first bug we ran into a problem where we could not locate the button. The problem description was not very descriptive and contains no images of the said button. There was a section with forms on the site that we were assuming contain the button (due to the name of the button having ‘form’ in it), however none of the forms would load on any of our computers or servers. We reached out to the product owner and received a response toward the end of the sprint where he provided a new server. With this new server we were able to load a form which corresponded with us finally being able to find the button. Using debugging tools in the browser we can easily find the code name of the button and the container allowing us to easily find the section of the code that we need to change. Sadly because of the delayed response and how much in class time we have we are going to have to push this item onto the next sprint.

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.