Success Criteria

Programmers who want to succeed in their careers need to learn about the domains of their businesses. Working in health care in the US? You'd better understand HIPAA and insurance billing. Working in finance? Better understand cash flow and the time value of money. Working in biology? Better understand a little bit of chemistry and genetics.

Entrepreneurs who succeed in business eventually learn that running a business requires far more than understanding the technical aspects of plumbing or construction or programming. Growing a business means understanding business as business.

Programmers who really want to succeed in their careers also ought to learn a little bit about business too. That means cash flow. That means return on investment. That means the time value of money.

Here then is the source of my unease with both academic computer science and programmer blog culture: they seem to exhibit a deliberate uninterest in understanding the realities of business.

Why aren't people using formal methods to verify their software? For the most part, the expense of using formal methods in both time and resources is greater than the expected return of additional correctness. (Yes, the perception can be wrong on both sides, but the decision has rationality to it.)

Why is it often more popular to build a shared-nothing web site in a dynamic language which uses a lot of extra cycles for unnecessary things you could work around in C or C++ even if later on you have to spend more resources to make things scale to handle larger popularity? (Yes, I know you can make a list of people who've made foolish technical decisions. Does that prove the inverse of that set does not exist?)

I write tests for all of the code I care about, but I don't test absolutely every part of the stack in exhaustive detail. I don't always write the same code in the same way everyone else does. One part of my business is a shell script written in bash and tested only by the fact that if it ever stops working, I'll find out immediately.

The purity of an ideal or a unified language stack or a hipster-compatible architecture is one thing. Maybe it's your preferred success criterion.

Meanwhile, the relentless pragmatism of Perl and the CPAN means that the return on my investment (especially relentless automation!) is greater on most of my projects than it would be for any other language or ecosystem.

I'm not telling you not to use Clojure or Node.js or PHP. I assume you're a rational person who can see the benefits and drawbacks of each. (If not, at least try to be lucky.) But before you look down your nose at me for not using a language with dependent types and a modern Hindley-Milner algorithm or for not writing a single-page JavaScript application that invents its own relational algebra on a distributed key-value store in the cloud, let me tell you that your success criteria aren't mine.

It's not that I wouldn't do those things if they made sense, but for me, Getting Stuff Done in a way that delights clients and customers and helps my business's numbers continue to improve is my primary success criterion.

I take pride in my craft. I program and design to the best of my ability and continue to strive to improve my skills. When I write code, I write code with care and discipline.

Yet when I must choose between meeting your idea of purity or satisfying the constraints of my business, I'm happy to tell you to learn to cope that I don't care about your new shiny.