Always serving someone

It’s Monday morning, and you open up a handful of files. You want to get a sense of that piece of the codebase you’re about to work on. You’re soon finding yourself surrounded by circumvoluted code, abstractions pilling on each other, classes filled to the brim. You end up spending your day trying to figure things out.

This is a lousy Monday.

What happened then? Well, the person/people who wrote the code forgot they’re delivering a service. Maybe it was you.

I mean, it’s easy to tell yourself that you don’t give a hoot about your users when you’re knee-deep into SQL queries. You’re not here to provide a great service to your users. You’re here to fetch data, pass it around between abstractions, and send it to the front-end team.

But what about the person who’ll work on your code two years from now? What about your future self that’ll get back to that awful transaction you wrote last month.

I know it’s neither easy nor possible to write beautiful code. The deadline is looming. Everyone has their own likings and tastes when it comes to design patterns.

But when I can, I like to think myself as a designer:

• I state what the problem is.
• I explore solutions.
• I produce something that’s both functional and beautiful.

Sure, well-articulated code doesn’t come if you’re burning the candle at both ends. You can’t conjure up beauty when you’re always fighting against ludicrous deadlines.

Aesthetic needs room to breathe.

This extra time will save you a massive amount of time over and over again. It’ll compound. And what was a lost Monday to you will become a joyful one for another developer.

Writing expressive code is me providing a great service to myself and my teammates. We are my own customers. And I want to serve them well.

Noticed something? Ping me on Twitter or create an issue on GitHub.

Cheers,

Rémi