Do not fall for complex technology

Fifteen years ago, I wanted to set up a note-taking system. At the time, Evernote was the tool everyone was talking about, so choosing it seemed like the right and easy decision.

After storing around 500 notes for eight years, Evernote became a mess to use. It was bloated, heavily monetized, and slow to work with. So I wanted to switch.

About that time came Notion. Everyone was talking about it. I jumped on the bandwagon and migrated a few hundred of my notes to it that were still relevant. It did not even occur to me that switching from a bloated and slow app to a web app would result in a similar outcome later. I followed a popular choice again.

After struggling for a year, I switched to Markdown notes and a plugin for an editor that renders inline images. I'm still using this to this day. It is simple, and I will be able to open my notes 10-20 years later. I can edit them in any editor. It works offline and does not depend on commercial products. I encrypt my notes locally so they can be stored safely on any cloud service.

I don't even use images anymore, so this could be simple plain-text files. Why did no one tell me that I can start simple and switch to a complex system if I really need it?

It took me almost ten years to understand that, don't be like me!

This process never stops. There are now Roam Research and Obsidian, where people spend more time organizing notes than writing them. Some people become obsessed with documenting everything and never reading it anymore, just because everyone talks how cool it is.

Microservices

Remember the peak of popularity of microservices and the use of GraphQL? Small teams of 3-5 developers used them to build simple web apps just because it was cool and big tech was writing about it a lot.

Simple systems became more complex for no benefit. A complex working system should only grow from a simple one. You need to gather initial knowledge and requirements about your project first. Iterating a simple system is much faster and easier. When a project starts, things change a lot. It's common to rewrite the whole project from scratch 2-3 times in startups just because the initial prototype resulted in so much technical debt and bad decisions. I had experienced this multiple times at my jobs. Not every system should be complex in the first place.

If you can only start with a complex system, there is a high chance it's broken by design.

The list of complex technologies is very big and I can go on and on. Oftentimes, you don't need to use ten cloud services, hundreds of serverless functions and so on. Not only can it be simpler, but it can also be faster and cheaper too! You just need to ask yourself why you need a particular technology in this project first. Sometimes the hardest part is to convince the management, though.

Start simple!

Blog engine

In blogging circles, one of the popular topics is "I migrated my blog from X to Y". Some people change their blog engines 3-4 times and I'm not an exception.

I started with WordPress, then I migrated to Django, and right now my blog is completely static.

When I was using Django, I needed a good server with proper caching so that when traffic spikes, it can handle it.

Right now, I don't need a database. Hosting static HTML files is simple, and you can do it for free. The only dynamic part is sending comments. I'm using CloudFlare workers with a simple 50-line script that just stores comments in Cloudflare Workers KV.

They are not loaded dynamically. I just import them to markdown files and regenerate the blog. There is no database to serve them. They are preserved in markdown forever.

The whole blog engine is 800 lines of Python code that supports comments, RSS, categories, and so on. I know exactly how it works, and adding new features is super easy. There is also nothing to hack. Internally, static website generators are pretty complex to handle various use cases. But, if I were using a popular static generator, adding custom features would be still hard.

LLMs

A lot of companies are trying to force AI everywhere. Look at Microsoft, they added it everywhere. In most cases, it does not make the life of a user easier. In the case of Microsoft, it actually results in more bugs and the worst UI. This time, ignoring complexity is much harder for a user, so the best shot is to switch to Linux where you have full control.

I think about this a lot. It's easy to spot problems in other products, but the product that you are working on can suffer from the same problems. It's harder to notice, especially when you don't use it.

Another problem with LLMs is that it is much easier to add new features to your project now. If you use LLMs, keep things simple and the scope of changes limited. When you aim for big changes, the code quality drops significantly. You stop paying attention to the changes to the point that you stop understanding how things work.

There is an old tale regarding code reviews. A team lead reviewed 100 lines of code and found three bugs. After that, he reviewed 1500 lines PR and found zero bugs. This happened because the scope of the changes was so big, that his brain just refused to concentrate on every change.

The quality of LLM output depends on code size, too. Their context is limited, and the bigger and more complex the codebase, the worse they perform.