Be Careful of Your Passion

Many developers categorize themselves when describing their areas of passion or specialty. Often this sounds like, “I’m a data guy,” or “I like middleware.” Occasionally you hear a passion for user experience or UI expressed as, “I like making GUIs.”

Most of us got into this business because we liked making computers do things we think of as cool. The most successful among us still get that rush when our new creation spools up and runs.

Tinkerers like us tend to gold plate the pieces of our systems we find most interesting. This is why developers will often find themselves the go-to-guy for certain specialities. A dev likes making services, she makes good ones because it’s fun, she gets to make more of them. Sounds perfectly reasonable and symbiotic, no?

It can be.

Ignoring the Boring

When we get to focus exclusively on the parts of the system that really flip our bits, it can come at a price. Although we might be jazzed about services, that data model still needs our attention. It is fairly common to focus on that thing that really gets us excited and forget (or outright ignore) that part which seems boring. Just because you think someone else will come along and sweep up after doesn’t make it happen.

The most common instance of “Ignoring the Boring” is documentation. Let’s face it, we want to write in languages other than English, right? Documentation is in the elegance of my self-describing code, right? Not so much. Whether we like it or not, documentation is often a deliverable of our system and as such deserves the respect we might give to our WSDL or interface definitions. Just because the reader is a human rather than a machine doesn’t mean we should short change her because it’s boring to do the work.

Smells of Sub-Optimizing

It is easy to see this kind of monocular behavior can result in a really clean UI with a messy back end, or visa versa. Whatever gets the short end of the stick will tend to show up in the system as a glaring deficit. We can then measure the deficit in the ignored sub-component in observable ways. Some failures of attention to detail might include:

• Lack of enforced constraints or relationships in database tables
• Code in the view, because it’s just this one little thing
• Leaky abstractions, because wrapping that data model in business logic can be a real PITA
• No check in notes
• Not taking the time to do code reviews, even informally

The System Isn’t Your Playground

On the other end of the spectrum, what happens when we get to play with the things that are fun? The results can depend on what the implementer really enjoys.

One recent real world story I heard told of a hardware engineer who designed 7 different chips within a device, each with a fundamentally different way of representing logic circuits. The chip engineer had a great time applying all the different techniques he read about in last month’s Nerd Fest Quarterly, but the team assigned to test this Franken-board was rightly annoyed.

Another symptom of playground development is needless abstraction layers or design patterns applied to simple problems. If a system is implemented with a gazillion abstraction layers where only a concrete implementation will do, you can bet someone is reading the Gang of Four in bed at night.

If your passion is trying new tools and technologies, how many of these shiny new toys are incorporated into your system without deliberate attention? How many logging libraries does one team really need? How many unit test frameworks?

YAGNI, ’nuff said.

Keep Your Passion Alive

So, what are you saying, Starr? Stop trying to extract pleasure from my work? Just bang the keys and give my 40 to the man? Of course not!

I am simply asserting that there is a degree of professionalism needed at all levels. Let’s care about the system as a whole and be good stewards to the craft, not just the shiny bits. And, yes, documentation is a justifiable deliverable. Cowboy up.

Learn new techniques that fire you up and apply them wisely, not with wild abandon. Delayed gratification means not always getting to use WPF to make a draw a button, or SilverLight to make a logo spin (<– bad example). Sometimes this means capitulating to use the prescribed framework so we can get a systemic optimization instead of trying to roll our own multi-tenant web portal, yet again.

Having more tools in our toolbox is a great thing. This is the essence of youthful fun in our work. Knowing when to use those shiny new tools is the wisdom part. Now go learn something new.