Why building too early can send you down a rabbit hole
Are you trapped in a spiral of constantly refactoring your own product? Do you often get stuck, obsessing over UX/UI problems, and end up rewriting your code over and over again? Are you constantly switching focus from one part of your product to another? Does it feel like you're never getting done?
The problem with super powers
Knowing how to code can be a blessing as much as a curse, especially for solo creators. Like with every super power it needs to be used carefully in order to help and not hurt. Starting to realise an idea too early and eagerly is something I often see people do, especially creators with developer background.
Although freebase building/coding might create a sense of freedom and nice contrast to the dull and locked-in process that the everyday job or assignment offers, this "rebellious" approach creates nothing more than a nice gut feeling in the long run. Because in terms of efficiency and getting shit done, this approach is devastating.
Don't be mean to your brain, your own expectations and your efficiency!
Jumping into the IDE and start cracking out code too early is misleading to your brain as well as to your own personal expectations. Why? Because you force your brain to focus on solving problems related to implementing something that it does not yet know how to envision. Not giving your brain a clear idea of what your product is, how it should look and function and why it should be constructed this way, is an equally challenging task as asking someone to pick the right screws and mount them correctly onto a bridge whose type (arch?, suspension?, truss?, beam?, cable-stayed?) you yet haven't decided.
Instead of placing its energy on solving tactical and technical problems (how to build the what and why) you're forcing your brain to implicitly focus on solving strategic business and UX-related ones (what and why). This results in context switching, energy loss and inefficiency.
Don't get me wrong though. I'm not saying that the demotivating and slow process at your day job is preferable. But completely skipping steps like design, scoping, prioritising and time-boxing won't help you either, as nice as it might feel. The perfect flow is found somewhere in between.
When the devil on your shoulder screams "code" and the angel gently says "but wait..."
Next time you find yourself in a conflict between "want to" and "should", take a minute to ask yourself the following questions:
- Am I doing things in a smart order?
Is my product development process ideally structured? Am I solving the right problems in the right order? - Have I set up clear boundaries for myself in each part of the process?
When moving from step B to step C, do I "let my brain off" (from thinking about step B)? Am I giving my brain the possibility to focus solely on step C? - Am I working in a cost efficient manner?
Am I solving the right problem with the right method? Am I coding when I should be coding or coding when I should be designing? Am I designing when I should be writing requirements or designing when I should be designing? Am I designing in high fidelity when low fidelity is enough (example: designing user flows in Figma when it could be done much more efficiently with pen and paper)?
