Best of 2024: My Year in Review

If I had to define my 2024 in one word, it would be: Change.

In 2023, I got burned out and sick. And when I was laid off in early 2024, I felt both worried and relieved. I needed some time off.

That layoff taught me valuable lessons about life, career, and money.

My coding side

2024 felt like a rollercoaster.

After getting laid off and sending dozens of applications, I decided to take some time off to take care of my health. A mini-retirement.

After the radio silence and a few “thanks, maybe later” replies, I started freelancing with a small software agency. That helped me stay afloat for a month or two without running out of savings.

In 2024, I doubled down on my online presence.

I created two video courses on Udemy: here and here. I hired Microsoft’s Copilot as my assistant to create the promotional materials. All the content and recordings were made by me. A human.

My career reflections

Being laid off gave me time to reflect on my career after over 10 years of non-stop work.

I wrote about the lessons my first job taught me about coding and life and shared 8 lessons for new developers, like in a free mentoring session.

Last year the coding world went nuts when Devin, “the first AI software engineer,” was released and I gave my predictions for coding in 2034.

If you’re reading this from the future, let me know if I nailed it with my predictions. By the way, do you have flying cars or are you still dreaming about them?

I created a 7-day email course to share the lessons I wish I had known to survive a career in software engineering. I share what I’d tell my younger self starting his first professional coding job.

And I moved my Monday Links series to an email list. Every other week, you won’t get Monday Links, but Friday Links in your inbox. For free.

My most read posts

If you missed any of them, here are my five most read posts from 2024:

  1. How to Test Logging Messages with FakeLogger
  2. It Seems the C# Team Is Finally Considering Supporting Discriminated Unions
  3. Testing DateTime.Now Revisited: .NET 8.0 TimeProvider
  4. Two new LINQ methods in .NET 9: CountBy and Index
  5. I applied at a FAANG and failed: Three interviewing lessons

My writing side

I will remember 2024 as the year I went all in on my writing.

After writing for more than 5 years, I took my first writing class. That gave me momentum to keep the writing ball rolling. I even created a tag /misc to write about everything outside programming and software engineering.

Starting on November 1st, I began writing daily on my blog. Those daily posts fueled my writing everywhere else.

LinkedIn

After months of inactivity in 2023, I revived my LinkedIn account from Zombieland.

I challenged myself to write 100 short-form native posts. I started with 1 post a week, then 2, then 3… I doubled my follower count and had two or three “viral” posts. Those are vanity metrics. But the main benefit? The fear of writing in social media is gone!

It turns out LinkedIn is not that cringy when we follow the right strategy.

dev.to

In 2024, I kept reposting some of my posts on dev.to.

The dev.to team featured three of my posts in the Top7 posts of the week. These ones:

  1. Four Lessons My First Job as a Software Engineer Taught Me About Coding and Life
  2. I Applied at a FAANG and Failed — Three Interviewing Lessons
  3. I Don’t Use “Pushy” Questions in Code Reviews Anymore. This Is What I Do Instead

Parting Thought

Taking some time off to take care of my health was the best decision I made in 2024. Being physically healthy spreads to all other areas of our life.

And definitely, Monday mornings don’t feel the same when you wake up to do something you love.

Thanks for reading, and happy coding in 2025!

Don’t miss my best of 2023, 2022, and 2021.

The Best Way to Get Better at Writing Code Isn't Just Writing More Code

More than 10 years ago, I started my real coding journey with a Google search: “How to be a better developer.”

University had taught me a lot of things I didn’t need. I had to teach myself the ones I needed.

I went down the rabbit hole. That search gave me lots of ideas and inspiration:

  • Write specs
  • Write unit tests
  • Document your code
  • Learn Functional Programming
  • Write self-documenting code
  • Read Clean Code
  • Start a blog

Yeah! Starting a blog. That inspired me to start this very blog. I didn’t know I was about to enjoy writing so much.

Those are good ideas. But what has worked best for me is reading other people’s code.

In fact, an ex-coworker taught me that lesson. That was his secret technique, even though he was our team’s architect, and we thought he didn’t need to study anymore.

So read more code. But read actively. You can’t read code like fiction, glancing over words on a page:

  1. Find a medium-sized library you use or find interesting
  2. Download its source code
  3. Compile and run it
  4. Look at its unit tests
  5. Debug one feature

See how the library authors implemented a feature.

If you find a new keyword, look it up. If you find a new data structure, look it up too. If you find a new method in the standard library, again, look it up.

Once you understand how a feature is implemented, try to recreate a bare-bones version without looking at the original code. That’s how you make sure you truly understand the code.

I used this strategy when I learned about the Specification pattern. I found a library implementing that pattern. I downloaded and read it. Once I got the main idea, I wrote my own dummy implementation. Then I wrote a post about it.

Don’t just write more code to get better at coding. Read more code. Actively.

Here's the Best Productivity Hack I Learned in 2024

It wasn’t a time management technique. It wasn’t the Eisenhower Matrix, Eat That Frog, or the Pareto Principle.

It was an energy management technique: eating better.

Eating better. Eating for energy.

Eating better means no processed foods, no carbs, and no sugar. We all know we should eat better. Nothing new! Right?!

But from “Glucose Revolution” by Jessie Inchauspé, eating better means reordering how we eat, without sacrificing those delicious candies.

Salads first. Proteins and fats second. And carbs and sweets last.

Reordering how we eat keeps our glucose spikes under control

Glucose spikes are the reason why we feel tired all day and hungrier even after eating. We have too much sugar in our bloodstream.

Simply by reordering how I ate, I got my energy back:

  • I don’t get sleepy after lunch.
  • I don’t drag my feet to get through my afternoons.
  • I lost ~4kg in two months without much effort.

Also, to control our glucose spikes, we could walk for 10-15 minutes after eating. The longer, the better.

Thanks to my new diet, my afternoons are as productive as my mornings. No more feeling like a zombie at the end of the day.

We are what we put in our bodies. And if we eat well, we think well.

The Best Books I Read in 2024 (Even If I Didn't Read Many)

In 2024, I stopped being a serial book reader, keeping a tally of books I read.

I went from “let’s read anything and everything” to “let’s read what I need to read.” From just-in-case to just-in-time reading. I realized I had a long list of book notes, but I didn’t remember reading some of those books.

Naval Ravikant’s reading strategy helped me change my mind about books. And I adopted some reading methods into my own reading method.

Instead of reading a long list of books, I immersed myself in a single writer’s world.

By accident, I found James Altucher’s work and I’ve been following him since then. I reread “Reinvent Yourself” and read “Choose Yourself.” Those are the best ones I’ve read.

Reinvent Yourself

This was one of those books I didn’t remember reading, even when I had notes. Later, listening to James Altucher’s interviews, I made the connection and reread it.

We can’t rely on the same skills we learned 5 years ago. We need to reinvent ourselves every 5 years. And here, reinvention means finding new income sources.

To start a reinvention, we should read 500 books on any subject. That would take us around 5 years.

Choose Yourself

This is the best book I read this year.

Often, we’re waiting for someone to save us or choose us. Someone will see how smart we are and give us a job. Someone will see how attractive we are and choose us as life partners…The government, our boss, or a rich guy that doesn’t know what to do with his money. One day, someone will save us.

The truth is no one is coming to rescue us. We should choose ourselves.

We start choosing ourselves by taking care of our body, mind, and spirit every day: moving our bodies, doing something creative, and writing 10 ideas a day. Working on things we love and being surrounded by people we love.

And we don’t need anyone’s permission for that. The internet has created a world without permissions. The only permission we need is from ourselves.


Apart from these two, I read “Choose Yourself Guide to Wealth,” and I have on my pile to read “The Power of No” and “Skip the Line.” All of them by James Altucher. Yes, I’m immersed in James Altucher’s work these days.

Some honorable mentions: this year, I also read “E-Myth Revisited,” “You Are a Writer,” “Slow Productivity,” and “The Anxious Generation.”

I can’t say one book has changed my life. But, those two books gave enough ideas and inspiration to take care of health and get life on track after a season of burned out.

One Technique to Ease Your Onboarding—and Not Make New Team Members Feel Lost

The first moments show how you’re going to be treated for the rest of the time.

It applies when you go to a restaurant, call a customer service line, or go to a bank. And the same is true when joining a new team as a developer.

The first day I joined my last full-time job was awful.

I was speaking a foreign language for work for the first time. I was working from home for the first time too. My company laptop didn’t arrive that day. I was told to install the software project with long and outdated instructions. I was completely lost.

I got a call from my boss’s boss that day, promising I’d “be in trouble” if I didn’t install that project before the end of the day.

The funny thing is, I didn’t have to work with that project at all in the 5 years I was there.

Instead of making your new team members feel lost, set clear goals for the first day, week, and month.

For the first day, a new team member should:

  1. Install the right tools: email, VPN, chat clients, etc
  2. Introduce themselves in Slack or company chat
  3. Get to know their team lead

For the first week:

  1. Have 1-1s with all team members
  2. Have the working environment ready
  3. Complete a dummy task to understand the project workflow

For the first month:

  1. Complete a medium-sized task, with almost no guidance

Make it really easy for new team members to install your project and its dependencies. They should be ready to work by running a single script or pressing a button.

Make it really easy for new team members to follow existing rules and conventions. Don’t rely on outdated documents. Show sample code or work that follows those conventions.

Get your developers “up and running” as quickly as possible. Show them how you’re treating them for the rest of the time.