You’re not a software craftsman if…
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 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.
- 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.)
- 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.
- 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.
- 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.
- 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.
- 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.
- You aren't regularly delivering value. This means releasing on a scheduled cycle. It should be a short cycle.
- 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.