Tuesday, February 21, 2017

Clean Coder Chapters 9 and 10

Chapter 9: Time Management

This is a very interesting chapter as everything revolves around time and it is something that we never seem to have enough of am I right? Of course I am. I myself have been trying for years to come up with some sort of consistence as far as a schedule goes, but with my situation up until I started with college was different as I am on disability so I tried to keep to a regular schedule so I didn’t get caught in some weird time continuum while I figured out my next step. I have found it difficult to manage time while in school though and try to set a schedule, but each semester that changes and well I get out of sync. Thank goodness this is the final semester (well until grad school if I go that route) and I will hopefully be gainfully employed shortly thereafter. Anyways I suppose I should get back to the chapter at hand, time management. I found it amusing how he referred to meetings as necessary and huge time wasters because it is so true no matter what your job is. I never gave much thought about how much per person it actually costs for a meeting. There are a lot of good points in the chapter concerning meetings in general, but a lot of it is in my opinion common sense. Have and agenda and a goal. Well of course there is an agenda and a goal, I know there are a lot of times where meetings don’t seem to have either but there generally is. I really like the stand up meeting like we are suppose to do for Agile development. Twenty seconds per question, no more than a minute per person; in, out, done the way it should be in my opinion. Short, sweet, and to the point I say. No beating around the bush. I liked his quote from Kent Beck, “Any argument that can’t be settled in five minutes can’t be settled by arguing.”. Awesome words of wisdom. There are a decent amount of items in this chapter I really enjoyed, especially how he compared stuff to D & D type games, like focus manna, if you use up all your focus manna in the meeting, you’ll have none left for coding, how very true indeed.

Time Boxing and Tomatoes. I am definitely going to give this a shot. I think it is a really great idea to set a timer and let nothing interfere with your plan, actually carrying out to a tee may be a different story but still worth a shot none the less. I love it; dividing your time between tomato and non tomato time. I am actually laughing right now thinking about it, how many tomato’s did you get done today Jim?  Only 15, slacker! Over all I thought this chapter was well done and a very important, if not one of the most important things that needs to be worked out. If you can’t learn how to manage time effectively and overcome adversity when something hinders your plans, you will have a hard time getting things done and you will probably find yourself moving out of a job versus up in the job.

Chapter 10 Estimation:

I really like how he put it right out there in the first sentence. “Estimation is one of the simplest, yet most frightening activities that software professionals face. So much business value depends on it. So much of our reputations ride on it. So much of our angst and failure are caused by it. It is
the primary wedge that has been driven between business people and developers. It is the source of nearly all the distrust that rules that relationship.”


He hits the nail on the head as far as what an estimate is and how they are interpreted differently. As commitments and guesses. In reality an estimate is just a guess at when you think you will be done, however they are never set hard in stone, but the issue is that the business man hears oh it will be done by such and such date, great. I mean there really isn’t much that I have to say on this chapter other than when I give an estimate, I try and be as clear as possible and look at all the facts and take in all the information that I have and add on some extra time just in case it falls through. I also make sure that I communicate if anything isn’t going according to plan and adjust accordingly. There were a lot of great techniques he described, but I think it is something that has to be learned by doing, and by making mistakes.

No comments:

Post a Comment