With two days left in 2022, now is as good a time as any to reflect on this past year. I went through my Twitter favorites to find quotes that inspired me or at least made me pause. I thought I'd share them with you.

These quotes were supposed to be in no particular order. However, I'm starting with my favorites.

“If you’re not concerned about naming and other language benefits, you are probably only shipping apps, not products.” — Vaughn Vernon

I got this quote from a presentation Vaughn Vernon gave for SkillsCast. The recording is only available to the participants, but the deck is available to download.

I often advocate for Domain-driven design, and I believe in the importance of naming to convey the purpose of an application. I had many discussions on the topic, especially after I opened a "Domain" folder, and all I saw were "Managers", "Entities", and "Constants" folders.

I would recommend Domain-Driven Design Distilled to anybody interested in shipping products rather than apps.

“If I had more time, I would have written a shorter letter.” — Mark Twain, Blaise Pascal…

I thought this quote was from Mark Twain, but it could go back to the French mathematician, physicist, inventor, and philosopher (oh my) Blaise Pascal, born in 1623. I love the simple idea that one needs to invest time to make something concise and efficient. And time was a rare commodity for Blaise, who died at age 39.

“If you're not embarrassed about last year, you're not making any progress.” — Katya

I couldn't find the tweet for that quote. It was probably in a video. Nevertheless, these are wise words from my favorite Drag Queen: Katya.

I worked on a framework and a CMS for about ten years. They have a special place in my heart because they allowed me to learn PHP and SQL. They allowed me to create websites rapidly when I started as a freelancer. They were shiny baggage for my first jobs. We built websites for international companies with them, and I was very proud of that. Twenty years later, I learned a great deal about development. My best practices now are very different. So yes, I cherish them, but I'm also quite aware of their flaws.

Now, my 2 cents. Yes, your code is gorgeous, and it's the best you can do. But it's just code. And it's just now. If you're lucky enough to get feedback and suggestions from another developer, enjoy it! You might learn something. Also, be kind to other people's code. Just like you, it's the best they could do at the time.

“If you're not embarrassed by the first version of your product, you’ve launched too late.” — Reid Hoffman

I found this quote on Insider. It made me think of Katya's, and that made me smile.

It happened to me a few times that a stakeholder would come with a fives years end state in mind. The project would turn into a never-ending cycle of meetings, each bringing feature creep. It's as if nobody heard about Agile software development.

If this happens to you, take a breather. Hold hands with your stakeholder and ask yourselves: what's the minimum viable product, its essence, and essential features? Once you figure that out. Deliver that MVP. Then, iterate, increment, and evolve until you have that "dream" product.

“Our job as software engineers isn't to write complicated programs. It's to paint a landscape in which the program is simple and obvious.” — John Arundel

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

I like these two quotes together. It's like they are echoing. Maybe echoing with Blaise Pascal as well.

Writing software is hard. Writing understandable software is harder. But I believe it gets easier with experience and time. In my early years, I would write classes with thousands of lines and probably multiple inheritance. Nowadays, I'm all about Single-responsibility principle and composition over inheritance. I found it easier to test. Easier to get back to it later. And it greatly reduced maintenance: if you add a new feature you probably won't touch the previous components.

So, if your class has thousands of lines, maybe ask yourself: "What's this class doing?". If the answer has multiple "and", consider extracting these as components. You'll probably see clearer, and you'll be happy you took the time, especially if you have to tweak the code many months later.

“Technical debt is like having to do the dishes before you can start cooking” (translated from French) — Olivier Mansour

Sure, sometimes it's fine to clean a few dishes before you can start cooking, but what if you need to eat right away because you have Karaoke that night? How long will that take? Will you miss Karaoke and be sad all weekend? Don't let dirty dishes ruin your Karaoke!

While at HelloFresh, I came up with the idea of Chapter Days. That proved to be a great tool to take care of technical debt, among other things.

Other quotes I appreciated

“A microservices architecture is NOT about a bunch of services talking to each other a lot. In fact, we should aim to MINIMISE how much services talk to each other, and preference for asynchronous interactions when they do.” — Graham Lea

When we design interconnected systems, I always look for the least coupling possible. I don't want my application to be the point of failure of another. Using asynchronous communication is one of the tools for that. Besides, what's the point of having services if you end up with coupled components that now have networks between them?

Still, asynchronous interactions are tricky. I regularly challenge events that are used as triggers to query an API, to get the data which, with a bit of luck, is connected to that event. If you emit events about changes, attach those changes to the event. And if the payload is too big, save it to a S3 bucket and provide a link in the event. Having the payload on a S3 bucket guarantees it won't be impacted by database updates (that is, if you are lawful good). Also, serving payloads from a S3 bucket is extremely cheap. Way cheaper than having a service running with an API to query a database.

“Use messaging to reduce HTTP calls, otherwise your services are only a distributed monolith.” — @Dbcodes

Again: replacing synchronous communication (HTTP calls) with asynchronous communication (pub/sub). It's okay to have data duplicated across multiple services as long it's only the data they need. A red flag would be an application duplicating the entirety of another application's data. That would be a sign that logic is not in the right place.

Microsoft has a nice article about Data considerations for microservices.

“A genuine problem in tech is that we’ve created a culture where people switch jobs too often to experience the consequences of their product & technical decisions let alone have to fix them.” — @Carnage4Life

I agree with the turnover, but I wouldn't necessarily blame the developers. I believe everyone is doing the best they can. Now, how much does the company value its software assets? Where's the cursor between software quality and delivering features? And what's up with the review process? You must be this tall to merge.

B-bye 2022

Any quotes you'd like to share? Find me on Twitter before it collapses! See you in 2023 ++