5 hard truths about building software (for perfectionists)
I’m a perfectionist, I like to know the “best” way to do something and I like to get things right.
I’m also the sole software developer and CTO of a young startup, and that’s where these self-identifying statements start to bash heads.
If you’re anything like me, you are constantly evolving at the pursuits you excel at most — constantly reading about industry trends, trying to soak up as much knowledge as possible from those who have come before, implementing new and good ideas into your daily workflow and generally trying to be better.
There’s a lot to be said for self improvement, however I find this often leads to frustration. Over-thinking, constantly second guessing the approach to a problem, trying to line up your plan to implement or architect with what you know your research says is the right/best/most popular way is a sure-fire path directly to the hell that is “analysis paralysis”.
You get nothing done while over analysing the problem into a universe-sized abyss of endless possibilities which can result in serious preoccupation, restless nights and ineffective days.
In a startup, where you need to move fast and often, the business can’t afford the person most responsible for bringing ideas to life to find themselves in this wilderness.
So, when this happens to me, I try to revisit these 5 hard truths.
- Nothing is ever perfect
No matter how hard or long you work, it will never be perfect. Humans are not perfect, so it is a fallacy to expect that the code they write will be. There will always be that one extra feature, that one codebase reorganisation or that new best practice you learnt about watching too many conference YouTube videos.
Let it go, if you can. Focus on making your effort directly relate to better outcomes for your business, your product or your customers, rather than scratching your own insatiable itches.
- You won’t get it right the first time
You can never know how to do something better until you have done it at least once. In fact, the more poorly you do it the first time the more you will learn about how to improve.
This is not an excuse to half-arse anything. Make the best thing you can, with the time/money/energy that you have, get it working, get it in the hands of your customers and then ask them how to make it better.
Accept that you won’t always get it right. Accept that you don’t and can’t know everything in advance. Accept that what you think is right or correct is opinion, not fact.
- There is no “best”
The process of developing software is an ever-changing quagmire of new ideas and rehashes of old ones. There are a sea of languages, tools, libraries, practices considered best (and the inevitable “practices, formerly considered best”).
It doesn’t matter. Pick something. If you want to do something quickly, pick what you know and work from there. If you have time to challenge yourself and learn, pick something new.
Don’t implement every new tool into your workflow just because it’s shiny, use it because it solves a problem that you have now, not one that you may never have.
There is no “best”, only what you can achieve right now, with the knowledge and time that you have.
- No matter how desperately you want to make big changes, make small ones
So you want to reorganise the entire codebase because it would be cleaner, easier to work with, quicker to develop on, faster to onboard new team members with? Great, that’s a lofty goal and an important one. Over time code rots, business priorities change and sometimes you need to transform what you have done before you can move forward.
The problem is, when you try to jam too much into a single transformation you can end up being caught in a cycle where you just need one more day, then another, and another, before you can get on with other more important tasks (like running your business and giving customers what they want).
The worst thing is, for a developer it’s almost impossible to explain the benefits of these large changes to the less technical on the team. Often they come with very little in the way of visual results, which can make it hard to justify the week you just spent reorganising your backend codebase.
Sometimes you need to make large, non-visual, non-functional changes, but plan it out first. Have a goal, make sure you understand all the work involved and then figure out how to do it incrementally so you don’t end up taking yourself away from the important job of iterating and innovating.
- Don’t beat yourself up
Most importantly of all, make sure that if you feel yourself slipping into any of these bad habits that you do not allow them to prevent you from doing your most important job — shipping software that your customers love.
Give yourself the mental room to breathe away from the noise of the codebase and identify your real world goals. Stop beating yourself up (and the people around you) by being so consumed with the code, or the tools, or the build environments, or the organisation of files, or whether it makes more sense for a method to be in one class over another. Stop. Think about the end result — not the functional, this-button-there type of result — but the customer result, the business result, the results that actually matter in the long run. You’ll thank yourself for it.
At Carisma, we are creating a platform for mechanics to communicate and engage with their customers in new and exciting ways. Our mission is to bring trust and transparency to an industry much maligned as having very little of both, despite remarkable technicians and workshop managers who pride themselves on working hard to provide great customer experience.
This is our goal, and anything that gets in the way of that (like analysis paralysis) is a distraction.
Does anyone else get this way? Is this applicable to other disciplines? I’d love to hear your thoughts.