Three Attempts Or More

Looking back at the huge amounts of code I have written for my ever new “Million Dollar Idea™️” , I came to the realization that when I’m building a new app with unfamiliar technologies, or wrestle with a new idea, I need at least three attempts to build an app that somewhat works in a reasonable amount of time.

I have gone through this while building the apps powerbell and DressUp Club. I learnt React Native while building powerbell and even though I was fairly productive using react before, I had trouble organizing the app structure and even though I shipped the app, it would require an entire rewrite to add almost anything new to it. For DressUp Club, I went the other way around and made it more complex that it was required which turned app into bloatware that is slow and took a lot of time to build but can be extended in any shape of form.

After going through step 1 and step 2 with React Native I learnt that unless I am building a companion app or have the ability to write my own native components, I’m better for picking a native platform and sticking with it. The amount of native API each platform uses easily outweighs the illusion of having a single codebase which ends up having lots of custom code to handle each platform’s way of doing things.

Every time, without fail, these are the three steps I have to go through:

  1. Build an app I end up with a working version of it but with serious scalability and / or extension problems because I have underestimated how hard the technology is or how poorly thought the idea was.
  2. To not make the same mistake again, I start thinking about all the possible problems and then of all the possible solutions and then of all the problems the new solutions would bring with them and on and on up to the point I never get to complete the project and abandon it because I don’t see the end in the foreseeable future.
  3. After learning what it means to go too fast or too slow, I start to get familiar with when I can sprint and when I have to take it slow, of the things the really matter to get them right and which are the things that can be rushed out.
  4. Sometimes the 3rd step is not enough and a nother attempt is needed in order to really filter out the bad ideas and to highlight all the pain points and lay out a solid foundation that can addapt to future requirements

This process maps out perfectly over the Dunning-Krugger Effect. The first you time you build an app you have the blissful confidence of ignorance until you reach the peak when the scalling issues start to amount. Then on the second attempt you take every precaution in the book to avoid the scalability problem and you fall into the depth of despair due to the never ending amount of work required to make it scalable. Now, on the third attempt you start acquiring taste and know where you can cut corners and where you have to do it by the book and so you get out of the valley of despair and build competence, real competence.

The only solution I have found so far to solve this problem is to limit the scope of the first things I build using new technologies or explore new ideas so that I reduce, to the minimum, the amount of time I spend in the inevitable step 1 and step 2 of the process and get to start with the 3rd step and move on, if necessary, to step 4 where.

PS: One thing I always avoid doing when building is to build new ideas with new technologies because then I can’t pinpoint if the problem is caused by my incompetence of by a bad idea.