Falsely skilled developers

I agree with your assessment, Edward, that blind re-use of code is indication of a "morals deficit." Here we come back to what I call the "craftsman's imperitive," which is, put simply, to give a damn about doing a good job. Part of doing a good job as a programmer is to understand exactly what it is you are doing. If we blindly re-use something without understanding how it works (at least at a high level) and verifying that it is soundly constructed, then we are demonstrating laziness and apathy. There is no room for laziness or apathy in programming. Even if you hate your job and desire to perform poor work to spite your employer, there is a higher responsibility to not introduce more bad code in the world.

Edward points out two re-use scenarios: re-using code snippets and re-using packaged artifacts like components and frameworks. In the case of snippets, I would not be able to sleep at night if I just grabbed a snippet from somewhere, pasted it in, and went on my merry way. At the very least, I need to rewrite it so as to convert it to whatever naming and error handling standards I'm following. More importantly, though, rewriting it ensures that I understand it. It would be irresponsible of me to just paste it in blindly.

In the case of components, though, re-use is the whole point. However, because a component is largely a black box, there is an element of trust involved. I have to ask myself, "Do I trust the person or company who created this component?" Even if the answer is "Yes," if it is a publicly available component I will first search usenet and the web to make sure there is not a preponderance of negative opinion about the component.

A separate, yet related, rant: crappy sample code included in books, and also crappy sample code shipped with products (especially Microsoft products), drives me crazy. The vast majority of code that I've looked at from books and purchased products (like components and frameworks) is just bad. Even in the case of some otherwise really great products and books (whose names I will omit), the sample code is just crap. It's not just that it doesn't work (because it usually does, since somebody at least tested it), it's that it looks and reads like crap: bad variable names, poor cohesion and coupling, bad or no exception handling, etc. Not only does this bad sample code set a poor example for the developers who are learning by reading the code, it ends up getting copied and pasted and propogated even further.

The problem with a "craftsman's" imperative is real.

It is that consistently throughout industry, "cost-effectiveness" is self-reflexive and must be internalized by the craftsman, and "cost-effectiveness" destroys craft.

It would not do so in a (mythical: Utopian) world not run on investment capital; but the reality in a competitive marketplace is that the craftsman's imperative is in real contradiction to the fact that without exception, the businessman needs the artisan to seek the cheapest not the best alternative.

Programmers are permitted, to be brutal, to imagine that they form a craft or a guild.

But one never reads even of the existence of this entity in the MIS or business press except insofar as it is The Problem, a gang of scruffy malcontents at odds with the purity and the clarity of the intentions of an abstract and singular User.

Except in Scandinavian countries, the idea of a partnership between this guild and management is a non-starter because in fact the guild claims a right of management control.

When I lay bricks or pull cable for a man, I can do the best job of bricklaying or cable pulling without my work ever ascending to the state of craft. All the boss wants is for the bricks to be laid neat and true, as Tom Hanks lays 'em in his recent film The Terminal, where as a penniless immigrant, trapped in JFK, Hanks takes over a job site to do the best job he can.

But by definition, code can never reach this point in a stable manner, although many programmers, in referring to "solid" code, would like it to, and return to a simple, honest relation with their employers like that of their grandfathers.

This is because code is writing and worse it is law (cf. Lessig).

To get to simple workmanship it has to overshoot and essentially upset the applecart.

This is because the User never has that clarity, indeed purity, of intent which would be represented, one for one, by solid code.

There is in any "enterprise" system in our society an element of double-dealing, of impurity of intent, and of struggle amongst different user cabals which is NECESSARILY reflected in the code.

As such, a guild of programmers which insisted on workmanship would be a revolutionary guild merely by insisting on clarity and bug freedom.

But as it is, programmers who construct robotics cannot, it seems, even enforce Constitutionally anything like Asimov's law (no robot can kill a human being): for one of the major applications of robotics is military, where Asimov CANNOT be a "law".

As to your point about code-in-books: I agree. I got flamed on Amazon for not delivering full code generation to the .Net CLR. Having sweat bullets at the YMCA delivering a full front end as 26K lines of code, I was amused at this charge, especially because the code was written consistently using Option Strict (the VB.Net construct enforcing C# type discipline) and a set of documented standards...including my own invention of a way to implement stateful objects consistently.

But, I decided on a rather superficial treatment of code generation because of the existence of good books by Katy Dollard and Serge Lidon on this matter. Which was seized upon, as a flaw.

Because programming is writing, the fabricator, who would like to be thought of as an honest, gruff craftsman in the Heideggerian Nordic mode, is instead an untrustworthy scribe whose very proximity to old Pharoah makes him simultaneously invisible and a danger.

Programmers in other words need to realize how others view them from the outside. I know from vast experience that programming "feels like" craft since before learning to program, I taught myself art forms including egg tempera.

But in fact (cf Lawrence Lessig, CODE and the Laws of Cyberspace) programming is a form of law which forces people to do things they don't want to do.