Monthly Archives: March 2017

The Software Craftsman Chapter 3 & 4 (3/28/17)

Comparing “The Software Craftsman” book to the “Clean Coder” book, there is a good amount of material that overlaps from one book to another. Chapters 3 and 4 introduces the idea of what software craftsmanship is and the attitude behind being successful at it.

The most important and useful piece of information from these two chapters was the idea that “clients don’t pay professionals to learn; use your own time and money to get better at what you do.” We as professionals get paid for the skills we have to offer so it makes sense that it is our responsibility to keep our skills sharp and up-to-date. If not, we slowly start to become irrelevant and people will no longer rely on us because our skills aren’t as sharp as it used to be. If you want to be paid good, then you better have a good skill set to show for; don’t expect a promotion if you have nothing new to offer to your employer. Think about it, why would anyone pay you more money for doing the same amount / quality of work?

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 Software Craftsman: Chapters 3 & 4

Chapter 3 covers the topic of what exactly software craftsmanship is. The author generalizes it by stating its putting responsibility, professionalism, pragmatism, and pride into software development. He then goes on a long walk through of how software craftsmanship came to be and the history behind it. Basically software craftsmanship has been around since 1999 however it never really gained traction until about 2009 when the Manifesto was published online. The Software Craftsman Manifesto outlines four main values of a developer: 1) Not only working software, but also well-crafted software. 2) Not only responding to change, but also steadily adding value. 3) Not only individuals and interactions, but also a community of professionals. 4) Not only customer collaboration, but also productive partnerships. The author concludes with the main idea that software craftsmanship is a lifestyle and mindset of professionalism in software development and always striving to provide the best service to clients.

After reading chapter 3 I thought there were some really good points but I did think the history was a little drawn out for the reader. I agree with the manifesto the author laid out however everything he mentioned seemed to be common sense. It is also something that must be embraced by the entire business for it to be effective. While one developer could be a craftsman, it takes everyone to follow the manifesto for it to truly work and give the client the best experience possible. My favorite idea from this chapter was the ‘craftsman swap’ where developers from different companies would trade places and act as if they were a developer at another company for a week. This is a great way for teams to get an idea of what they could do better and sheds some light on how other companies are operating. Both teams benefit and can adopt the best practices from the combination of two teams. I can however see where competing companies may not want to have their competition directly working with their team to gain any kind of competitive edge. Overall, I think the Manifesto for craftsmanship holds good points any developer should be following and sets a higher standard for developers everywhere.

Chapter 4 covers the topic of attitude being a software craftsman. The author makes a point to make it clear that we as individuals are responsible for our own careers and continued learning. While it’s nice to work for employers who invest in their employees we are ultimately responsible for keeping ourselves trained and up to date. He goes on to talk about all the different ways we can keep up on our training so that we are always learning. First he mentions reading material in the form of books, blogs, or technical websites. The author does mention even beginner developers should keep a blog to document and track their progress. Next he talks about ways to practice. When practicing a problem it’s important to focus on how the problem is actually being solved and not just writing code that works. Katas which are short coding exercises or doing personal pet projects are also some suggested ways to get good practice in. Lastly the author touches upon time management. Many times we tell ourselves we are too busy but he insists to make time. We can do this by limiting habits like TV watching or social media use. He does make a point that there needs to be a good work life balance but to own your own career you must manage time wisely and keep your skills sharp outside of normal working hours.

After reading chapter 4 I noticed a lot of commonalities mentioned from Robert Martin’s Clean Coder. I strongly believe it is an individual responsibility to continue software learning at any career stage. Out of the ways mentioned I find myself following social media and blogs the most. With the speed that tools and technologies come out, blogs tend to have good early information and usually tutorials to help you learn. One thing I’m not sure I fully agree with is the Pomodoro Technique. While I think it may be useful for someone who’s off track, setting timers and keeping such a rigid schedule does not seem sustainable. Personally I know I would keep checking the time remaining which would hinder my focus. In conclusion my career will surely benefit from personal learning and proper time management skills.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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

Chapters 1 and 2 Software Craftsman

Chapter 1

One of the first things I noticed in this chapter and it
made me cringe is how people seemed to have thought back in the early 90’s in
how they measured seniority by how cryptic your code was. I am sure it wasn’t
everywhere but I remember people back then talking like that. How anyone ever
thought that was cool or what not is another issue for another time I guess but
wow memories come flooding back, not because I was a coder in the early 90’s
but I knew some and hung around them and I remember hearing stuff like this. I
laughed a few times as well in this chapter, especially when he was talking
about adding abstractions and design patterns all over the place and how today
it would be called overengineering and stupidity. It is amazing just how far we
have come I guess. He hits the nail on the head though in talking about choosing
your passion for work and what makes you happy. I see it in a lot of the young
folks today talking about oh how much money this and that, but never hear them
talking about finding something they would be happy doing. I never thought much
like that, of course I would like to make a lot of money, but if I am not happy
making it what’s the point?
I like his take on seniority as well and how it is transient
and relative. I think too many people in general judge seniority in numbers of
years and not quality of product. I have been many a place and seen people with
2 years of experience blow someone away that had 10. It is true though however
that there really is no senior or junior developers unless you reference what
senior or junior is as pertaining to a certain language I guess. It is
interesting to see how things evolve over the years in what our
responsibilities are or will be once employed. We need to be a sort of jack of
all trades in the sense that we will be doing many roles as we evolve up the
ladder. I am looking forward to see what the rest of the book has to offer.
Chapter 2

After reading this chapter I look at agile a new way. I
never gave much thought to the name until now. The definition of agile is “able
to move quickly and easily” hence the methodology being quick and short
feedback loops. I think that it is awesome that these guys got together and
basically changed the way we think and do. Doing things in short iterations
like this makes for smooth flow in my opinion and less of a chance of failing.
I love the first line of the manifesto, “Individuals and interactions over
process and tools”, it is quite the revelation to me and how I like to think.
It makes so much sense I wonder why it wasn’t done a long time ago. I mean if
everyone is involved and working together and “communicating” it is common
sense that thing should go smoother. Keeping people out of the loop on projects
makes for a mess that sometimes can’t be cleaned up. He is right in saying though
it doesn’t work unless there is a full transformation with everyone on board. I
mean that is like anything though in my opinion, you can’t half ass stuff or
you end up where you started and doing it all over again. It takes work, but I think
once the work is put in and results are seen it is a no brainer I would think.
The embracing of software craftsmanship is needed and I am beginning to like
that term. We are craftsmen and like craftsmen we should strive to become
better each day and utilizing the tools we can accomplish this.

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