You’re not a software craftsman if…

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…

1. 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.
   
   
2. 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 others. Personally, I would say you need to read at least 1 book per quarter and subscribe to a few blogs as well. My RSS feed list is over to the right somewhere. I don't read all the posts of course, but I read a lost of them.
   
   
3. You aren't working to solve a business need. Coding is great fun! Code can be art. If you aren't concerned with RIO (and this includes schedule,) you are not respecting the craft or the client. Artesanal software is lovely. Save it for open source projects done on your own time. Don't make your client pay for art, unless they ask for art. 999 times out of 1000, they ask for features. (There should probably be more 9s there.)
   
   
4. You aren't participating in your community. There are plenty of ways to get involved. You can blog, tweet, go to user groups (.NET, Ruby) and contribute to open source. You need to be involved to be a craftsman. You can't work in isolation. If you don't have a user group in your area, create one at work. I have done this at my last few jobs and it is an amazing way to improve the quality and quantity of the output of your shop.
   
   
5. You aren't willing to learn from others. No one knows everything. Expose Your Ignorance isn't just for beginners. Almost everyone on your team knows more than you about something: (one of) the language(s), the domain, the data, something. Let them teach you. Seek out the knowledge they have. Paired programming is the easiest way I know to share knowledge amongst the developers on a team. Try it out.
   
   
6. You horde your knowledge or act superior when you share it. We all learned from someone and we all need to learn from others. Sure you have original thoughts, ideas, and solutions, but they are based on what you learned from others and you shouldn't keep them from your team. If you are a dick when you explain set-based logic or design patterns, etc., people will stop asking you questions. This will prevent you from sharing and succeeding as a craftsman.
   
   
7. You aren't improving your skills. Craftsmen value skill both in themselves and in others. Practice, practice, practice. Then you can produce finer work when it is time to produce. Find your weaknesses and do something to improve in those areas. My C# and TSQL are strong, but web-fu (CSS, JavaScript) is kinda weak and so is my PL/SQL. I'm working on 'em.
   
   
8. You aren't validating your code. For me this means automated tests both at the unit level and the acceptance level. For you this could mean manual regression after each feature. Actually, I think I would need to be convinced of the second option. You are in the business of automating work, but you do your own manually? Really? WTF? Automate that! We all know manual regression tests are boring and error prone.
   
   
9. You only know one technology stack. This one is hard for me because I am a .NET developer. I have been doing C# since it came out and VB6/ASP/Visual C++ before that. I have been on the Microsoft stack for almost my whole career. I know ASP.NET (WebForms & MVC), WinForms, WCF, SQLServer, IIS and Windows Server configuration. I don't know much about everything else. A craftsman needs to be able to compare and contrast more than one paradigm. I have been trying to learn Ruby (w/Rails) development on Ubuntu for a year+. I have read about half of Seven Languages in Seven Weeks and some of Rails for .NET Developers. It is hard to learn just for the sake of learning. The truth is you need to. Ruby has taught me better ways to C#. My JavaScript has improved once I learned what a prototype language is and (some of) how jQuery works.
   
   
10. You aren't passionate about code. When was the last time you were in an argument about what to name a variable? Software craftsmen care deeply about doing the right thing for the code and for the client. If this is just a way to pay the bills (and buy toys,) you are a laborer (code monkey.) If you aren't passionate, you aren't a craftsman.
    
    
11. You aren't regularly delivering value. This means releasing on a scheduled cycle. It should be a short cycle.
    
    
12. You don't take responsibility for your own education. It is awesome when employers provide training. If yours doesn't, you can't use that as an excuse to stagnate. Find a mentor. Be a mentor. You and you alone is responsible to ensure that you stay current and relevant in this industry. I have never seen an resume with an "Excuses for why I only know a dead technology" section. If I did, I might laugh, but I wouldn't hire the guy.

So, what would you add to this list? What would you take off?

I have written 3 previous versions of this article and thrown them all away because they didn't quite say what I meant. Hopefully this time it came together well.