You frequently hear (or I do, anyway) the advice that if you’re unhappy in your coding job, you should scratch your own itch, work on what you love… Work on something you’d be a user for. Because then you don’t have to do a bunch of requirements gathering and get them inevitably wrong, etc. etc. The idea seems to be that if you love the business process, you’ll love working on the code that enacts it. And, well, that’s fine. It seems to make a lot of sense, on the surface. But then I thought about history.

As programmers, we don’t have a lot of it (compare auto workers or, say, masons). History, I mean. But there’s some and in the days of Mel and COBOL Cowboys, things were different from what they are now. Today we have all these powerful abstractions and high level languages. Folks (well, not all, but many) consider it to be ideal if you’re basically writing your code in a DSL specific to your business process. Which means your code is really tightly coupled to your business (on that layer, anyway). I don’t know that that’s a bad thing at all (in case I sounded critical). I just want to contrast it to what came before.

Those dudes were almost just writing ones and zeros. They were so far removed from the business processes they were enacting and the folks who were using their stuff that I wonder how much impact it had on them. Would Mel have been any more or less happy writing financial management apps for large companies than solitaire? I kind of think it wouldn’t have mattered to him; he was in it for the code and playing with numbers. He enjoyed all that low-level stuff.

So I wonder, is our (figurative us, here) unhappiness when dealing with business processes we aren’t personally invested in a symptom of all of our awesome high level languages and nice abstractions?