🎒 Why Do Software Engineers Think Long-Term?

Hey 👋,

I am surprised and thankful when I see the opening rates of this newsletter. Always above 40%. It's impressive and I never thought I'd be here after less than a year.

Don't be a stranger and reply if you have comments to the article. I love hearing those.

Anyway, thanks again and I hope you have a good week,

-------------------

Compound Work

Developers work on the same project daily, constantly adding value in the same place.

Software development is compound work.

A developer's work today will affect the team in one year or more. Today’s work matters as long as the software is running and used.

Compound Work and Value

Why does it matter that software engineers’ work is compound? Like compound interest, the more work we do, the more we get out.

Let’s give an example. Imagine a worker that adds 1% of value to a project every day, and let’s say that the projects always start with a value of one hundred.

If the work is not compounded, the project starts anew every day. Therefore, the worker adds one point of value every day.

If the work is compounded, the employee starts where she left off. Therefore, the first day finishes at 101, the starting point of the second day, which then ends at 102.01. On the second day, the worker added more value than on the first day: 1.01 (102.01 - 101) instead of 1 (101 - 100).

By Friday, the worker in the compound case added 1.04 points versus 1 point of the non-compound worker. This is 4% more in just five days.

If we apply this progression during a whole year (assuming 200 working days), the compound worker adds 7,17 points on the last day. In contrast, the non-compound worker keeps adding 1 point. This is a difference of 717% in just one year.

These numbers are not real. But, it gives an idea of the massive impact of compound work.

Current Best Practices Leverage Compound Work

How can we take advantage of that? Actually, we are already taking advantage of it. Most of the best practices in software development are about long-term thinking. For example:

• Clean code. Writing readable code makes our work easier to maintain, therefore, easier to keep adding value to it in the future.
• Automated Testing. Software projects are complex, and their parts are interrelated. Fixing a bug in one place might break other areas. Having tests makes maintenance easier.
• CI/CD Pipelines. Releasing new versions of our project takes effort. A few releases mean more changes per release and more risk of errors. An automated pipeline means more releases where problems are caught earlier and fixed faster—increasing the value over time.

Think Long Term

In the end, all this is summarized with:

Our decisions today matter tomorrow.

Surprise! As if you didn’t know this already 😂.

Avoid hacks, write readable code, test your code, automate manual processes, etc. Think of how every decision affects the project in one year.

Yes, I know what you are thinking. “All this is very nice, but I need to release the project next month, Llorenç.” Ok, I understand that. But find a balance and make sure you know the trade-offs when taking shortcuts.

A small decision today can hugely impact the future because our work compounds.

This is not just for strategic decisions like which technology we choose or which infrastructure to build. This is also important for individual team members. For example, if someone solves a problem that took him two hours debugging, it’s worth documenting it or adding a test just for that.

Try always to make life easier for your future self.

Remember the famous quote:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

If you like this post, consider sharing it with your friends on twitter or forwarding this email to them 🙈

Don't hesitate to reach out to me if you have any questions or see an error. I highly appreciate it.

And thanks to Michal for reviewing this article 🙏