Half-Baked Ideas

No-Code Apr 06, 2020

When I started playing guitar I used a software called Guitar Pro to make music. It was good. However, everything took a lot of time, at least for me. My setup was my guitar, and my computer, that was it. I couldn’t record anything so every note would have to be written: click, type, click, type, listen, erase, click, type, listen. It would be like that for every single instrument. It sounded gimmicky, but it was all I had. I wrote numerous songs from beginning to end using only that (don’t ask how good the were).

Nowadays, I use an interface to record my guitar and vocals, a MIDI controller to write synth lines or program drums, and several DAWs (Digital Audio Interfaces) to ease the process as much as possible. But here’s the thing: Although I can start working on a lot more projects due to the lack of limitations and the huge amount of options, the number of finished songs is significantly smaller than during my Guitar Pro era.

I’m telling you this because I saw this tweet the other day and it sounded familiar:

It goes without saying that it’s awesome to have so many good options to create software, right? You can go to coding bootcamps, learn to code online, or learn how to use a lot of No-Code tools. Tons of options! But… it also does start to feel like the Netflix menu, right? So many options, how can you commit to only one thing? More importantly, how does one decides to commit to something?

When you are working on your web application or your mobile app, or whatever, you start motivated and you progress until one of two things happen: 1) you find something new and more exciting than what you are doing, or 2) you reach a point where you don’t know how to keep that progress going, and get stuck (this might be technical or conceptual, obviously). And knowing how easy and fulfilling it is to start a new project using No-Code tools, things like what the tweet tell us can occur.

So how should we deal with this? I don’t think stepping away for a while is a bad idea, actually. As long it is only for a while. The idea is to have a good time with this, so if we are not doing that, we should leave it alone for a couple of days. Perhaps you’ll find your way through your problem during the shower and continue with your project, perhaps it needs more time and preparation. Maybe you haven’t even noticed there is something that’s not working properly.

I also recommend going back to square one. And I don’t mean going through your first technical step in the making of the app. I mean really going back to the beginning. Why did you want to do this in the first place? What made you go from daydreaming to start making something real? So check your first notes and drafts, fall in love once again with what is currently half-baked and get back to it!

Leave some space when something is not working exactly how you hoped it would, but don’t just abandon it. Make a journal of your ideas, so that when you are stuck or wanting to do something else just so you don’t have to face this plateau, you can remember why it meant —and probably still means— something to you. Don’t quit on your ideas before they are fully realized.

So go on. Open that file from three months ago, you’ll find something you didn’t remember you loved.

const headerTagLinks = document.querySelectorAll('.js-header-tag-link'); for (x = 0, l = headerTagLinks.length; x < l; x++) { const lang = headerTagLinks[x].getAttribute('data-slug').split('-')[1]; const shouldRemoveLink = lang !== document.documentElement.lang; if (shouldRemoveLink) { headerTagLinks[x].remove(); } }