Programmer vs. Business Owner

This week I’m wrapping up one of our more ambitious programming projects (which I’ll be posting about when it’s launched).

I often find my roles as both a programmer and business owner at odds with each other. It’s easy to get caught up in writing perfect code, programming for every single possible scenario, adding additional features because they’d be cool, or writing code that will scale to handle 100x the volume that we’re currently at. It’s easy to turn a two week project into a month long project, or to write twice the necessary code in the quest for programming perfection. The developer in me wants to go above and beyond for the sake of going above and beyond, but that’s not always what’s best for the business. Sometimes the right answer from a business perspective is to do less.

Years ago I was chatting with a friend in a similar position. He was both the owner of a tech business and the head programmer. I was mentioning how I don’t do a lot of the things that I think great programmers should do – such as attending conferences, participating in open source, and answering questions on Stack Overflow – and was wondering aloud if at some point it would catch up with me. His answer was something to the effect of: “you and I shouldn’t be doing those things because programming isn’t our career, running a business is. It’s our job to write great code for the sake of the business, not because we’re trying to become elite programmers.”

That point really resonated with me. Any time that internal debate arises – and it always will as long as I care about the code I write – I picture my business owner self asking questions to my programmer self. Do we really need this feature? Would it really be that big of a deal if it only did X for now and we added Y later? What’s the opportunity cost of you spending twice the amount of time to accomplish feature Y? Usually the answer is “no”. We only launch with what we truly need, which turns out to be not only what’s best for the business, but in the long term is (oddly enough) what’s best for our code base. We don’t have a lot of bloat or unnecessary code because if it wasn’t important, we didn’t write it.