push.cx
Peter Bhat Harkins
As Difficult as Possible
For a long time it had seemed to me that life was about to begin - real life. But there was always some obstacle in the way, something to be gotten through first, some unfinished business, time still to be served, a debt to be paid. Then life would begin. At last it dawned on me that these obstacles were my life.
One of the things I like about programming is that it’s as difficult as I can make it. Programming can be tedious sometimes: filling in values for a config file, looping over another array to edit its values, schlepping data from raw input to database.
But anything that can be done by rote can be done automatically, any shared logic can be drawn up into higher-level abstractions, any duplicated values can be generated from a canonical reference. I can slack, or I can move up through abstractions so I’m not wasting my time writing filler code again and again. Software development should be as difficult as possible. If I’m not pushing my limits I’m not writing the best code I can.
I’m learning that running a business is a lot like programming in this way; maybe it’s even a level above the software development. Instead of writing code I can hire people to write code to my spec. Software development becomes a meta-game, instead of writing code to loop over some data or execute a database query to update a set of rows or use an ORM to mass-update a gaggle of objects, I’m instructing a person to do all of those things. It’s not as deterministic, but the parser is a lot more flexible.
Of course, this clashes with my programmer’s impulse to write every line of code in every library used by every project for myself. I’ve learned to compromise in my programming: not every library API matches my mental model, not every data structure fits my performance needs, not every line of code I write will be bug free. Because I sometimes revise code to improve it multiple times I know that quality isn’t binary, it’s a range. If outsourcing development means I end up with lower-quality code (which is mostly means its not written in my personal coding style), that’s OK as long as I’m advancing my business goals rather than coding for code’s sake.
I love software development, but it’s turning out to be a smaller part of this business every time I step back and evaluate my progress. As long as I don’t turn into a full-time manager, I think I’m OK with that.
I’m not as good at managing as developing, so it’s easy to fall back into developing it myself every time I want to get something done. But that doesn’t work. I need to keep the job difficult to succeed. I need to get as much done as quickly as possible to reach my goals, and I’m not going to do that if I just do what’s easy.
This is, in a way, the point of the excellent E-Myth Revisited. I read it a few years ago, but it’s one of those books that cause me to sit up every few months and realize that I’m re-discovering things it’s already explained and expounded on.