Build Shitty Stuff That Works

The hardest part about learning to program is building things that work and being okay with the fact that they are shit. These are also the most important aspects of learning how to program.

Shipping one fully functioning software on our own can teach us far more than tinkering with dozens of half-finished projects ever could. At the end of the day, good programming is about consciously making sound design decisions and owning up to their consequences. We can practice these skills by building and maintaining something that actually works.

However, it is hard to build a working solution because we draw our inspiration too much from passion. After the initial period of excitement for the project, our passion is bound to subside, and our motivation to dwindle. For instance, side projects are abandoned more often than you’d think because owners inevitably lose interests. And it is not uncommon for maintainers of software to become inactive after an initial meteoric surge in contribution.

Something You Can Use Every Day

Instead of deriving our motivation from passion, we should motivate ourselves by working on something that we can use every day. Nothing motivates us more than being able to use and reap rewards from our creation in our everyday lives. When our lives directly benefit from those projects, it is in our best interests to keep building them. In such case, we are driven not by philosophical or emotional reasons but by all the practical reasons.

A good example of building for personal everyday use is this very website, Dnote, on which you are reading this article. I started this project last year by writing a 300 line program to improve my programming knowledge. Ever since I have been using it regularly to learn programming as well as other subjects, and therefore have had all the more reasons to make it a better software over time.

a heatmap showing a frequency of Dnote usage
A heatmap showing how frequently I learn using Dnote

Among all the projects have started since last year, I use this particular project every day, and therefore have the motivation to maintain it. And it is one of the best teachers I have ever had. It has made me bear the full responsibility for some careless design decisions in the past. It has taught me how best to move forward while supporting existing users. It has taught me to collaborate with others. All in all, Dnote taught me to build a better software.

Your Code Will Be Shit

Another difficult aspect of learning programming is coming to terms with the fact that our code is shit. This is particularly true for beginners who are eager to learn as quickly as possible. But as students of programming or of any other things, we need to make peace with the fact that our work will be mostly garbage.

No one has ever started by creating masterpieces and we should not expect us to do so. Many early works of master artists such as Picasso or Warhol are neither widely recognized nor critically acclaimed. Those people were simply insanely prolific and kept on creating things good and bad. What I think made some of their work masterpieces is thousands of hours they had put in perfecting their craft.

In learning any skills, not just coding, we just have to put in time while producing works that stink. Let us draw a parallel to music because it might be easier to recognize a cacophony than a bad code. I had taught myself guitar for seven years by copying famous guitarists before I could write something that has a remote semblance of what we would recognize as music:

Above is one of the originals I wrote about five years ago. While in many ways it still stinks, there are musical elements that detaches itself from a sheer noise. There is a structure and instruments work together to support it. On the contrary, let us listen to what I have written two months ago after watching some YouTube tutorials on how to make electronic music:

There are many things wrong with the song and it is nowhere near my guitar instrumental in quality. Mixing is so awfully done that drums are a pain to listen to. The vocal samples are awkward at best. The song sounded really good in my head, but it turned out to be shit. The reason is that I only spent maybe two months learning to produce ‘music.’ A few months just do not cut it.

We all write shit especially as beginners and there is nothing we can do to change that. Coding is no different. All we can do to make progress is being absolutely not apologetic about the garbage we are bound to produce. We just need to keep making shit stuff that at least works.

Go Build Your Thing

So let us all build our things good and bad, and make them ‘work,’ in the broadest sense of the word possible. Doing so is especially important if you are learning to code. We probably will not build projects like React or Ruby programming language, just as we will not start by producing songs with comparable quality to those made by famous producers. And that’s okay. No one expects you to produce the best work in the universe. In fact, everyone is busy and no one really cares about your work.

Try to write good code and at the same time do not try to make it better. Here is a thought from my favorite essay, Steps Toward A Small Theory of the Visible by John Berger, that I have been turning over in my head for years whenever I taught myself new things.

Better did not mean making the thing more beautiful or more harmonious … it simply meant making it more itself so that the cow or the city or the bucket of water became more evidently unique!

Your software, music or writings do not have to be beautiful or exceptional. They just need to be more themselves and so that you can be more yourself and your journey of learning can be more itself. Build shitty stuff that works.

Dnote newsletter

Get intersting stories about privacy and note-taking, written by real people. Follow Dnote's journey.

No spam. Just stories. Unsubscribe anytime.

Sung Won Cho

I am making Dnote to protect our privacy.

Sydney, Australia https://sung.io