I don't work in a vacuum

Not too long ago I wrote a blog rant called 'Stupid Template Languages'. I suspected I was setting off a firestorm, but I have to admit I didn't quite expect to have the singular honor of having both Armin Ronacher and Mike Bayer respond to me in their own blogs. As one might say, "Danny, you really stepped into it."

My initial response to their entries was to start writing another post that would refute what they said point-by-point. However, while the tone in my original post was somewhat confrontational, the problem is that I didn't want to turn the debate into a sordid affair with drawn sides. You see, I've long respected both Mike and Armin as developers and people. Even if I didn't care about them, all it would do is stir up angry retaliations and steer people away from good tools. So I linked to their responses, let it go, and I hope we can drink over the issue this year at Pycon.

However, if we step away from the tools, the real problem I was addressing in my post was this:

I don't work in a vacuum

Any tool has the potential for misuse. As Alex Gaynor pointed out in Django Dose, he is familiar with the poorly crafted system which was part of the reason why I wrote 'Stupid Template Languages'. Heck, anyone reading this blog has probably run into one of those nightmarish system created by others that we have to maintain, and many of us will sheepishly admit to having been the author of such systems.

When you create a system like that you are making things harder for others to contribute and enhance. Trivial tasks become monumental and the desire to post your sad story to The Daily WTF becomes very strong.

Don't work in a vacuum

There are the well-documented methods called 'best practices' that us programmers ought to follow in order to make our work more maintainable.  In the general programming world, patterns like Model-View-Controller (MVC) is a common way to break up pieces of a project into predictable components. In the Python world, we generally follow a set of standards called 'pep-8' for writing our code. Various groups and organizations often have additional standards for naming, tests, and documentation styles.

Standards can be created without wisdom or consideration for real-world issues. Too many tests and documentation can eat up time on a project and cause interminable delays; there are horror stories about developers writing pages of non-technical material in order to produce a single line of working code.

Following these methods and doing so with wisdom is like striving for a platonic ideal. It is both gratifying and time consuming to reach for perfection - and this perfection is fleeting because of the shifting requirements of clients, operating systems, and tool changes. To attempt to reach for this helps a person be considered a good developer, but doesn't guarantee that they are actually good.

Breaking the rules

Sometimes you have to abandon best practices. Sometimes the tool at hand makes it hard to perform a task without breaking the rules. In the python world a good example is monkey-patching, which we do with trepidation. In the relational database world, people with a deep understanding of normalization will sometimes indulge in de-normalization in order to boost performance.

Unlike best practices, there is no platonic ideal that clearly states when breaking the rules is a good thing. Ever seen a database created by a developer without any knowledge of normalization who smugly says their database is better because it started off de-normalized? How many of us have seen views where control and persistence is integrally embedded? Or where views are embedded in control code?

In regards to the debate that triggered this post, I've read the following phrase a few times as an argument against my rant: "We're all consenting adults here".

Does that mean we can do what we want? That we can write spaghetti code?

Certainly most people reading this post will know that statement generally refers to variable handling in Python, not the right to sunder the rules of good coding practices. Yet I've seen people use that as a mantra to ignore any sense of good coding practices for python related projects. Which meant that the level of effort to maintain and expand those projects increased at the same rapid rate that the bus factor decreased.

Conclusion

I'll just throw out some well known platitudes:

• Code like you aren't in a vacuum. 
• Break the rules only when you have a concrete reason. 
• Learn to take criticism well.