First (stupid) things First
When computers can't connect to the internet, maybe check the LAN cables first before trying to build a new modem from scratch

Don't reinvent the wheel
when you want to build a car.

If you just want to know how the wheel works, or got some extra time to test stuff, then sure, go ahead and do it. But this is rarely the case in a business or a project with other people involved...

meanwhile me, doing distro-hopping, testing 5 provisioning tools, upgrading to ts7 when it's not fully-baked, creating docker swarm, writing an agent with SDKs from scratch and customizing my own alpine VM just to run 3 docker containers:

oxfmt, oxlint >>> prettier, eslint

A friend of mine gave me a useful insight: the more options & customizations you offer, the more they'll demand.

We were working on a payment system, and we faced an edge case where the refund amount could become negative 🗿 Our first assumption was to do MAX(refund, 0) thus allowing only positive values. I decided to ask the stakeholders, just to make sure it was ok. However, the way I asked opened a door for customization... they responded: "It's okay to have negative refunds (meaning the customer needs to pay an extra amount to complete the cancellation) and we've already had some cases in the past! So yes, allow the negative values!"

So, we needed to add the functionality... we compared some ways to do it, and chose the one we (the dev team) thought was the simplest, one that didn't require refactoring or changing the whole system.
After implementing it, the business-minded one among us asked why we did it. We explained how we tried to make it as simple as possible, but he had a simpler way: don't do it.

He didn't mean opposing the stakeholders' idea, but rather to change the business rules a bit so negative refunds don't even appear. He talked with them, and they agreed.

🏖 No new database tables, no new pages in the dashboard, no new documentation about how our "simple" refund system works, no headaches for employees, and no unforeseen bugs, just by deciding not to do something.

The moral of the story here is, just because you (& your team) can implement things and just because you can offer different levels of customization, doesn't mean you should. No stakeholder will reject a customization or an option; we all like extra options! Suggesting them will create a lot of new tasks in your project management app, and delay the launch unnecessarily.

I’m not encouraging you to slack off, but focus on delivering the product with a strong core, something that satisfies the stakeholders, and then start working on special features - only if needed.

6×9 + 6+9 = 69

This is a good example of how broken or slow tools may reduce your productivity and eventually get abandoned by you (& your team) – sometimes even if their use is enforced.

Without really talking about it, our team slightly abandoned linting and formatting in our codebases because they either took too much time, got in the way annoyingly, or the linter/formatter itself became a project to maintain.

After switching from eslint to oxlint, linting the whole codebase went from 17s to 0.4s (400ms!), we got rid of 15 dev deps (just for eslint plugins and stuff), and most importantly, we reconciled with linting.

The same thing is true for many other things. For example, if the backup process is complex, manual and takes too much time to complete, you'll probably evade it. But if it's as simple as pushing a button, you'll happily do it (maybe even multiple times per day).

Just took a look at my past notes about what I can build with AI – including business ideas – and almost all of them have either been built by somebody else or have become so simple that they went from a “nice idea” to an afternoon project, all within the past few months. 💀

Confusion costs time and money:

https://github.com/zakirullin/cognitive-load