Teams and Projects: 

Teamwork doesn’t happen nor flow instantaneously. Teams need time to adapt to each other and learn to work and flourish as a group. Therefore breaking up a team for projects is a terrible idea. This idea was very fitting because our group started off working very poorly together–or more so we just didn’t collaborate. Over time we are beginning to adapt and be more vocal.

Mentoring, Apprenticeship, and Craftsmanship:

New programmers need mentoring. Like any other field, becoming a specialist most of the time takes years. Given the impact of software on our lives, this is crucial. There is no responsibility for elders to teach the young causing a missing puzzle piece in programming. It’s producing a lack of role models.

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

Pressure: 

Pressure can make or break people. There are some who thrive, some who fail. The professional developer is calm and contained under these circumstances, sticks to their roots, and finds the best route to hit the deadline. However avoiding pressure from the start would be the better option; do not make a promise you cannot keep. In other words, only make a commitment you can fulfil, keep the code clean, have a plan, and work in a way that there is no need to change it during a crisis. In relation to our class, we are under pressure during our sprints to finish what is on the table. If we accept too much, we might not be able to finish making us look worse.

Collaboration:

The majority of programmers prefer to work alone; that’s just how it is. There needs to be a common understanding for communication amongst the business folks, clients, dev team, etc. Collective code ownership and pairing create this level of communication that is necessary.

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

Overall sprint two went well. Our basic Trello tasks were completed which included setting up, connecting, and building our APATH login. The main issue that arose with connecting to AMPATH was the server on the site; it wouldn’t allow any user to connect normally. Therefore either the user could download a chrome extension, which for some of us caused our Wi-Fi to crash, or add a code snippet to one of the xml file. Option B proved to be the more promising choice that most of us went with. Some of us were able to begin rewriting some of the module, nothing too special yet, but it will still be placed onto the backlog of the next sprint.

A big part of our retrospective was that we realized our communication and teamwork has been rather poor. Up to this point, the majority of the work has been done independently which we believe to be partly caused by nothing has been too extreme or challenging that we have had to collaborate on, but nonetheless we are looking to improve in those aspects come the next sprint. On the other hand we have had some issues with attendance and participation in daily scrums that we addressed and hope will be fixed for 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.

Time Management:

Time management is key to accomplishing most tasks in life especially programming. Time is precious; do not waste time. Meetings are necessary, but often are time wasters. Keep discussions brief within meetings, try not to keep everyone there trying to solve a problem in the meantime. Keeping focus all the time is a tough task, especially with software development, but you can break up your day with simpler tasks. This directly applies to us but more in the sense of managing other classes/work on top of our programming.

Estimation:

Estimation will always cause uncertainty. One of the hardest questions a developer will ever have to answer is how long something will take. The PERT technique computes distributions based off best-case, nominal, and worst-case estimates for the project.

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

Week 3

Finished our first sprint! It has been a low week here waiting for the next sprint to happen where the interesting tasks will ramp up. Over the past week I completed my Angular Tour of Heroes, and we did a team evaluation at the end of the sprint which turned out to be a slightly awkward experience because no one wants to throw anyone under the bus. We have to progress as a team and complete our tasks though. We will see how smoothly the next sprint goes then re-evaluate.

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

Test-Driven Development: There are rules that the author provides about test-driven development such as you are not allowed to write any production code until you have first written a failing unit test. You are not allowed to write more of a unit test than is enough to fail and the contrary, you are not allowed to write more production code than is enough to pass the currently failing unit test. Working in small key increments making sure the units operate properly will reduce any problems. From my experience, I have noticed trying to write the entire program THEN go back to search for these errors can be troublesome–and not fun.  This incremental testing will reduce defects by 2-10x, increases comfortability of the coder with their code, and more importantly provides certainty that the change will not break anything.

Practicing: Practicing is key is any element in life. Practice what you preach. Code Kata is an exercise in programming that helps a programmer hone their skills through practice and repetition (in relation to the concept of kata in the martial arts). Wasa is a two-person version of the kata where it is done in pair-programming style. Moral of the story, there are several ways to practice, and every coder needs to practice. From being in the field for a few years now, and reading blogs it is very clear how fast this field evolves. You can’t possibly stay up-to-date without studying outside of work. All professionals practice.

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

Week 2

Second week in, we created team slacks to communicate effectively. We built our first short sprint for basic tasks to get the project going. This included creating a trello for a task board, linking the trello to our slacks, introducing ourselves to our client from AMPATH on a forum, and completing the Angular Tour of Heroes. Our project will be written in Angular 2, which previously I had never heard of, however it is just a form of Javascript. From research it sounds fairly easy to jump into especially if you haven’t been accustomed to Angular 1. The tutorial consists of a walkthrough of building an app to help a staffing agency manage its stable of heroes. My app is in the works and it is quite neat!

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

Saying Yes:

When you say you are going to complete a task, you have to mean it…which in turn means to actually complete the task. Commitment means taking full responsibility, some results are out of your control however you must respectively anticipate the limits and raise any concerns from the start.

Coding:

Coding requires a certain level of focus that is unlike any other, distractions and overtime are major problems. A story is provided where code written at 3am causes severe problems; it is a bit difficult to focus in the middle of the night. Interruptions and music are also bad distractions but a helpful way to alleviate these issues is pair programming. Coding can not be rushed; it is a marathon, not a sprint. There is no reason to bring your work home in order to get a head start. Take your time and keep your focus.

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

Hey everyone! Back for my final semester which means more blogs. By more blogs I mean two a week this time! I will be constantly writing about my experience in my SCRUM team along with my learnings, but also I will be noting information from our book The Clean Coder. I can’t wait to see where this goes, hope you all enjoy!

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

Professionalism:

The term professionalism is the defining factor of responsibility and accountability in the real world. One must own up to their mistakes (potentially being letting a bug slip through). The first rule of professionalism regarding software developers is to not harm the function nor structure of the software being developed. There is no perfect world without mistakes, but as previously stated; own up to them, learn, react accordingly. You should know and trust that the code you release will have nothing left for QA’s to find. This is an industry of continuous learning meaning that out of work practice and reading will be required to stay up to date.

Saying No:

This chapter has a long disaster story about what can happen from premature deployment of software. Afterwards speaking about how managers and developers have roles that are adversarial, or opposing, because their goals tend to conflict on the short terms. The manager wants to release the code to make the deadline, but the code is not ready and you are aware. The higher the stakes of the deadline, the more valuable a no becomes on your end.

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