You Can't Sit on the Sidelines and Become a Philosopher

At some point every competent developer has that flash of insight when he or she realizes everything is fundamentally broken: the tools, the languages, the methodologies. The brokenness--and who could argue with it--is not the important part. What matters is what happens next after this moment of clarity, after this exposure to the ugly realities of software.

You could ignore it, because that's how it is. You still get paid regardless of what you're forced to use.

You could go on a quest for perfection and try all the exotic languages and development environments, even taking long archaeological expeditions into once promising but now lost ideas of the 1970s and 80s. Beware, for you may never return.

You could try to recreate computing in your own image, starting from a new language, no wait, a new operating system--wait, wait, wait--a new processor architecture. This may take a while, and eventually you will be visited by people on archaeological expeditions.

The right answer is a blend of all of these. You have to ignore some things, because while they're driving you mad, not everyone sees them that way; you've built up a sensitivity. You can try new tools and languages, though you may have to carry some of their concepts into future projects and not the languages themselves. You can fix things, especially specific problems you have a solid understanding of, and probably not the world of technology as a whole.

As long as you eventually get going again you'll be fine.

There's another option, too: you could give up. You can stop making things and become a commentator, letting everyone know how messed-up software development is. You can become a philosopher and talk about abstract, big picture views of perfection without ever shipping a product based on those ideals. You can become an advocate for the good and a harsh critic of the bad. But though you might think you're providing a beacon of sanity and hope, you're slowly losing touch with concrete thought processes and skills you need to be a developer.

Meanwhile, other people in their pre-epiphany states are using those exact same technologies that you know are broken, and despite everything you do to convince them that this can't possibly work...they're successful.

I decided to take my own advice by writing an iPhone game. It's not written in an exotic functional language, just a lot of C++, some Objective-C, and a tiny interpreter for scripting. There are also parts of the code written in a purely functional style, and some offline tools use Erlang. It wasn't ever intended as a get-rich project, but more of get-back-in-touch project. As such, it has been wildly successful. (Still, if you have fun with it, an App Store rating would be appreciated.)

(If you liked this, you might enjoy The Background Noise Was Louder than I Realized.)