Software Craftsmanship is an alternative way of thinking about the activity of writing computer software and skill acquisition mechanisms. It is a growing movement amongst software developers dissatisfied by the mainstream software industry’s focus on the skill-level of the median programmer.

In December of 2008, a summit was held in Chicago that resulted in the drafting of the Software Craftsmanship Manifesto:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration,but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

© 2009, the undersigned. this statement may be freely copied in any form, but only in its entirety through this notice.

Although we are using code generation more and more, shifting some responsibilities away from the average developer, we still need to keep crap code at bay. When we upgrade to model-driven development, we switch to the trade of keeping crap models at bay. A Software Craftmanship orientation is here to stay and we should embrace it.

In-house code generators help implement a Software Craftsmanship initiative by enforcing the use of correct and tried-and-tested designs and patterns.

Read more about Software Craftsmanship (books @ Amazon):

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman
Clean Code: A Handbook of Agile Software Craftsmanship
Software Craftsmanship: The New Imperative
The Craftsman

I’ve just signed the manifesto. Did you?

I’m sure it happens to you. As much as you try to guess in advance all the problems you may find during development, you’ll end up fighting some problem for hours. You think it over and over again. And again. A solution is nowhere to be found.

It happened to me several (too many) times. Most of the time, after much fight, I end up reaching a solution. But on a few occasions, something startling happened: After quitting, usually because time ran out that day, I return the other day and find a solution in five minutes or less! And a simple one. “So easy!… Why didn’t I think of that yesterday????”

I start to wonder how much time I wasted by not quitting to fight the problem.

So from now on I decided to have a new approach to problem-solving: If it starts to take too long to solve, I move on to something else, and leave it for tomorrow or the other day. And I advise you to do the same. You’ll end up saving time.

The reason for this quite surprising effect lies on the fact that when we have a problem, we set a series of reasoning “paths” that, unfortunately, lead us to the same “solution candidates” over and over again. At a certain point, we cannot deviate from those paths anymore. We become stuck, or run in circles.

If we leave the problem behind for some time, we have the chance to rebuild those reasoning paths again, hopefully in new directions. But don’t leave it for too long. That’s because there is always important information you must retain to be able to solve the problem. The longer you leave it, the harder it gets to get started again.

Knowing when to quit helps you save time solving problems. Think about it.