Are You A Hacker Or A Craftsman?

It's usually viewed as an either/or type of thing: Either you're a hacker, or you're a craftsman.  The problem with any discussion around this is that the words have no clear and fixed definition.  They mean something different to everyone.  So conversations about this end up largely unproductive as everyone keeps talking past one another.

Lets start here.  Hackers are generally characterized as rebels quickly banging out some code that does something impressive, but the code is unmaintainable crap that no one else can understand.  And the hacker is generally only concerned with short term goals.  On the other hand, craftsman are characterized as deliberately and carefully designing beautiful code, but it takes them forever and they're encombered by things like tests and principles and patterns.  And the craftsman is usually looking ahead to the long term (at least where maintenance is concerned).

I don't think these either/or characterizations are useful.  Here's a completely different take on "Hacker" from Rands in Repose talking about Facebook.  He characterizes hackers as "believing something can always be better", and not accepting limitations preventing them from making it better.  In the positive light, these "hackers" reject restrictive process and seek to be disruptive by doing new and better things.  In a negative light, these "hackers" reject collaboration, are unreasonable, unpredictable, and not motivated by the same goals as the business.

This is not even close to being the same as the colloquial meaning of "hacker," but its an interesting blend of hacker and craftsman.  It has the hacker's rebellious qualities, combined with the craftsman's broader vision.

And it's here that I think there is an interesting point to be made.  Hackers lose points for not caring about the future, or the long term.  And craftsmen lose points for losing sight of the broader objectives due to their uncompromising attention to code details.

Software development is nothing if not compromise.  The team that shits out awful code quickly gets done first*.  But then can't respond to change.  The perfectionists with 100% code coverage and perfect SOLID code come in last*.  But then can't effectively respond to change.

* Yes, asterisks.  The team that writes the awful code probably wont finish first, because they spend most of their time debugging.  And it's possible the team with 100% code coverage wont finish last, at least that's the argument, which you can believe if you want to (but I think it largely depends on your experience and your tooling).

I think it's pretty clear that there is a time for hacking, and there is a time for craftsmanship.  The real trick is figuring out at any given moment, which mindset you should be in.  And that requires a very broad understanding of the factors of the project, including: the vision of the product, the long term strategy, the short term goals, the complexity of the code, and the likelihood of change.  All of which is subject to change.  So good luck!!