Luciano

The bulk of your argument rests on the assertion that the use of higher-level tools bestows a higher level of ability on those using them, and that’s simply not the case. Tools (in the general sense, not just software tools) are things we use to reduce the work required to do something. To put it another way, they bring efficiency. But higher-level tools carry very pointy parts and will let you saw your own leg off if you’re not careful.

Software is no different than a lot of other pursuits in that putting powerful tools in the hands of the inexperienced doesn’t usually produce excellent results. What comes from experience is the ability to understand what a tool does (because odds are good you’ve already used something like it before or done it yourself) and how to wield it to do the work you want and do it well without sawing off a limb in the process.

Craftsmanship is what you get from someone who’s got enough experience to understand how to do the best possible job with the tools he has available regardless of their “level.”

Anybody can write functioning software, and if it works forever, that’s great. But the moment I have to stick my head under the hood and make repairs or changes, the level of craftsmanship determines how difficult my work is going to be. And I can tell you from experience that I’d much rather work on a piece of well-crafted code than something that would be featured at Coding Horror.

In some ways, I feel sorry for the younger generation, because they’re expected to reach into the cabinet, pull out the pointiest tools and start producing. I at least had the luxury of growing up with the industry and had time to soak in all of the innovations that led up to those tools.

–Mark

After programming for nearly 30 years in more than 20 languages/technologies, I think the “language/technology experience” isn’t worth very much – also not for youngsters. Technology/languages can be learned in one week to get going, a month to get to the top quartile if your good.

What is important in experience are all the errors and wrong decisions you’ve made over the years, not language knowledge.

Cheers
Stephan
http://twitter.com/codemonkeyism

Actually, my point was that software experimentation should *not* be rigid or controlled, because it misses the benefits of experimentation. The concept of a master craftsman and apprentice means that experimentation would be controlled, which is wrong.

–Omar

I think you’ve highlighted areas where the craftsmanship metaphor breaks down badly when applied to software. Innovation and collaboration is so important for our field. By evoking Guilds though, craftsmanship suggests a controlled stagnation for the benefit of the establishment. I think there is more to craftsmanship as an idea, however.

Anyone who clings to old technologies and frameworks is unlikely to outperform new tools in the long term because they are ignoring so much new accumulated knowledge. I picture a greying man rubbing punch cards between his fingers and sniffing the aroma while basking in the glow of green CRTs — it’s ridiculous. A similar scene of an aging vintner testing the soil of his vine fields doesn’t seem as silly.

It is possible in software to have experience beyond a particular framework or technology. This is where the distinction between experience levels become important, in my opinion. No web framework I’ve encountered prevents a developer from introducing a static field to one of their classes, but this is nearly always a bad idea in a web application. The team at twitter got their system up and running quickly, but hit a problem that had been solved years earlier with message-oriented-middleware. ORM frameworks like Hibernate make SQL nearly obsolete, but understanding of the N+1 selects problems remains important.

Knowledge of implementation details becomes obsolete as it is abstracted away. Understanding of software systems in action and how they behave does not. Even though the system is abstracted away for the developer at build-time, all the bulk of it is still there at run-time.