The laborer basically works with the tools he has for as long as needed to get the job done. The craftsman always pushes his environment to the max, creating new tools along the way to improve productivity and reduce the amount of manual labor.
The craftsman attitude yields a number of benefits:
- By creating new tools, the craftsman skills are continuously sharpened beyond basic labor
- Productivity is increased on the long run
- Attitude remains upbeat and enthusiastic through out the greater challenges involved with craftsmanship
So, what kind of worker are you? A craftsman or a laborer?
2 comments:
Being of a philosophical bent of mind, I've learned to be suspicious of false dichotomies. What you describe as a "laborer" really encompasses much of what software developers do on a day to day basis, and necessarily so I think, or else we would be engaging in too many diversions. There is always a balance to be struck.
Here's something else to consider: it's tempting to consider the tools of our craft in a heterogeneous fashion. But in reality, they're actually stacked on top of each other in such a way that we have to hold one level of tools constant in order to innovate at another level. That's a rather formalistic way of saying that, in order to innovate in an area like Ruby metaprogramming for example, I have to have tools like an OS and a compiler, which I more or less "work with for as long as I need to get the job done." So I'm approaching one layer of tools as a laborer, so that I can approach another level as a craftsman. So the dichotomy isn't as simple as it seems.
Well said, Fred.
Let's focus then on what we can learn from the constrast between laborers and craftsmen even if it is not absolutely true. The point I gather is to always seek continuous improvement instead of just sticking with the status quo.
For example, while some developers may be content writing Struts and EJB 2.1 web applications, others may be always seeking better tools like Spring and Hibernate, or Rails and ActiveRecord.
In fact, if the latter developers had to work with Struts and EJB 2.1 on a project, I bet they would write their own layers and tools on top of them to compensate for the framework weaknesses and/or apply new concepts borrowed from other better frameworks.
I actually knew someone who adapted Hibernate to ActiveRecord pattern on a Java EE project after having been exposed to the Ruby on Rails framework.
Post a Comment