Author Archives: c-braley

Week 4 Reflections

Ok so I think that I have learned a bit this sprint as a lot
of things were new to me. I think the first thing is it feels like the Scrum
side of things is finally rolling to where it actually makes sense to me and I
can see the benefits of it now that I am putting it to use. I like how it all
works and it helps to keep me organized and on track. It feels good to be
putting the tools of the trade to use. Aside from the Scrum side of things I
have learned a lot about Angular and the project we will be working on. I am
still finding it challenging as I have never used Angular before and am really
not familiar with Javascript aside from the basics and I feel like that it is
making it harder for me to grasp not knowing it ahead of time. I am having to
not only look up Angular stuff, but also referring to J.S. docs as well. It isn’t
hindering me that much just a bit more work than I had originally thought.
I was excited to get the OpenMRS standalone running, thanks
to some of the other classmates help with code that needed changing, but it was
definitely a great feeling. I didn’t have much of an issue getting it up and
running. The NG2-amrs build was a little more frustrating to get up and
running. I spent a good deal getting help from classmates as well as the README
(who would of thought that would be helpful right?) but I did get it going and
did cartwheels. A bit was stupid mistakes and not taking a break when I should
have, but that is part of the learning process. Come to find out, that was the
easy part so far.
I am now actually into the code, well the login/auth code
side of things and digging into the meat and potatoes of what we will be
working on. The goal up until now was to re-write the auth/login module to get
a better understanding of how Angular works and how Ng2-amrs login is working.
We as a team ended up breaking the story down into smaller more manageable
tasks so it wasn’t so overwhelming. Initially we had committed to re-writing
the whole module on one card, but split into re-writing the HTML/CSS component
first then digging into the actual auth/routing side of things. That made life
a bit smoother for me. I basically copied the HTML/CSS taking note of things
that I didn’t grasp, such as the Angular additions (I have a good understanding
of HTML/CSS). The challenge is in the writing of the actual Angular. I had to
do a lot of peaking at the original code as well bouncing back to
DOCS/README/Tutorials and other help sites, but got it done. I am still far
from fluent and need a lot of help I think to further my understanding, but I
am persistent and have more help than I could ask for and am not afraid to ask.
That is why we are here in the first place. I am still not 100% up to par on
the RESTful architecture and routing but I am getting there. The more I am
exposed and the more I write and do the more comfortable I am.

I guess to wrap it up for this Sprint, I have to say I am
pleasantly pleased so far and look forward to what is to come and to see how my
blog grows and I grow in the process. I am looking forward to learning more
about the Ng2-Amrs project and collaborating with other developers via the MRS
wiki and forums and digging into the issue tracker on the JIRA server (another
thing I know zero about and am looking forward to learning) and just how
everything fits together. It is great actually seeing the process unfold and learning
new things. Until the next learning reflection blog…..

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

Week 4 Reflections

Ok so I think that I have learned a bit this sprint as a lot
of things were new to me. I think the first thing is it feels like the Scrum
side of things is finally rolling to where it actually makes sense to me and I
can see the benefits of it now that I am putting it to use. I like how it all
works and it helps to keep me organized and on track. It feels good to be
putting the tools of the trade to use. Aside from the Scrum side of things I
have learned a lot about Angular and the project we will be working on. I am
still finding it challenging as I have never used Angular before and am really
not familiar with Javascript aside from the basics and I feel like that it is
making it harder for me to grasp not knowing it ahead of time. I am having to
not only look up Angular stuff, but also referring to J.S. docs as well. It isn’t
hindering me that much just a bit more work than I had originally thought.
I was excited to get the OpenMRS standalone running, thanks
to some of the other classmates help with code that needed changing, but it was
definitely a great feeling. I didn’t have much of an issue getting it up and
running. The NG2-amrs build was a little more frustrating to get up and
running. I spent a good deal getting help from classmates as well as the README
(who would of thought that would be helpful right?) but I did get it going and
did cartwheels. A bit was stupid mistakes and not taking a break when I should
have, but that is part of the learning process. Come to find out, that was the
easy part so far.
I am now actually into the code, well the login/auth code
side of things and digging into the meat and potatoes of what we will be
working on. The goal up until now was to re-write the auth/login module to get
a better understanding of how Angular works and how Ng2-amrs login is working.
We as a team ended up breaking the story down into smaller more manageable
tasks so it wasn’t so overwhelming. Initially we had committed to re-writing
the whole module on one card, but split into re-writing the HTML/CSS component
first then digging into the actual auth/routing side of things. That made life
a bit smoother for me. I basically copied the HTML/CSS taking note of things
that I didn’t grasp, such as the Angular additions (I have a good understanding
of HTML/CSS). The challenge is in the writing of the actual Angular. I had to
do a lot of peaking at the original code as well bouncing back to
DOCS/README/Tutorials and other help sites, but got it done. I am still far
from fluent and need a lot of help I think to further my understanding, but I
am persistent and have more help than I could ask for and am not afraid to ask.
That is why we are here in the first place. I am still not 100% up to par on
the RESTful architecture and routing but I am getting there. The more I am
exposed and the more I write and do the more comfortable I am.

I guess to wrap it up for this Sprint, I have to say I am
pleasantly pleased so far and look forward to what is to come and to see how my
blog grows and I grow in the process. I am looking forward to learning more
about the Ng2-Amrs project and collaborating with other developers via the MRS
wiki and forums and digging into the issue tracker on the JIRA server (another
thing I know zero about and am looking forward to learning) and just how
everything fits together. It is great actually seeing the process unfold and learning
new things. Until the next learning reflection blog…..

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 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.

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 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.

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 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.

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 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.

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 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.

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 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.

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 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.

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 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.

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