Author Archives: c-braley

Software Craftsman Chapters 5 and 6

Chapter 5

I have to say it
seems like just after I get done with a decent chapter I move on to
the next and boom! You can tell that this is an Uncle Bob series
book. I am so tired of hearing the word professionalism and
professional that I want to puke. I am going to keep this chapter’s
blog short. Maybe it is because I have been through a lot of the
scenarios he talks about that I get irritated. This chapter is almost
exactly like a chapter that Bob wrote in the clean coder. Never say
I’ll try and get it done because the boss takes that as you will,
don’t over exert yourself or you’ll get burnt out, you can’t
code good at 3am, sleeping in the parking lot and getting a horrible
nights sleep is a bad idea etc. I get that it is important to learn
how to say no, and not commit to something you know you can’t
deliver even if it means getting that nasty look from your boss or a
guilt laden trip from hell. I just think it is over done in the
series. I understand that important things need to be reinforced, but
I think it is over done here. I will stop ranting now, because the
book does have its good points, I just am not fond if certain
chapters.

Chapter 6

I do have to say
that this book seems to alternate good and bad chapters to me. This
chapter I thought was informative and had some useful stuff. I agree
with these guys on their stance of having clean code and working
software, or being a software craftsman if you will. He hits on many
things in this chapter and something stood out to me right off the
bat. He said that “some organizations believe that with a good
management team, deep hierarchies, micromanagement, strict process
and a large amount of good documentation and the project will
succeed.” One other line was that many organizations see developers
as lesser skilled than the higher qualified managers. He hit the nail
on the head with those two statements. I have seen this in most every
industry I have worked in. They always seem to forget that us
underlings are the cogs that keep the machine turning. That is not to
say that good management isn’t important, I just think there is a
lot of backwards thinking and it is maybe because they pay the
management ludicrous numbers and they need some way to justify it?

I also thought that
his stance on working software is not enough was well done and very
true. I think there are a lot of hacks in every trade that thinks
that good enough is ok. I firmly believe that you should take care of
your code like you are looking after your garden. It needs to be
weeded and groomed and fed to ripen and blossom. It is like a living
being it seems to me. Especially after working on the Ampath project
and seeing how projects work and the communication and all of the
collaborators working together. He says the cost of dealing with bad
code can make companies less competitive and I agree. It reminds me
of a saying my father used to say to me, “Don’t do it half ass
because you’re just going to have to do it over again and it will
take twice as long as if you’d just done it right in the first
place.” I can’t argue with that wisdom as I found out the hard
way a few times more than I care to admit.

Over all I really
enjoyed this chapter and took away some things from it. I really hope
that I don’t end up working for a company like some of the
nightmares he was talking about. So much about Agile development
makes sense and on paper is grand, I just hope that at least some of
the methods are employed when I get out there.

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

Software Craftsman Chapters 5 and 6

Chapter 5

I have to say it
seems like just after I get done with a decent chapter I move on to
the next and boom! You can tell that this is an Uncle Bob series
book. I am so tired of hearing the word professionalism and
professional that I want to puke. I am going to keep this chapter’s
blog short. Maybe it is because I have been through a lot of the
scenarios he talks about that I get irritated. This chapter is almost
exactly like a chapter that Bob wrote in the clean coder. Never say
I’ll try and get it done because the boss takes that as you will,
don’t over exert yourself or you’ll get burnt out, you can’t
code good at 3am, sleeping in the parking lot and getting a horrible
nights sleep is a bad idea etc. I get that it is important to learn
how to say no, and not commit to something you know you can’t
deliver even if it means getting that nasty look from your boss or a
guilt laden trip from hell. I just think it is over done in the
series. I understand that important things need to be reinforced, but
I think it is over done here. I will stop ranting now, because the
book does have its good points, I just am not fond if certain
chapters.

Chapter 6

I do have to say
that this book seems to alternate good and bad chapters to me. This
chapter I thought was informative and had some useful stuff. I agree
with these guys on their stance of having clean code and working
software, or being a software craftsman if you will. He hits on many
things in this chapter and something stood out to me right off the
bat. He said that “some organizations believe that with a good
management team, deep hierarchies, micromanagement, strict process
and a large amount of good documentation and the project will
succeed.” One other line was that many organizations see developers
as lesser skilled than the higher qualified managers. He hit the nail
on the head with those two statements. I have seen this in most every
industry I have worked in. They always seem to forget that us
underlings are the cogs that keep the machine turning. That is not to
say that good management isn’t important, I just think there is a
lot of backwards thinking and it is maybe because they pay the
management ludicrous numbers and they need some way to justify it?

I also thought that
his stance on working software is not enough was well done and very
true. I think there are a lot of hacks in every trade that thinks
that good enough is ok. I firmly believe that you should take care of
your code like you are looking after your garden. It needs to be
weeded and groomed and fed to ripen and blossom. It is like a living
being it seems to me. Especially after working on the Ampath project
and seeing how projects work and the communication and all of the
collaborators working together. He says the cost of dealing with bad
code can make companies less competitive and I agree. It reminds me
of a saying my father used to say to me, “Don’t do it half ass
because you’re just going to have to do it over again and it will
take twice as long as if you’d just done it right in the first
place.” I can’t argue with that wisdom as I found out the hard
way a few times more than I care to admit.

Over all I really
enjoyed this chapter and took away some things from it. I really hope
that I don’t end up working for a company like some of the
nightmares he was talking about. So much about Agile development
makes sense and on paper is grand, I just hope that at least some of
the methods are employed when I get out there.

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

Software Craftsman Chapters 5 and 6

Chapter 5

I have to say it
seems like just after I get done with a decent chapter I move on to
the next and boom! You can tell that this is an Uncle Bob series
book. I am so tired of hearing the word professionalism and
professional that I want to puke. I am going to keep this chapter’s
blog short. Maybe it is because I have been through a lot of the
scenarios he talks about that I get irritated. This chapter is almost
exactly like a chapter that Bob wrote in the clean coder. Never say
I’ll try and get it done because the boss takes that as you will,
don’t over exert yourself or you’ll get burnt out, you can’t
code good at 3am, sleeping in the parking lot and getting a horrible
nights sleep is a bad idea etc. I get that it is important to learn
how to say no, and not commit to something you know you can’t
deliver even if it means getting that nasty look from your boss or a
guilt laden trip from hell. I just think it is over done in the
series. I understand that important things need to be reinforced, but
I think it is over done here. I will stop ranting now, because the
book does have its good points, I just am not fond if certain
chapters.

Chapter 6

I do have to say
that this book seems to alternate good and bad chapters to me. This
chapter I thought was informative and had some useful stuff. I agree
with these guys on their stance of having clean code and working
software, or being a software craftsman if you will. He hits on many
things in this chapter and something stood out to me right off the
bat. He said that “some organizations believe that with a good
management team, deep hierarchies, micromanagement, strict process
and a large amount of good documentation and the project will
succeed.” One other line was that many organizations see developers
as lesser skilled than the higher qualified managers. He hit the nail
on the head with those two statements. I have seen this in most every
industry I have worked in. They always seem to forget that us
underlings are the cogs that keep the machine turning. That is not to
say that good management isn’t important, I just think there is a
lot of backwards thinking and it is maybe because they pay the
management ludicrous numbers and they need some way to justify it?

I also thought that
his stance on working software is not enough was well done and very
true. I think there are a lot of hacks in every trade that thinks
that good enough is ok. I firmly believe that you should take care of
your code like you are looking after your garden. It needs to be
weeded and groomed and fed to ripen and blossom. It is like a living
being it seems to me. Especially after working on the Ampath project
and seeing how projects work and the communication and all of the
collaborators working together. He says the cost of dealing with bad
code can make companies less competitive and I agree. It reminds me
of a saying my father used to say to me, “Don’t do it half ass
because you’re just going to have to do it over again and it will
take twice as long as if you’d just done it right in the first
place.” I can’t argue with that wisdom as I found out the hard
way a few times more than I care to admit.

Over all I really
enjoyed this chapter and took away some things from it. I really hope
that I don’t end up working for a company like some of the
nightmares he was talking about. So much about Agile development
makes sense and on paper is grand, I just hope that at least some of
the methods are employed when I get out there.

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

Software Craftsman Chapters 5 and 6

Chapter 5

I have to say it
seems like just after I get done with a decent chapter I move on to
the next and boom! You can tell that this is an Uncle Bob series
book. I am so tired of hearing the word professionalism and
professional that I want to puke. I am going to keep this chapter’s
blog short. Maybe it is because I have been through a lot of the
scenarios he talks about that I get irritated. This chapter is almost
exactly like a chapter that Bob wrote in the clean coder. Never say
I’ll try and get it done because the boss takes that as you will,
don’t over exert yourself or you’ll get burnt out, you can’t
code good at 3am, sleeping in the parking lot and getting a horrible
nights sleep is a bad idea etc. I get that it is important to learn
how to say no, and not commit to something you know you can’t
deliver even if it means getting that nasty look from your boss or a
guilt laden trip from hell. I just think it is over done in the
series. I understand that important things need to be reinforced, but
I think it is over done here. I will stop ranting now, because the
book does have its good points, I just am not fond if certain
chapters.

Chapter 6

I do have to say
that this book seems to alternate good and bad chapters to me. This
chapter I thought was informative and had some useful stuff. I agree
with these guys on their stance of having clean code and working
software, or being a software craftsman if you will. He hits on many
things in this chapter and something stood out to me right off the
bat. He said that “some organizations believe that with a good
management team, deep hierarchies, micromanagement, strict process
and a large amount of good documentation and the project will
succeed.” One other line was that many organizations see developers
as lesser skilled than the higher qualified managers. He hit the nail
on the head with those two statements. I have seen this in most every
industry I have worked in. They always seem to forget that us
underlings are the cogs that keep the machine turning. That is not to
say that good management isn’t important, I just think there is a
lot of backwards thinking and it is maybe because they pay the
management ludicrous numbers and they need some way to justify it?

I also thought that
his stance on working software is not enough was well done and very
true. I think there are a lot of hacks in every trade that thinks
that good enough is ok. I firmly believe that you should take care of
your code like you are looking after your garden. It needs to be
weeded and groomed and fed to ripen and blossom. It is like a living
being it seems to me. Especially after working on the Ampath project
and seeing how projects work and the communication and all of the
collaborators working together. He says the cost of dealing with bad
code can make companies less competitive and I agree. It reminds me
of a saying my father used to say to me, “Don’t do it half ass
because you’re just going to have to do it over again and it will
take twice as long as if you’d just done it right in the first
place.” I can’t argue with that wisdom as I found out the hard
way a few times more than I care to admit.

Over all I really
enjoyed this chapter and took away some things from it. I really hope
that I don’t end up working for a company like some of the
nightmares he was talking about. So much about Agile development
makes sense and on paper is grand, I just hope that at least some of
the methods are employed when I get out there.

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

Software Craftsman Chapters 5 and 6

Chapter 5

I have to say it
seems like just after I get done with a decent chapter I move on to
the next and boom! You can tell that this is an Uncle Bob series
book. I am so tired of hearing the word professionalism and
professional that I want to puke. I am going to keep this chapter’s
blog short. Maybe it is because I have been through a lot of the
scenarios he talks about that I get irritated. This chapter is almost
exactly like a chapter that Bob wrote in the clean coder. Never say
I’ll try and get it done because the boss takes that as you will,
don’t over exert yourself or you’ll get burnt out, you can’t
code good at 3am, sleeping in the parking lot and getting a horrible
nights sleep is a bad idea etc. I get that it is important to learn
how to say no, and not commit to something you know you can’t
deliver even if it means getting that nasty look from your boss or a
guilt laden trip from hell. I just think it is over done in the
series. I understand that important things need to be reinforced, but
I think it is over done here. I will stop ranting now, because the
book does have its good points, I just am not fond if certain
chapters.

Chapter 6

I do have to say
that this book seems to alternate good and bad chapters to me. This
chapter I thought was informative and had some useful stuff. I agree
with these guys on their stance of having clean code and working
software, or being a software craftsman if you will. He hits on many
things in this chapter and something stood out to me right off the
bat. He said that “some organizations believe that with a good
management team, deep hierarchies, micromanagement, strict process
and a large amount of good documentation and the project will
succeed.” One other line was that many organizations see developers
as lesser skilled than the higher qualified managers. He hit the nail
on the head with those two statements. I have seen this in most every
industry I have worked in. They always seem to forget that us
underlings are the cogs that keep the machine turning. That is not to
say that good management isn’t important, I just think there is a
lot of backwards thinking and it is maybe because they pay the
management ludicrous numbers and they need some way to justify it?

I also thought that
his stance on working software is not enough was well done and very
true. I think there are a lot of hacks in every trade that thinks
that good enough is ok. I firmly believe that you should take care of
your code like you are looking after your garden. It needs to be
weeded and groomed and fed to ripen and blossom. It is like a living
being it seems to me. Especially after working on the Ampath project
and seeing how projects work and the communication and all of the
collaborators working together. He says the cost of dealing with bad
code can make companies less competitive and I agree. It reminds me
of a saying my father used to say to me, “Don’t do it half ass
because you’re just going to have to do it over again and it will
take twice as long as if you’d just done it right in the first
place.” I can’t argue with that wisdom as I found out the hard
way a few times more than I care to admit.

Over all I really
enjoyed this chapter and took away some things from it. I really hope
that I don’t end up working for a company like some of the
nightmares he was talking about. So much about Agile development
makes sense and on paper is grand, I just hope that at least some of
the methods are employed when I get out there.

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

Software Craftsman Chapters 3 and 4

Chapter 3

I am finding it hard to get into this book. So far it seems like a re-write of the Clean coder but with different wording. I hope I am proven wrong as I progress further but so far I am kind of disappointed. Do we need a chapter devoted to talking about whether the skill of programming is a craft, trade, engineering, science, or an art and five definitions and metaphors for software craftsmanship? I can’t believe there are debates over this to be honest, I mean I was always taught that when you work you do your job to the best of your ability and put in an honest day of work for your pay. I think it should be common sense that no matter the profession, you should do it with pride and professionalism. Does it matter what you label it? I agree that there needs to be meetings like the Agile summit and all that to talk about practices and techniques that can help to improve coding efficiency as well as end product results as this happens with most trades and professions. New strategies are implemented and such, but work ethic and professionalism should be a given in my opinion. I guess there are folks out there that don’t know about this or maybe don’t care how their code or work looks as long as the paycheck keeps coming in, but I have found that these types usually don’t hold jobs long. Maybe I am being over critical, I just think the chapter was a bit much.
Chapter 4

This chapter is a bit better than the last, there are a lot of good points here and I feel a bit bad about condemning the book previously, but I am writing about my feeling on the book as I go and that is how I felt about chapter three. I enjoyed how he opened in the first couple of pages about the talk with his friend and his response to him after he told him how he hadn’t been promoted and how the company hadn’t sent him to seminars and such. “Who is in charge of your career?”, what a great comment and so true. I have met many people who have this attitude that the company owes them and should see how good they are and send them here and there. Well I got news for you, that is not how the world works. I hear it here at school and I too am sometimes caught up in the I wish we learned this or that and then come to my senses and realize that I have the tools to learn this stuff myself and that is how you get better.
There are many good points in this chapter. I am still in awe at how much there is out there to learn and the tech changes it seems daily. There is always something new to learn and a lot of this is new to me, not the learning part but the technology. I would have never thought about following blogs before coming back to school. I do have to work on who to follow however as there are so many out there. I am slowly finding a niche. I am slow to Twitter and social media and could use some work in that area. I am not sure why, maybe an age thing or I just haven’t tapped into its full potential yet.

The rest of the chapter is well done as well, but I am not going to go on and on, but it is, in my mind one of the most important things in this field, practice. If you aren’t practicing your craft, you lose a step. I didn’t know about katas until I read the clean coder and will one day give them a try. There is no excuse to not practice these days. The word though can throw you off though as some folks despise practice as it reminds them of the horrendous drills you had to do in sports and such. Coding practice though is much more fun as there are so many ways you can hone your skill set. Open source, katas, projects, etc. Choose something you like and it is a heck of a lot better.

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

Software Craftsman Chapters 3 and 4

Chapter 3

I am finding it hard to get into this book. So far it seems
like a re-write of the Clean coder but with different wording. I hope I am
proven wrong as I progress further but so far I am kind of disappointed. Do we
need a chapter devoted to talking about whether the skill of programming is a
craft, trade, engineering, science, or an art and five definitions and
metaphors for software craftsmanship? I can’t believe there are debates over
this to be honest, I mean I was always taught that when you work you do your
job to the best of your ability and put in an honest day of work for your pay.
I think it should be common sense that no matter the profession, you should do
it with pride and professionalism. Does it matter what you label it? I agree
that there needs to be meetings like the Agile summit and all that to talk
about practices and techniques that can help to improve coding efficiency as
well as end product results as this happens with most trades and professions.
New strategies are implemented and such, but work ethic and professionalism
should be a given in my opinion. I guess there are folks out there that don’t
know about this or maybe don’t care how their code or work looks as long as the
paycheck keeps coming in, but I have found that these types usually don’t hold
jobs long. Maybe I am being over critical, I just think the chapter was a bit
much.
Chapter 4

This chapter is a bit better than the last, there are a lot
of good points here and I feel a bit bad about condemning the book previously,
but I am writing about my feeling on the book as I go and that is how I felt
about chapter three. I enjoyed how he opened in the first couple of pages about
the talk with his friend and his response to him after he told him how he hadn’t
been promoted and how the company hadn’t sent him to seminars and such. “Who is
in charge of your career?”, what a great comment and so true. I have met many
people who have this attitude that the company owes them and should see how
good they are and send them here and there. Well I got news for you, that is
not how the world works. I hear it here at school and I too am sometimes caught
up in the I wish we learned this or that and then come to my senses and realize
that I have the tools to learn this stuff myself and that is how you get
better.
There are many good points in this chapter. I am still in
awe at how much there is out there to learn and the tech changes it seems
daily. There is always something new to learn and a lot of this is new to me,
not the learning part but the technology. I would have never thought about
following blogs before coming back to school. I do have to work on who to
follow however as there are so many out there. I am slowly finding a niche. I
am slow to Twitter and social media and could use some work in that area. I am
not sure why, maybe an age thing or I just haven’t tapped into its full
potential yet.

The rest of the chapter is well done as well, but I am not
going to go on and on, but it is, in my mind one of the most important things
in this field, practice. If you aren’t practicing your craft, you lose a step.
I didn’t know about katas until I read the clean coder and will one day give
them a try. There is no excuse to not practice these days. The word though can
throw you off though as some folks despise practice as it reminds them of the
horrendous drills you had to do in sports and such. Coding practice though is
much more fun as there are so many ways you can hone your skill set. Open
source, katas, projects, etc. Choose something you like and it is a heck of a
lot better.

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

Software Craftsman Chapters 3 and 4

Chapter 3

I am finding it hard to get into this book. So far it seems
like a re-write of the Clean coder but with different wording. I hope I am
proven wrong as I progress further but so far I am kind of disappointed. Do we
need a chapter devoted to talking about whether the skill of programming is a
craft, trade, engineering, science, or an art and five definitions and
metaphors for software craftsmanship? I can’t believe there are debates over
this to be honest, I mean I was always taught that when you work you do your
job to the best of your ability and put in an honest day of work for your pay.
I think it should be common sense that no matter the profession, you should do
it with pride and professionalism. Does it matter what you label it? I agree
that there needs to be meetings like the Agile summit and all that to talk
about practices and techniques that can help to improve coding efficiency as
well as end product results as this happens with most trades and professions.
New strategies are implemented and such, but work ethic and professionalism
should be a given in my opinion. I guess there are folks out there that don’t
know about this or maybe don’t care how their code or work looks as long as the
paycheck keeps coming in, but I have found that these types usually don’t hold
jobs long. Maybe I am being over critical, I just think the chapter was a bit
much.
Chapter 4

This chapter is a bit better than the last, there are a lot
of good points here and I feel a bit bad about condemning the book previously,
but I am writing about my feeling on the book as I go and that is how I felt
about chapter three. I enjoyed how he opened in the first couple of pages about
the talk with his friend and his response to him after he told him how he hadn’t
been promoted and how the company hadn’t sent him to seminars and such. “Who is
in charge of your career?”, what a great comment and so true. I have met many
people who have this attitude that the company owes them and should see how
good they are and send them here and there. Well I got news for you, that is
not how the world works. I hear it here at school and I too am sometimes caught
up in the I wish we learned this or that and then come to my senses and realize
that I have the tools to learn this stuff myself and that is how you get
better.
There are many good points in this chapter. I am still in
awe at how much there is out there to learn and the tech changes it seems
daily. There is always something new to learn and a lot of this is new to me,
not the learning part but the technology. I would have never thought about
following blogs before coming back to school. I do have to work on who to
follow however as there are so many out there. I am slowly finding a niche. I
am slow to Twitter and social media and could use some work in that area. I am
not sure why, maybe an age thing or I just haven’t tapped into its full
potential yet.

The rest of the chapter is well done as well, but I am not
going to go on and on, but it is, in my mind one of the most important things
in this field, practice. If you aren’t practicing your craft, you lose a step.
I didn’t know about katas until I read the clean coder and will one day give
them a try. There is no excuse to not practice these days. The word though can
throw you off though as some folks despise practice as it reminds them of the
horrendous drills you had to do in sports and such. Coding practice though is
much more fun as there are so many ways you can hone your skill set. Open
source, katas, projects, etc. Choose something you like and it is a heck of a
lot better.

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

Software Craftsman Chapters 3 and 4

Chapter 3

I am finding it hard to get into this book. So far it seems
like a re-write of the Clean coder but with different wording. I hope I am
proven wrong as I progress further but so far I am kind of disappointed. Do we
need a chapter devoted to talking about whether the skill of programming is a
craft, trade, engineering, science, or an art and five definitions and
metaphors for software craftsmanship? I can’t believe there are debates over
this to be honest, I mean I was always taught that when you work you do your
job to the best of your ability and put in an honest day of work for your pay.
I think it should be common sense that no matter the profession, you should do
it with pride and professionalism. Does it matter what you label it? I agree
that there needs to be meetings like the Agile summit and all that to talk
about practices and techniques that can help to improve coding efficiency as
well as end product results as this happens with most trades and professions.
New strategies are implemented and such, but work ethic and professionalism
should be a given in my opinion. I guess there are folks out there that don’t
know about this or maybe don’t care how their code or work looks as long as the
paycheck keeps coming in, but I have found that these types usually don’t hold
jobs long. Maybe I am being over critical, I just think the chapter was a bit
much.
Chapter 4

This chapter is a bit better than the last, there are a lot
of good points here and I feel a bit bad about condemning the book previously,
but I am writing about my feeling on the book as I go and that is how I felt
about chapter three. I enjoyed how he opened in the first couple of pages about
the talk with his friend and his response to him after he told him how he hadn’t
been promoted and how the company hadn’t sent him to seminars and such. “Who is
in charge of your career?”, what a great comment and so true. I have met many
people who have this attitude that the company owes them and should see how
good they are and send them here and there. Well I got news for you, that is
not how the world works. I hear it here at school and I too am sometimes caught
up in the I wish we learned this or that and then come to my senses and realize
that I have the tools to learn this stuff myself and that is how you get
better.
There are many good points in this chapter. I am still in
awe at how much there is out there to learn and the tech changes it seems
daily. There is always something new to learn and a lot of this is new to me,
not the learning part but the technology. I would have never thought about
following blogs before coming back to school. I do have to work on who to
follow however as there are so many out there. I am slowly finding a niche. I
am slow to Twitter and social media and could use some work in that area. I am
not sure why, maybe an age thing or I just haven’t tapped into its full
potential yet.

The rest of the chapter is well done as well, but I am not
going to go on and on, but it is, in my mind one of the most important things
in this field, practice. If you aren’t practicing your craft, you lose a step.
I didn’t know about katas until I read the clean coder and will one day give
them a try. There is no excuse to not practice these days. The word though can
throw you off though as some folks despise practice as it reminds them of the
horrendous drills you had to do in sports and such. Coding practice though is
much more fun as there are so many ways you can hone your skill set. Open
source, katas, projects, etc. Choose something you like and it is a heck of a
lot better.

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

Software Craftsman Chapters 3 and 4

Chapter 3

I am finding it hard to get into this book. So far it seems
like a re-write of the Clean coder but with different wording. I hope I am
proven wrong as I progress further but so far I am kind of disappointed. Do we
need a chapter devoted to talking about whether the skill of programming is a
craft, trade, engineering, science, or an art and five definitions and
metaphors for software craftsmanship? I can’t believe there are debates over
this to be honest, I mean I was always taught that when you work you do your
job to the best of your ability and put in an honest day of work for your pay.
I think it should be common sense that no matter the profession, you should do
it with pride and professionalism. Does it matter what you label it? I agree
that there needs to be meetings like the Agile summit and all that to talk
about practices and techniques that can help to improve coding efficiency as
well as end product results as this happens with most trades and professions.
New strategies are implemented and such, but work ethic and professionalism
should be a given in my opinion. I guess there are folks out there that don’t
know about this or maybe don’t care how their code or work looks as long as the
paycheck keeps coming in, but I have found that these types usually don’t hold
jobs long. Maybe I am being over critical, I just think the chapter was a bit
much.
Chapter 4

This chapter is a bit better than the last, there are a lot
of good points here and I feel a bit bad about condemning the book previously,
but I am writing about my feeling on the book as I go and that is how I felt
about chapter three. I enjoyed how he opened in the first couple of pages about
the talk with his friend and his response to him after he told him how he hadn’t
been promoted and how the company hadn’t sent him to seminars and such. “Who is
in charge of your career?”, what a great comment and so true. I have met many
people who have this attitude that the company owes them and should see how
good they are and send them here and there. Well I got news for you, that is
not how the world works. I hear it here at school and I too am sometimes caught
up in the I wish we learned this or that and then come to my senses and realize
that I have the tools to learn this stuff myself and that is how you get
better.
There are many good points in this chapter. I am still in
awe at how much there is out there to learn and the tech changes it seems
daily. There is always something new to learn and a lot of this is new to me,
not the learning part but the technology. I would have never thought about
following blogs before coming back to school. I do have to work on who to
follow however as there are so many out there. I am slowly finding a niche. I
am slow to Twitter and social media and could use some work in that area. I am
not sure why, maybe an age thing or I just haven’t tapped into its full
potential yet.

The rest of the chapter is well done as well, but I am not
going to go on and on, but it is, in my mind one of the most important things
in this field, practice. If you aren’t practicing your craft, you lose a step.
I didn’t know about katas until I read the clean coder and will one day give
them a try. There is no excuse to not practice these days. The word though can
throw you off though as some folks despise practice as it reminds them of the
horrendous drills you had to do in sports and such. Coding practice though is
much more fun as there are so many ways you can hone your skill set. Open
source, katas, projects, etc. Choose something you like and it is a heck of a
lot better.

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