The Gordian Knot

Recently I’ve been exploring the concept of progressive enhancement. I won’t rehash the idea here, but I will restate the approach so it fits my Test-Driven brain.

• Write just enough markup to display all the necessary content of a resource.
• Write just enough styles to turn your markup into something nice looking.
• Write just enough client-side scripts to make your content interactive.

The End of Language Superiority

The world thrives on diversity and so does the web. It is empowered by diverse technologies working together, and it is much greater than the sum of its parts. Separation of concern is similar to separation of labor. When I can solve a very large problem by breaking it into smaller problems then it is much easier to change my solution as the problem inevitably changes. This also allows an expert in CSS to solve the problem of styling my content. In addition, building web applications out of a variety of technologies and having a sympathy for each of them is a good thing. The age of language superiority is over.

The Aggressive Curmudgeon

Now to deal with the curmudgeonly developers who reject diversity and sympathy in favor of depth of knowledge. They insist these new ideas are idealistic and ultimately unfruitful. This leads them down the road of forceful swings from their favorite tool which begin to lay foundation for the Great Rewrite of 2011. Software written by the aggressiveness of willful ignorance is not meant to be shared.

If the web is about sharing and the web is represented through code then every piece of code one writes is for someone else. It might be said that in the age of non-distributed computing that developers should own their code. To put it another way, “your code, your problem.” But just as the age of language superiority is over so the age of individual code ownership is over. However, let me be clear that I am not saying “your code, our problem.” That is simply not the way the open-source community works. If one writes poor code then he suffers the consequences of no one using or contributing. Unfortunately, the latter paraphrasing rings true in most businesses because a developer inevitably moves on and new developers must work together to produce something. That is, developers are paid to accept the idea that someone else’s code is their problem.

The Impracticality of Perfection and the Reality of Improvement

When I code I do not strive for perfection. Instead, I attempt to improve my skills by learning from others who know more than me. When a mentor is unavailable (often this is the case) I attempt to approach a problem in a different way. Where I might have used an abstraction to solve a problem I did not understand in the past I attempt a more advanced methodology. The great news is that, though mentors may not be available, there is a wealth of information from people much smarter than myself. Again the web is about sharing. When solving a problem one ought not relegate himself to learning nothing new. Perfection is for Guitar Hero. Improvement is for software craftsmen(and women!).

The Hard Facts

Anecdotes and flowery language interpreted by multiple readers is bound to miss the mark at which I’m aiming so allow me to be a little more objective in my conclusion:

• Your problems are not intractable.
• There are people in the world who speak different languages. Learn them.
• The web is about sharing.
• Write code for your successors.
• Improve your skills by holding yourself to higher standards than you might comprehend.