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.

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.

The Clean Coder: Chapters 11 & 12

The image from chapter 11 perfectly sums up my feelings about this week.

I’ve really enjoyed reading The Clean Coder I think Uncle Bob has made some very clear and important points. This week was quite short and so there is only so much to write for this post. This books is great for a student hasn’t begun working or an engineer who’s at his first job fresh out of college. However, for anyone who has worked in the “real-world”, we already know the things that are stated in chapters 11 & 12.

One of the more interesting topics that I never really had a name for was Crisis Discipline. This is something in my current field that is incredibly important. I work as an Air Quality Engineer. Part of my job is to execute wet sample extractions for pollutant sources per federally regulated methods. In these methods everything I need to do in order to get proper extraction of whatever pollutant I am looking for is written in stone. However, during the actually sample gathering there are ways you can “speed up” the process or “cut corners” to make the job easier. However, EVERY single time someone decides to do this (No one has in my company), it backfires and them. It usually lands them rerunning an entire testing program that may costs tens-of-thousands of dollars.

The next chapter interestingly talks about collaboration. This is something again, that as working person in a technical field, I have found that a second pair of eyes is ALWAYS better. I spent a lot of my earlier years building and fabricating anything from specialized flanges to electrical control boxes. When you spend time designing something and working on something, no matter how good you are, you will screw up. Period. End of discussion. I remember training a young technician on how to rewire a simple relay system that controls a heater block. When the technician had completed the task they simply put it back on the shelf.. Job done, right? This technician in particular had an issue with me always checking his work and I knew that I would do it forever and a day because we are human and humans are fallible. However, from his point of view, he thought I was always passively aggressively saying he wasn’t smart enough. So I decided to go out and check the heater anyways. I found that two of the wires were backwards, and that was going to cause the relay to stay closed 100% of the time which meant power was going to be continually supplied to the heater. The next morning I got in my normal time which was well before the rest of the technicians and I plugged the heater that he had worked on in. Long story short, when he had made it in to work he saw a BRIGHT cherry red heating element just about ready to melt through the metal casing. When he asked me what had happened I explained to him that is why I always check his work and why I always have other engineers check my work.

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

The Clean Coder Chapter 11 & 12 (2/21/17 – 2/28/17)

Have you ever heard of the term “working under pressure” and how some people say they work better and faster under pressure and stress?  As weird as it sounds, I believe that life is more fun with pressure. It makes the objective much more worth-while and you appreciate it a lot more when it is over and done with. However, on the opposite side of the spectrum, there are a handful of those who “crack under pressure” instead. I can’t speak for all professions but if you are a programmer; that is one thing you can’t do. Although I am not a full-time professional (YET!), I can certainly testify to that and after reading chapter 11 of the Clean Coder book, I’m sure the book can also testify to that as well!

If you feel as though you’ve never experienced “real pressure” before, just pick a decently lengthy assignment and don’t start on it until 30 minutes before its due and see if you can resist the urge to not quit and not go to a corner and cry (hahaha). Hey, its not the same as real professional pressure that you will get from work but its pretty close!

Chapter 12 of the Clean Coder book talks about collaborating and when it comes to that, it is not an option. I could go on forever about times when I was stuck on software code and had to ask others to help me solve it. Good software requires good programmers (notice the “s” at the end of programmer). So let go of your pride and ego and collaborate more!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The Clean Coder Chapters 11 & 12

In chapter 11 of The Clean Coder, Martin talks about how to deal with pressure and stress when it comes to deadlines. None of this stuff is really new to me, especially being a college student and having to deal with deadlines for projects. He goes over how, if you can, avoid pressure, but, if you can’t, make sure to communicate this properly to the people you work with. Mainly, don’t take your stress out on the people that work with and for you. Also, if you are going to miss a deadline, tell your bosses and team way in advance so that you can plan out how to fix that. He points out that you should always follow your disciplines when you are under pressure because you know that the way you’ve been doing things is the right way to get the work done. This makes sense because this prevents you from having a huge mess that you will, most likely, just have to clean up later and waste more time. The last thing he went over is making sure to work in pairs which is common sense in programming now-a-days. You need at least one other person just to review your work to make sure you aren’t so stressed that you miss major flaws in your design.

This leads into what chapter 12 is about, which is working with people. Again, I personally find most everything that Martin has stated in this chapter to be a “no duh” kind of situation. He goes on to talk about how you should pay attention to the business that you are in so you know what is going on there. He gives an anecdote about a time he was fired for being, to summarize his post, “too into the technology and not into the business.” His story basically turned out that he liked the work for the job, but he didn’t care about job etiquette or manners; this includes basic things like what to wear at the job, who the higher-ups are,showing up on time, etc. To me all of this stuff is a no-brainer. When you get a job you follow the dress code, you know the people, and you show up on time. If you don’t like those rules, then look for a different job that will take you. The other two things Martin talks about in this chapter is “owned” code and pairing. I simply agree with him on both of these points. I don’t think people should have code that is “just theirs” because that creates so many issues due to them not wanting their code to be reviewed. This obviously leads to multiple issues down the line. Also, as I’ve already stated, paired programming is effective, and working in teams makes sure that messes and bugs are caught early before major issues start to happen.

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 11 & 12 Week 6

The first part of the reading talks about pressure in the work place. Commitments are a big deal in a professional environment and while you should try to avoid them as best you can sometimes other people make them for you. You are not responsible for these commitments if you did not agree to them so you should not stress over them. Keeping everything clean will help reduce stress, so make sure to take the time to make sure your code is clean. I know that if I start coding quickly and dirty that it becomes a mess and I get stressed out. Don’t be too proud to get help, if you’re running behind find a co-worker that is willing to help you.

The second section talks about collaboration, it’s a very important part of programming, we can’t do it all ourselves sometimes. When working with a team do not “own” your code, make the code accessible available to change by anyone in the team. A lot of programmers did not get into their field to work with people, quite the opposite, most did because they don’t enjoy working with people. Unfortunately there is no way to avoid this, working with other programmers and clients cannot be avoided.

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