Choosing the right website building paradigm, or "The Lazy Programmer Method"

While struggling with frontend development of my new blog software, Kittybox, I've came to a conclusion. I was pursuing the wrong thing all along.

When building a product, you need to ask yourself: "What do I want to have on my website?" Then, as ideas come into your mind, write them down, preferrably in a text document on your computer. Then order the features that you want to have by their complexity.

And then go from least complex, to the most, implementing it in the laziest way possible.

The lazy programmer method

I'm not exactly sure I invented something new, but I think I'd like to call it "The lazy programmer method". Why lazy? Because programmers need to be lazy. Invention is a product of laziness. We invent new stuff to have more time to be lazy and get some rest.

People in my country say that the leap from the apes to homo sapiens was performed when the concept of labor was invented. That tools were invented out of labor. No! They were invented out of laziness. Using a simple tool, an ape could get its job done faster, receive food more efficiently, and thus, have more time to enjoy the fruits of its labor. Humans are the same.

When you implement features you want in your product in the laziest way possible, sorted by complexity, three things happen:

Your code becomes simple and easy to debug

This may or may not be obvious. But when you write as little code as possible, you may not find yourself as tangled when something goes wrong. Less code means less places to make mistakes, after all!

Your code evolves in a natural way

Going from simple to complex is just how everything in nature works. Writing code the lazy way allows you to learn as you go. When one of the features you want to implement requires a thing you never knew about, you can pick it up as you go, and not try to cram stuff into your brain as if you're studying for an exam.

And we all know that everything you cram for an exam will disappear as soon as you go and write it on paper. (That's why I stopped making notes in school one day, because I tend to forget stuff I write down)

You only implement what you need

Remember, how I said: "write things down first"? This helps you with planning. Sometimes my brain tends to make me want to cram as much shiny stuff in my blog as possible; this led me to working on the new redesign for over a year already. I understand now that I need to start from scratch and apply everything I wrote above in my own practice.

The lazy girl's website

Ok, so you know the method, let me try showing you how it works in real life and try to fit my new blog frontend's concept in this method.

Features

• Static rendering - of course, a proper IndieWeb website should be available without JS.
• Dark and light themes - for sane people and for people who want their eyes to burn.
• Support for most content types I usually post:
  • Notes - simple Twitter-like posts
  • Articles - long-form posts with a title
  • Photos and videos - I list them together because these media types are very similar to each other
  • Food and drinks - because who doesn't want to turn their blog into a food porn collection?
  • Exercise - umm, yeah, might be tough on quarantine but I still want to get my physical activity up
  • Check-ins - might feel a little bit non-relevant on quarantine too but I want to highlight some local businesses that need our love and support!
• Ability to log in to the website to view private posts
• A service worker to cache the website's content
• A simple admin interface just for me, built right into the frontend, as a stretch goal

My past mistakes

My first mistake was starting in the unknown lands, with React. Next.js turned out to be a well-made framework, but it wasn't built for sites like mine, which need to be able to be stupidly simple. So I guess I should've started with some good old HTML templating.

My second mistake was then trying to overthink and overengineer the system - while the onboarding screen I've shown y'all earlier (I think it was even featured at IWC Online 2020!) was really good, the implementation was kinda messy and it wasn't completed before I realized that the framework choice I made was holding me back.

My third mistake was not realizing it and continuing to fight further, when it was clearly time for a fresh start. If only I got the idea for this post... a little earlier!