Hey there!

Summary of this email:

• When we do duplicate code (+ 4 Rules of Simple Design course published in the Premium plan)
• Are we going to stop using Cursor?

Estimated reading time: 3 minutes.

⌨️ When we do duplicate code

> One of the biggest sins in programming is duplicating code. - That's why we create abstractions. > But duplicated code is better than a bad abstraction. - That's why we duplicate code.

This is a contradiction we run into many times while programming, but... when should you duplicate code and when should you abstract?

Here we can lean on 3 principles: - DRY - WET - SSOT

DRY: Don't Repeat Yourself > Every piece of code or logic should have a single representation in the system.

The core idea is to avoid spreading the same logic across different places to improve cohesion.

It's very useful when we have deep knowledge of the code and we know that an abstraction at a certain point will save us future headaches.

This rule doesn't mean zero literal duplication, but rather avoiding duplicating knowledge (business rules, behaviors...), which prevents things from getting out of sync.

WET: Write Everything Twice > Also known as the Rule of 3. Don't create an abstraction until the 3rd time you see duplicated code.

It doesn't mean always duplicate, but rather wait to find stable patterns before abstracting.

It's useful when we don't know the codebase well or the code is evolving very rapidly. By waiting for those 3 times, we'll see if the abstraction makes sense or if it's better to keep things duplicated because the code will evolve differently.

SSOT: Single Source of Truth > A principle that states each piece of data or information should exist in only one authoritative place within the system.

It's very useful to apply in configuration files. It's better to have a single configuration file and declare database connection parameters there than to have n files with duplicated connection strings.

In summary, as a general rule, we duplicate when we don't know how the code is going to evolve.

For that we apply the Rule of 3.

For config files or other cases where we're very sure we want centralization, we create an abstraction.

All this and more is covered in the 4 Rules of Simple Design course that we've just published at 100% in the premium plan. 😊

💻 Are we going to stop using Cursor?

This year has been the year of coding agents. Since Cursor introduced them around March, the way we code has changed quite a bit.

And so has the pricing model.

Cursor became popular because of its pricing: $20/month and you get nearly unlimited access. The usage model was per request. You had X amount of AI usage per month.

From then until now, agents have gone from being able to edit a couple of files to making entire PRs. It no longer makes sense for Cursor to charge the same, since a request in March cost Y, but one now costs Y*10.

We have, among other IDEs, the annual Cursor plan, but with the format change, it might not make sense to stay there. Tomorrow at 9am CEST, on Cafe con Codely, we'll share our current thoughts on the topic. You can follow it on YouTube or Twitch.

And since you've made it this far in the newsletter, here's the joke of the week, which I know you were waiting for:

> Why don't Docker containers have friends? Because they're always isolated. 😂

Cheers!