There’s a unique sort of delight to be felt when you know you’ve created something marvelous. It’s likely that artists of all stripes feel similar joy about their best works, but I experience it where I’m most at home: programming.

Programming Problems

I’ve been recently faced with a fiendishly difficult programming problem which shouldn’t even exist but for a bizarre set of circumstances at the client. It’s the sort of problem where there’s no such thing as a clean solution.

No matter what it was, it would be ugly.

Like painting a picture, there’s no perfect way. But the limitations of paint are in their ability to capture the entirety of a scene, whereas there are some behaviours of a program that simply cannot be simulated without an extraordinary amount of non-reusable code.

Inside The Box

Thinking ‘inside the box’ can be one of the biggest enemies in these situations. The ideals of abstraction and data-hiding lead to much more maintainable, bottom-up code. But there are those places where a tool has many purposes. A screwdriver is a screwdriver, but it’s also half a crowbar.

I found it helpful to think in terms of extremeties. Lay out the worst possible approach that would still work, even if it’s too ugly to be feasible. Then lay out the absolute best approach in broad strokes, even if it’s unfathomable how a particular piece of the functionality will be implemented.

Look at the worst-approach picture. Try to grab at anything that can be abstracted, any kind of general case that can be drawn between the different cases.

Impasse

The most successful false start lasted for several days, until I suddenly realised with a sinking heart that would not work. The design was impossible.

What to do then? Go to the water-cooler. Play darts. Cycle home and think about it. Have a shower. Percolate.

In the morning, I’ve got a solution. It’s not perfect, but it will work. And it’s significantly better than the worst-case-scenario. By lunchtime, it’s working, using large pieces of code that was written for the prior attempt.

Teamwork

It’s so important for programmers to work in small teams, and idea-bouncing is one of the many reasons. New eyes can so easily see value in something you’re ambivalent about, or better yet, see the problems with your idea.

Programmer Pride is another reason. When a piece of code just works, it’s so great to be able to show it to others who understand the significance. Like design, the best programming looks easy. The best programs do work for you without even letting you know. Sharing source with others is a way of demonstrating how cool something is under the hood, and sharing a little of the excitement.

Solution

The problem is solved, and development will move forward, spurred on by the knowledge that there’s something nifty in there.

Mike

← Earlier Later → Posted at 8:33 pm to Uncategorized.