12 Feb 2025 #misc
A bit of nostalgia, reflection, and compilation today.
This is what happened, not today, but around this day in my blog:
Last year, before being laid off, I had just finished another short project with a contracting client. It was a project to support events, like weddings and conferences, in a hotel management software. That project taught me more about leadership and project management than coding. I wrote two lessons I learned from that project.
In 2023, I started a 4-part series on NullReferenceException with a post about when NullReferenceException is thrown and how to avoid it.
In 2022, I was still running Monday Links here. I wrote about Daily Meetings, Estimates, and Challenges. From that episode, I included a post I found with 5 signs to look for when it’s time to quit your job.
By the way, these days, I’m not running Monday Links, but Friday Links on an email list. Every Friday, you’ll get a 2-minute email with curated resources about programming and software engineering. Join here.
In 2021, I was working with a Stripe-powered payment processor. And I wrote about how to use the Decorator pattern to implement retry logic when sending payments to Stripe. The analogy I used to explain the Decorator pattern was IronMan wearing the HULKBUSTER suit.
In 2020, I used the Pipeline pattern to create a pipeline of steps to make reservations. And since I had already used it to create invoices and notes in an invoicing system, I decided to write about it.
In 2019 and 2018, I didn’t write in February. It’s a shame. Well, I was still trying to find my rhythm and what to write about.
11 Feb 2025 #misc
Rewriting legacy code that works isn’t a good idea.
At some point in the rewrite, we have to maintain two systems. Fixing bugs in the legacy one while making sure they’re fixed in the new one too.
These days, Antirez, Redis’ creator, wrote in We are destroying software:
We are destroying software pushing for rewrites of things that work.
Rewrites are expensive and time-consuming. Every rewrite starts with good intentions, but they all end up being the next application to rewrite.
Interestingly enough, I’ve been involved in full rewrites at every job I’ve had.
At my first job, I had to rewrite a WebForms app into a WinForms app. That was the solution to a networking issue. By the time I left (actually, I was fired), there was an ongoing project to unify every separate department application into a single “unified” platform. Another rewrite.
At my second job, similar story. A WebForms app backed by 1,000-LOC stored procedures. We rewrote it using ASP.NET Web API with NHibernate. But, by the time the president (a coder in a past life) found out that NHibernate was slower, he ordered another rewrite. A rewrite in the middle of another rewrite. It took us around five years to finish the first prototype of a working app.
My next job rewrite was from Python jobs to background jobs with ASP.NET Core. The idea was to read a database table with price updates for rooms at a hotel and call the Expedia or Booking.com API. The challenge? We couldn’t send two price updates for the same hotel at the same time. These days I’d use Hangfire for that.
Next job? Rewriting a VisualBasic WebForm app into Blazor. Oh boy!
You see? Chances are you can’t run away from rewrites and legacy code. And funny enough, “Working Effectively with Legacy Code” has been sitting in my to-read list all these years.
10 Feb 2025 #misc
To stand out, do what everybody else isn’t doing.
That’s a lesson I learned from Isra Bravo, Spain’s top copywriter, and maybe the country’s top solopreneur.
When everybody is doing sales calls, putting chatbots on their websites, or offering personalized demos, it’s time to stand out by doing something completely different.
Recently, I discovered Keygen, a licensing software and its no calls policy.
The founder, probably being an introvert, wanted to ditch sales calls and in a moment of frustration, he deleted the “Book a call” button from his company’s website.
Instead of sales calls, they improved their messaging. They clarified what their tool does and how much it costs.
And when someone requests a sales call, they simply reply:
“No, we don’t do calls, but happy to help via email. Feel free to CC any relevant team members onto this thread.”
Some of Keygen’s prospects loved the #nocalls policy. Too many calls are boring, draining, and time-consuming.
Sure, they might be leaving money on the table. But we don’t want money from just anyone, only from the right clients. The ones that trust us, respect us, and pay the right price.
With a clear message and open pricing policies, we attract the right clients. We attract clients based on the messaging and the values we project. And that works for anything else in life.
#nocalls is an idea worth copying and stealing, especially if selling feels draining and if you prefer to think of in terms of helping, not selling. Better messaging = more sales.
09 Feb 2025 #writing
Imagine writing a blog post every day for over 20 years.
Seth Godin has done just that. A post a day for over 20 years means more than 7,000 daily blog posts. That’s more than impressive. I’ve always admired Seth’s blogging rhythm.
Inspired by Seth Godin and other daily writers like Tim Denning and Herbert Lui, I started writing daily on my blog in November 2024. I even created a new tag, /misc, for everything outside of software engineering and coding. That’s part of my strategy in these days of dead blogging.
For my daily writing challenge, one headline and one main idea are enough to call it a day. No cover image. No need for 10 points. If it’s longer than a tweet, it’s OK to publish. Around 200 words is my sweet spot.
A daily writing habit has made me more conscious of the content I consume.
When we set the intention to write daily, we start to see content everywhere: conversations, quotes, passages from books, podcast episodes, comments on social media, TV shows…“Oh, that could be a post, I’d better write down that idea.”
My goal was to publish 100 daily posts starting on November 1st. This is my daily post #100. Mission accomplished.
08 Feb 2025 #career
One day, you’re the only team member and the next, you’re a leader, without asking for it.
Been there and done that.
Back in one of my first jobs, at some point, I was the only one in the mobile team.
We were building the prototype of a mobile app with Xamarin. I don’t know if that’s still a thing. When there was too much work for me, two team members joined from other teams. They were learning Xamarin and getting up to speed with the business domain.
And the next day, I started to be responsible for their work. Management asked me, not them, when they were behind schedule. I thought my job was only answering their questions and offering help. Nope!
I wasn’t a leader and I didn’t want to be one. But that day, I became their leader by omission.
And recently, it has happened to me again.
But this time, I was on the other side of the table. I joined a small agency and got assigned to a project with only one team member. He was a lone wolf, working on his own corner with zero dependencies and shared work. The challenge came when we needed to sync our work and keep an eye on dependencies between our tasks. He was so used to working alone, and I was expecting more collaboration.
When you’re the most senior member or the only team member, as soon as new pairs of hands come, you become the point of contact, the go-to person for questions and problems. Upper management starts to ask you about the new team members. You don’t ask for it, but you become a leader. A leader by omission. And remember as a leader, you’re not the best coder anymore.