14 Apr 2025 #writing
1. Title your reaction posts with “Re:”
I’ve written response or reaction posts before, but I named them with my own titles. Yesterday I found this idea to use “Re:” in titles for response posts.
2. Make your urls easy to pronounce.
I already learned from Derek Sivers to write short and memorable URLs. But this time, I also learned to make them easy to pronounce. For example write URLs using “dash,” which is easier to pronounce than “underscore.”
More blogging tips? Here are two tips I’ve been following. They’ve helped me keep my daily blogging streak.
13 Apr 2025 #writing
Imagine stepping into a restaurant, only for the waiter to say, “You don’t seem to have enough money to eat here.” Would you stay? I know I wouldn’t.
Never, ever, blame your readers.
That’s a mistake I’ve learned to avoid in my own writing, especially when writing sales copy for landing pages.
Instead of blaming your readers, make them feel heard and understood.
The other day, someone tried to sell me access to an online community and shared his landing page. The headline? “You didn’t go to Harvard. You didn’t apply to McKinsey.” He was trying to sell leadership coaching.
Another day, someone shared the landing page of a fiction writing course he was preparing. The headline? “You don’t know how to tell good stories.”
I didn’t want to continue reading past the headline of those two pages. I felt like a schoolboy getting on the bus, walking down the aisle, hoping for someone to smile back—only to be ignored or bullied.
A headline should attract the right audience.
But we should attract the right audience without making them feel dismissed or rejected.
Someone who feels dismissed or rejected stops reading, and worse, they won’t buy.
A couple of alternatives for those landing pages:
- “You don’t need to spend 4 years and pay Harvard tuition to be a leader people want to work with.”
- “It’s hard to tell good stories. I tried plenty of templates and frameworks. None of them worked. Until I learned this method.”
Boom! Just like that, no more pointing fingers at the reader. Would you keep reading if those two were the headlines? After all, nobody likes being blamed.
12 Apr 2025 #misc
“Do anything to wake up the experts.”
That was a phrase we repeated at a past job. We were building a gateway-like software to connect small companies to the Government’s tax office.
It took us a couple of years to build a minimum viable product. We were behind the Government’s changing requirements and our own clients’ expectations.
We were late almost all the time. Often we knew we needed to finish something, but we weren’t sure what or how. Apart from emails or conversations with clients, we didn’t have clear requirements or specs.
In those moments, we woke up the experts.
To show some progress, we built on a quick prototype or a half-baked idea. Then, after looking at that half-baked idea, a stakeholder, project manager, or product owner, would speak up, saying that what we had wasn’t what was needed. Then, we started to work on a real solution.
When looking at a bad answer or a half-baked idea, it turned out everyone was an expert.
The fastest way to get a good answer is by giving a bad answer, by waking up the experts.
For more workplace lessons, check the leadersship lessons I learned from this project and the lesson from the most expensive hambugers I’ve tried
11 Apr 2025 #career
If you’re looking to start your coding career, start by understanding each company type has its own vibe.
These days, stability and job security are hard to find. Recession, high interest rates, layoffs, AI, you name it.
In over 10 years, I’ve worked in non-tech corporate companies, tech companies, and software agencies. This is what I’ve found.
Non-tech corporate companies
I started at a “boring” job.
I was at the IT department of a large company in my city. That was my first contact with office politics and the corporate world. Spoiler alert: I was fired.
This type of company in one word? Slow.
If you land a job here, expect more office politics and bureaucracy. The larger the company, the more you’ll find. They tend to offer more benefits and might feel stable.
But don’t expect to work on the shiniest and brightest tech stack or tools. Be ready to work on a legacy codebase with outdated or little documentation, fixing bugs and hacking to add new features without breaking anything.
Tech companies
Tech companies tend to move faster than corporate jobs.
In a tech company, you’re helping the company make money. You aren’t an expense anymore. That often means higher salaries.
This is the place where you’d find TDD, DDD, any other DD methodology, code reviews, Kubernetes, the Cloud, and the shiniest and brightest.
But, they also come with higher risk of burning out.
Software agencies
Here, you are an employee assigned to a client company or project.
There’s good money with agencies if you live in a place with low cost of living and earn your salary in stronger currencies. Money will pass from the agency to your bank, while they take a good chunk of it. That’s the business.
Also, understand that companies prefer agencies as a risk-free alternative to hiring. When they don’t need more hands on a project, they’re just an email away from letting people go. Again, that’s the business.
Expect client rotation and possibly months without pay while the agency finds you another client.
With agencies, there are fewer chances of growth since you’re sold as a pair of hands.
Of course, YMMV.
Rather than choosing a company for its benefits, start experimenting with your career, then make a 5-year career plan (or intention), and pick the jobs and places that take you closer to that plan. That’s a lesson I wish I had known 10 years ago.
10 Apr 2025 #writing
If you want to start a coding blog, don’t start with a deep dive of the Linux Kernel or other cryptic topics, unless you’re an expert on them.
Instead write short “Today I Learned” (TIL) posts.
TIL posts are shorter posts where you share something you’ve found or figured out.
When writing TIL posts, you don’t have to worry about long introductions or conclusions. Just write a good headline, a code block, a quick explanation, and your sources. And write using your own words, like in a conversation with a coworker. Here are my TIL posts as example.
That’s enough to make a post worth reading.
TIL posts invite people into your learning journey.
Don’t try to lecture the coding world about what they should do. Start documenting your learning instead.
Instead of writing “5 VS Code extensions every coder should install,” try “TIL: 5 VS Code extensions I couldn’t avoid installing.”
Or instead of “5 Git commands every coder should know,” covering the same basic Git commands, write “TIL: 5 Git basic commands to use everyday” or “TIL: How Git Status works.”
Did you spend 20 minutes or more figuring out something? write a TIL post. That’s the easiest way to start a coding blog. And don’t think of writing your own blogging engine.