Code Obsession

Software craftsmanship is the new fad to replace ALT.NET and Agile as the cool thing to do if you actually like writing software. This post is inspired by a recent post by Whitney Hess about UX designers. There is a lot of debate about that software craftsmanship means. See my previous post so you can get started on your education. YOU’RE NOT A SOFTWARE CRAFTSMAN IF… You don't write code as a primary function of your job. Software craftsmanship is about crafting software . It isn't about being a manager, scrum master or (PowerPoint) architect. It's about creating code that helps people. If you are once involved directly in code, this doesn't count. A craftsman is involved in the craft, not a parallel/supporting craft. You aren't reading. Blogs, books, magazines (really? do people still get magazines?) are great sources of collective experience. You can't learn do it all on your own, so a wise programmer (person) attempts to learn from the experience of oth...

What is a craftsman? What is a Software Craftsman? There is a lot of debate. Educate yourself and make up your own mind... This is a little old, but I wanted to make it available so that I could reference it in another post. The Manifesto The Software Craftsmanship Manifesto The Book Software Craftsmanship: The New Imperative The Other Book Apprenticeship Patterns - Guidance for the Aspiring Software Craftsman Pete McBreen's Response to The Manifesto Software Craftsmanship Revisited David Harvey speaks to the topic Danger! Software Craftsmen at Work Dan North starts a war Programming is not a craft Liz Keogh explains her discomfort with the software craftsmanship manifesto Why I didn’t sign the Software Craftsmanship manifesto Gil Zilberfeld draws a comparison between software craftsmanship and alt.net The Path Already Taken Jason Gorman wants us to avoid getting hung up on labels Enough With The Software Holy Wars! Michael Feathers looks for more deliberate practice in our work Th...

I have been playing with Ruby recently and it has lead me to want a couple of methods off of commonly used objects. I have found myself typing each and times into my VS editor regularly rather than curse my primary language, I decided that I should just implement the the missing functions. It is surprisingly easy to do. Here are some snippets for you to drop into a static class: //Each & Times public static void Each<T>(this IEnumerable<T> enumerable, Action<T> block) { foreach (T item in enumerable) { block.Invoke(item); } } public static void Times(this int count, Action block) { for (int i = 0; i < count; i++) { block.Invoke(); } } public static void Times(this int count, Action<int> block) { for (int i = 0; i < count; i++) { block.Invoke(i); } } The usage should be fairly straightforward, but just in case you need a pointer, here is some code I took from one of my Bowling Game Kata practice sessions: 21.Times(() => _game.Roll(0...

This is another book in the project management vein. I put it in my Amazon wish list about a year and a half ago, though I only recently got around to buying it. I had a manager strongly dissuade me from reading it based on title. Apparently, Zombies are not approved work fare. ;-) On the one hand, this book was a fascinating read because so many of the patterns were familiar. Seeing that my experiences haven't been unique, but are often common enough that they have been identified and named was interesting to me. On the other hand, it was a little bit depressing because I had hoped that the industry was more mature than what I have experienced. Apparently, there is a lot of opportunity for improvement everywhere. The idea of using patterns to describe software development project behaviors struck me as quite appropriate. Unfortunately, the book mostly just presents anecdotes and stories. The patterns all have catchy, if sometimes misleading, names and all have a distillation of ...