Monthly Archives: March 2017

Retrospective Sprint 3

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.

Clean Coder Chapters 13 and 14 (Week 6)

Wow! Finally in the last chapters of Clean coder, kind of emotional right? I’m still holding it in without spearing a tear from my eye. In the 13th Clean Coder chapter, the author talks about the value of teamwork and how the concept is incorporated into projects. The gel phase gets talked about where its the phase a team really gets to know each other so they can adapt and work together properly. The author goes on about the challenges of being a project leader, including the the point where every team needs enough time to gel so they can work properly together and get things done and keep it together for as long as the project or projects are in development.

I didn’t know that a typical team is around 12 people, i always wanted to know about how many are working within a project. Let alone i wonder how that many people get to know each other while working in the environment, probably go out to the bar or something. Teamwork is critical since working individually on a project is tedious so this is a great topic to touch base on.

The last and 14th chapter of The Clean Coder talks about teaching people how to code and giving them opportunities to guide the educated by working with them and giving them advice. The author first talks about meeting a student who is going for a masters in computer science and somehow managed to avoid coding, and then goes into saying that school can not teach you into being a craftsman.

While I do know people who aren’t really good at coding and are in the CS program, they at least work in a different field that does not include a lot of programming and just mainly testing and maintenance. Learning on your own is super beneficial and school will not really teach you that, they only teach you what you learn from google in a shorter amount of time really. It’s the adventure you go to on your own that counts.

From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

The Clean Coder (Chapters 13 & 14)

Chapter 13 is short and the chapter can be summarized as follows: teams are hard to build, it better to use the same team  for different projects rather than form teams around a single project.

Chapter 14 is about mentoring, apprenticeship and craftsmanship.  I found the Degrees Of Failure section funny. How does somebody go through a master’s degree in CS without knowing how to code? I was surprised to hear that there are CS master’s candidates who do not know how to code! Damn! !

The rest of the chapter was about mentoring, the importance of learning and what it means to be craftsman. I completely agree with the author that the process of becoming a software engineer must be more like the process of becoming licensed doctor. I also agree with the author on the idea of craftsmanship. I takes years of learning, practice and tutelage to gain true mastery of software development.

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

The Clean Coder Chapters 13 & 14

In chapter 13 of The Clean Coder, Martin goes over why teams should not be formed around projects. Instead a team should be put together with the objective being for that team to gel together and stay as a team for a long time. This makes sure that you have people that understand one another and can easily work with each other on multiple projects that they get. If this doesn’t happen, it may take longer for an makeshift team to get a project done rather than one that is already gelled. Martin also points out that it is also time consuming and expensive for a business to be constantly breaking up teams to work on different projects because of that fact. Again this just makes common sense to me. If you constantly have to predict how your teammates will act and never get into a rhythm, then you will be wasting time and effort on those predictions rather than getting your work done.

The last chapter of the book is directed towards those that are already in the field. Martin talks about how universities can only teach the next generation of programmers so much, and the rest falls to mentors that know what it’s like working in the real world. He talks about how, ideally, companies would know not to give recent graduates high level work that could possibly lose the company money. Instead there would be a hierarchy set-up that would make sure people with 10+ years experience would oversee people with less experience, and those people would train graduates on concepts and designs for a year before they are able to work on code. Even though this is technically in place – with project managers, older team members who over look younger team members, etc.  – there isn’t enough supervision and mentoring. I definitely agree with Martin on this point. While I have been learning a lot at college – about design patterns, different types of testing , etc. – I have not ingrained all of these teachings into how I program. I also know that there are tons of other things that I have yet to come across and learn because computer science is a huge field and I can’t possibly learn everything. Most of the stuff that I have absorbed has been from someone helping me personally with a project, or talking with a teacher or a professional on how to get some bit of code to work. This is why I think it is very important for people that are already in the field to remember to work and communicate with graduates, so that they can become better at what they do and, in turn, help the next set of graduates that come in.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

The Clean Coder 13 & 14 Week 7

The first part of this reading discusses teams. Teams are a very important part of completing a project. “The Gelled Team” is a very efficient way of forming a team, it usually consists of 12 people, some programmers, some testers and a project manager. This team needs to learn eachothers habits and learn to be able to work with them, this can sometimes take a long time but is necessary. This team can then take on multiple projects and is much more efficient.

The second part of the reading focuses on learning to program outside of school. A lot of programmers haven’t even gone to school, they teach themselves. The ones that do go to school are not ready to start coding right away, it takes years of learning the way an office works and how to perform efficiently.

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

Clean Coder Chp 13 + 14 Week 7

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.

The Clean Coder: Chapters 13 & 14

Chapter 13 covers the topic of teams and projects. The author talks about two different approaches with projects. The first approach is that a team is selected for a specific project. Usually these people who are selected are also working on several other projects and they are not familiar with each other’s work habits. This type of team usually works slow and is not the most effective in completing a project. The second approach is to select a team that highlights all the necessary skills and keep them together for as many projects as possible. Over time this team will start to “gel” as the author calls it and will become extremely efficient at working together. The only down side that is mentioned is relative to the project owner. The project owner lacks some security in relying on their team’s resources because the team can make a short term allocation of all their effort to another project in an emergency. In conclusion the main lesson here is to form a good team and move through projects together, getting better after each one.

After reading chapter 13 I definitely think the approach of forming a team and keeping them together makes the most sense. By working with the same individuals you can build relationships and form a reliable team that can get projects completed. Unfortunately, as a junior developer I will have little influence on how a company or department approaches their projects. I will however keep this team approach in mind for project decisions when I am more senior. I think it’s important to note that sometimes a team may need to change some of the members intentionally. Maybe one person isn’t working well with others or maybe you need to add a member with a special skill. Keeping a team together is important but I think there should be an overall assessment after each project to make sure improvements are being made when possible.

Chapter 14 covers the topics of mentoring, apprenticeship, and craftsmanship. The author first talks about the different forms mentoring can take. It could be a programming manual, observing a teacher, or really anything that pushes you in the direction of improving your knowledge. He then makes a point that in programming recent graduates often get thrown on to teams without a true training phase like most other professions. He talks about a hypothetical hierarchy of master programmers, journeyman, and apprentices. As a programmer gains experience they shed some of their technical supervision and gain responsibilities including mentoring those junior to them. This chain reaction of elders teaching the young is what leads to programmers becoming true craftsmen and professionals. When junior programmers have good role models they become those role models over time.

After reading chapter 14 it’s clear that proper mentoring is necessary to grow into a craftsmen programmer. I don’t think the author places enough responsibility on the junior programmers though. As a young programmer it’s important to recognize the proper role model and seek mentorship from the more senior programmers who are doing things right. While mentors should reach out to the junior programmers it’s still important to take charge of your own path. Entering the software development field, I’d like to think I will have good mentors that will help guide me in the right direction as I move through my career. If I find that I lack the proper mentors, I will do my best to seek out the professionals I will need to one day become a mentor for those junior to me.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

The Clean Coder chapter 11 & 12

In Chapter 11, Robert Martin talks about pressure and the methods we can follow to handle pressure as software engineers. Being under pressure is something that can either make or break an individual. It is how we handle pressure that defines us as professionals; even in the toughest times a professional must not show signs of distress. Some of the ways that Martin suggests we can manage pressure are avoiding it to began with, not making reckless commitments, and staying clean. Now, I am kind of puzzled that Martin says to avoid pressure because I don’t think anyone purposely tries to put themselves in situations that causes them unmanageable pressure. If we avoided we won’t have to deal with it however, pressure will always find us. These advice are not only applicable to professionals and software engineers, we can also use them in our daily lives to keep manage the distress that derives from being under pressure.

Moreover, Martin talks about collaboration in chapter 12. Collaboration is an essential part of being a software engineer. Most of the programs that engineers works on will always consist of a group of people because there will always be a ton of thing to do. Within that group, there has to be great communication, teamwork, and most important professionalism. Even though at times there will be people that are tough to work with, we have to find a way to strengthen the teamwork. Ultimately, working alone is not always the best choice; when we put our heads together the outcome should be much greater.

From the blog CS@Worcester – Adestin by adestinyblog and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 11 & 12

In chapter 11 “Pressure”, author Martin, talks about various ways of avoiding and handling pressure. He suggests that the best way to stay calm under pressure is to avoid the situations that cause pressure. It is equally important it is important to avoid committing to deadlines that we aren’t sure we can meet. Another way to tackle pressure is by staying clean. It helps us to avoid pressure by keeping our systems, our code, and our design as clean as possible. Furthermore, author relates back to TDD disciplines. He suggests to choose disciplines that you feel comfortable following in a crisis. Then follow them all the time.

As being a computer science student right now, I get a lot of pressure. I need to go through sleepless nights in order to catch up my schedules and deadlines. Rather than panicking much by taking such stress I will now trust my own disciplines and try to stay clean with my projects. I will also be getting help from my teammates whenever I feel I needed support.

The next chapter is titled as “Collaboration”. Martin summarizes that programming is all about working with people. We need to work with our business, and we need to work with each other. Personally, I think the best thing about in working in team is we get to learn new techniques from our teammates, and of course we get help when we get stuck.

 

From the blog CS@Worcester – Software Dev Capstone by osworup007 and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 11 and 12

Being a software professional, you need to accept the fact that you will constantly have some sort of pressure on you. Weather that is pressure to meet a deadline or pressure to do something else. Your best option here is to try to minimize it. A couple different ways you can do this is by making reasonable commitments. Do not make a commitment that you are not able to keep, this will make it so that you do not have to stress about not being able to make it, which is a good way to cut down the pressure. If pressure is unavoidable it is important that you don’t panic, and stay calm. Something i thought that was interesting about this is when the book says “Sleepless nights won’t help you get dont any faster. Sitting and fretting won’t help either.” This is a lot easier said than done, it is hard not to stress about something, but if you can adopt this mindset then it will help you out in the future.

Collaborating is also a huge part of being a professional. Most software is created by a team of people rather than one individual. It is true that sometimes working with other people may be a struggle. Working with another person can be unpredictable, and may slow you down in the end. Another problem is when programmers feel like they own the code, and they will not let other people work on it or even see it. This is one of the worst symptoms of a dysfunctional team member. When people think of a software engineer or developer, they often think that they sit in front of a computer screen and all they do is produce code by themselves all day. This is not true. Part of being a software engineer is having to work with people. Even if you do not like it, this is something you will have to accept if you are going to call yourself a professional.

From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.