Simple

So the thing I tell myself, over and over, every day of developing code is this:

Keep It Simple, Stupid.

This little maxim is important for everybody, of course, but for us programmers it's the most important thing there is to remember. You see, programming is hard. Software is hard. It gets complicated really fast. Programmers tend to be really smart people (not like me, I'm just a little smart), but even they cannot handle the kind of complexity that software demands. Not remotely.

Most of what programmers do, in fact, is work out ways to simplify the vast complexity that is their code. We do things like "refactoring", which is a fancy word for re-writing code to make it clearer and simpler.

We have tons of little sayings, maxims, truisms, and so forth to remind us how hard it is and what tricks and disciplines we need to practice to simplify it all. We remind ourselves to DRY (Don't Repeat Yourself). We encapsulate and modularize. We loosen our coupling. We abstract. We hide implementations. We make and use frameworks. We maximize code re-use). We use (and analyze and debate endlessly) best practices.

We have formating standards and naming conventions and color-coded coding and integrated development environments with advanced intellisense and just-in-time compiling and graphical object and data modeling languages that look like complex flow charts (but they're much more complex than they look) and tools that can generate code from those diagrams (but nobody really does that).

We have many languages, each with advantages and drawbacks, each with a religious following and an equally religious opposition. When structured programming (FORTRAN) wasn't good enough anymore, we moved to procedural programming (C). When procedural wasn't good enough, we moved to object-oriented (C++, then C#). Now that's not good enough and we're wondering if we should go to functional programming (F# anyone?). We have low level languages and high level languages and visual languages and database engines and web servers and communications protocols and standards galore. We have debuggers and version controls systems and user interaction conventions and change requests managers and virtual machines and automated test harnesses (that we really should write first, before the thing they'll test). Did I mention the competing methodologies? Waterfall (blech) vs. Iterative Rapid Development vs. Extreme Programming vs.... Oh never mind, it's endless as the accelerating and expanding universe. And that's just the computer stuff, I haven't even touched on the complexities of any given problem (business) domain.

So, I need to simplify.

Here's the best way to write simple code:  don't write any code at all. Use your head and figure out a way to do what you need without code. If you utterly fail at that, try again. Try harder.

If you still fail, try even harder to work out a way to accomplish your goal with very little code. Even less than that, if you can. That would be very, very, very little code.

The less code you write, the fewer bugs you'll create.

This is the thing I did today. I went at that Meta-Manager program and figured out a way to do it without writing any code at all. Subsequently, I'm finished. And it's bug-free. It doesn't have some of the features I was dreaming of, but the extra time it'll take to use won't begin to equal a tenth of the time it would take to write and debug the code those features would require.

I'm going to make do, and I'm happy. Because today, I actually managed to keep it simple.