Applying Derek Siver’s Over-Compensate to Compensate to Software Development

Feature image for Applying Derek Siver’s Over-Compensate to Compensate to Software Development

Table of Contents

Sign up for the Newsletter

    Once a week. Three links. No spam. Unsubscribe anytime.

    Derek Sivers has this wonderful idea called “Over-Compensate to Compensate”. He observes that when we try and correct for a bad habit, we often don’t fully correct the habit, because we forget that we are influenced by:

    • a lifetime of doing it the other way
    • your environment that made you that way
    • the pressure from friends to stay that way
    • and the undertow of old habits.

    So, Sivers suggests that to change a bad habit, go extreme. For instance, if you often blame everyone else for your problems, you should correct this by blaming yourself for everything.

    You need to think, “Absolutely everything is my fault. All of it. It’s my fault the world is the way it is. It’s my fault the government isn’t exactly to my liking. It’s my responsibility to fix everything I don’t love. It’s my fault that others act the way they do towards me.”

    This feels horrible. It feels like you’re overcompensating. But you will most likely swing back to your old ways of thinking; sometimes you can’t help but think it’s not really your fault.

    This means that given some time, you’re actually striking a balance. Which is good. Over time, this becomes your new normal.

    Sivers says he’s trying to do this for the following topics:

    It’s a great idea, one that I’d forgotten until very recently.

    Applying Overcompensation to Software Development

    I’m a software engineer by training. I’m currently a ‘solopreneur’. The biggest danger for me now is spending excessive amounts of time polishing my software — writing the most beautiful code, designing the most scalable software architecture, writing legible, rigorous tests.

    I feel uncomfortable when I look at dirty, unoptimised code. I get visibly upset when I extend a hack with another hack. The software engineer’s desire to write the cleanest thing, all day, every day, for every little thing, lives strongly in me.

    This is a problem when you’re one-man business. Spending time polishing software is time not optimising for the business. At this stage, given that I’ve not found product-market fit, my time is better spent shipping features my users want, doing marketing to get attention for my products, or figuring out if what I’m building is actually something people are willing to pay for.

    So: I’m going to overcompensate. From now, every feature I write will be subjected to the following thought process:

    I cannot spend much time on this. What’s the ugliest version of this feature I can ship that is useful? Is there a way to create the most amount of technical debt possible while doing so? What else can I cut in order to gain speed? How can I break as many rules of software engineering as possible in the process? Good code is for dummies. Real businesses ship.

    This is ridiculous. The software engineer in me cringes just writing that paragraph. I’m going to force myself to think these thoughts as I program in order to over-compensate for my desire to be clean. Knowing me, I’ll likely circle back to refactor (promising myself that ‘oh but this doesn’t take that long’ — which is a lie, which is the point).

    This means that I’m more likely to strike the right balance. After all, over-compensating is compensating. It just doesn’t feel like it in the moment.

    Want more posts about working as a solopreneur? Check this out.

    Originally published , last updated .

    Member Comments