Monthly Archives: March 2017

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.

The Clean Coder Chapters 9 and 10

Chapter 9 in The Clean Coder is about time management. The first thing it goes over is meetings. While meetings are very important and worth your time to go to , this is not the case with all meetings. In fact, it is actually  considered unprofessional to go to too many meetings, which would not leave time for you to do other stuff. If you find yourself in a meeting that is not worth your time, it would be wise to find a polite way to exit. Time management is important outside of the workplace also. It is important that you are getting enough sleep at night to ensure that you are ready for the next day of work. Caffeine and short breaks can help you keep focused if you are having trouble. It is important for a software professional to keep their options open by keeping an open mind about alternate solutions to their problems. It is not wise to become so vested in a solution that you are not willing to abandon it for a better solution.

Chapter 10 is about estimates. Something that was interesting to me about estimations is when the author said, that business like to view estimates as commitments while developers like to view them as guesses. The problem with the business looking at them as commitments is that the estimates may not always be correct. This may require a developer to work extra hours in order to fulfill this “commitment”. Developers should not make commitments that they cannot meet. When they make a commitment, it is expected that they will honor this commitment at all costs. This is why when developers give an estimate it should be a very well thought out estimate to avoid any complications.

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

Clean Coder Chapters 11 and 12

This is an interesting chapter. I have been in many different
types of high pressure situations, some that required in the moment think on
your toes stuff in the military and other just plain old the boss or company
wants this and wants it yesterday type stuff, but to be honest I have never given
it much thought as far as what I do in or out of crisis. I like how he keeps
hammering home to not make commitments you cannot keep though, that will cause
a crisis for sure. A good bit of his points are in my opinion common sense ways
to avoid unneeded pressure. Keep your code clean, keep your system and design
clean etc., but others I had never given thought to, especially in th crisis
part where he says, “You know what you believe by observing yourself in a
crisis.”, so true. Thinking back on my life and some of the situations I have
been in I have thrown out the norm of doing things and switched to a whole new
set of rules, but I think in some cases that needs to happen. I do agree though
that in this field you should stick with what works for you in and out of
crisis as there should be no need to change how you do things as long as you
have a system that is efficient and clean.
 
He gives some great tips that should be lived by, don’t
panic, communicate, rely on your discipline, and get help. Those are great tips
and I like. I mean I guess it is easier said than done, but practicing these things
outside of crisis will make you handle them better. The biggest pieces of
advice I could give from this and he says also is “SLOW DOWN, COMMUNICATE, and
get HELP!!”. There is nothing worth a heart attack or stress related illness
over a job. Calm, cool and collective they say. Communication is huge and goes
hand in hand with the get help part. Speak up, don’t be afraid to ask questions
or for help, this isn’t grade school and no one is going to blow you off or
laugh at you. I think the best tip is avoid pressure if you can.

The more of the book that I read the more I think it grows on
me in a way. I see so much of what he has gone through in my own life and the
trials I have endured. It fascinates me that no matter what industry you are
in, it seems like you run into the same scenarios or strategies. I know this
chapter is about collaboration and I agree with him in that working together as
a team is usually better than by yourself no matter how much you think working
alone may be better for you. In my opinion the more heads the better off you
are to an extent. I mean of course the people on the team have to have a
similar mindset and all striving towards one goal, but as long as that is the
case things usually go a bit better. The team keeps itself in check and egos
are hard to get in the way. I do get though that most of us computer guys and
gals are geeks and don’t work well with others in a normal sort of way (whatever
the definition of normal is) but we do however work together well with one
another I think. Like he says though, there are of course times when it is
right to work alone and that is fine, but I like his idea of it being best to
collaborate with others and pair a large fraction of the time.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 11 and 12

This is an interesting chapter. I have been in many different
types of high pressure situations, some that required in the moment think on
your toes stuff in the military and other just plain old the boss or company
wants this and wants it yesterday type stuff, but to be honest I have never given
it much thought as far as what I do in or out of crisis. I like how he keeps
hammering home to not make commitments you cannot keep though, that will cause
a crisis for sure. A good bit of his points are in my opinion common sense ways
to avoid unneeded pressure. Keep your code clean, keep your system and design
clean etc., but others I had never given thought to, especially in th crisis
part where he says, “You know what you believe by observing yourself in a
crisis.”, so true. Thinking back on my life and some of the situations I have
been in I have thrown out the norm of doing things and switched to a whole new
set of rules, but I think in some cases that needs to happen. I do agree though
that in this field you should stick with what works for you in and out of
crisis as there should be no need to change how you do things as long as you
have a system that is efficient and clean.
 
He gives some great tips that should be lived by, don’t
panic, communicate, rely on your discipline, and get help. Those are great tips
and I like. I mean I guess it is easier said than done, but practicing these things
outside of crisis will make you handle them better. The biggest pieces of
advice I could give from this and he says also is “SLOW DOWN, COMMUNICATE, and
get HELP!!”. There is nothing worth a heart attack or stress related illness
over a job. Calm, cool and collective they say. Communication is huge and goes
hand in hand with the get help part. Speak up, don’t be afraid to ask questions
or for help, this isn’t grade school and no one is going to blow you off or
laugh at you. I think the best tip is avoid pressure if you can.

The more of the book that I read the more I think it grows on
me in a way. I see so much of what he has gone through in my own life and the
trials I have endured. It fascinates me that no matter what industry you are
in, it seems like you run into the same scenarios or strategies. I know this
chapter is about collaboration and I agree with him in that working together as
a team is usually better than by yourself no matter how much you think working
alone may be better for you. In my opinion the more heads the better off you
are to an extent. I mean of course the people on the team have to have a
similar mindset and all striving towards one goal, but as long as that is the
case things usually go a bit better. The team keeps itself in check and egos
are hard to get in the way. I do get though that most of us computer guys and
gals are geeks and don’t work well with others in a normal sort of way (whatever
the definition of normal is) but we do however work together well with one
another I think. Like he says though, there are of course times when it is
right to work alone and that is fine, but I like his idea of it being best to
collaborate with others and pair a large fraction of the time.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Clean Coder Chapters 11 and 12

This is an interesting chapter. I have been in many different
types of high pressure situations, some that required in the moment think on
your toes stuff in the military and other just plain old the boss or company
wants this and wants it yesterday type stuff, but to be honest I have never given
it much thought as far as what I do in or out of crisis. I like how he keeps
hammering home to not make commitments you cannot keep though, that will cause
a crisis for sure. A good bit of his points are in my opinion common sense ways
to avoid unneeded pressure. Keep your code clean, keep your system and design
clean etc., but others I had never given thought to, especially in th crisis
part where he says, “You know what you believe by observing yourself in a
crisis.”, so true. Thinking back on my life and some of the situations I have
been in I have thrown out the norm of doing things and switched to a whole new
set of rules, but I think in some cases that needs to happen. I do agree though
that in this field you should stick with what works for you in and out of
crisis as there should be no need to change how you do things as long as you
have a system that is efficient and clean.
 
He gives some great tips that should be lived by, don’t
panic, communicate, rely on your discipline, and get help. Those are great tips
and I like. I mean I guess it is easier said than done, but practicing these things
outside of crisis will make you handle them better. The biggest pieces of
advice I could give from this and he says also is “SLOW DOWN, COMMUNICATE, and
get HELP!!”. There is nothing worth a heart attack or stress related illness
over a job. Calm, cool and collective they say. Communication is huge and goes
hand in hand with the get help part. Speak up, don’t be afraid to ask questions
or for help, this isn’t grade school and no one is going to blow you off or
laugh at you. I think the best tip is avoid pressure if you can.

The more of the book that I read the more I think it grows on
me in a way. I see so much of what he has gone through in my own life and the
trials I have endured. It fascinates me that no matter what industry you are
in, it seems like you run into the same scenarios or strategies. I know this
chapter is about collaboration and I agree with him in that working together as
a team is usually better than by yourself no matter how much you think working
alone may be better for you. In my opinion the more heads the better off you
are to an extent. I mean of course the people on the team have to have a
similar mindset and all striving towards one goal, but as long as that is the
case things usually go a bit better. The team keeps itself in check and egos
are hard to get in the way. I do get though that most of us computer guys and
gals are geeks and don’t work well with others in a normal sort of way (whatever
the definition of normal is) but we do however work together well with one
another I think. Like he says though, there are of course times when it is
right to work alone and that is fine, but I like his idea of it being best to
collaborate with others and pair a large fraction of the time.

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.