19 Apr 2025 #misc
Yesterday, it took me nearly half an hour to calm down.
I had just rushed to the ER with a loved one. And I simply couldn’t switch off my brain’s fight response. All the stress chemicals must have been at their highest.
Once the emergency passed, my body refused to relax. I was still in fight mode. To take control back, I tricked my brain into focusing on something else: writing a 10-idea list.
Here are some other alternatives to try when stressed:
1. Follow the 3-3-3 breathing rhythm: Inhale for 3 seconds, hold for another 3, and exhale for 3.
2. Write 10 ideas about anything: Give your brain another task.
3. Do some physical exercise: Go running or lift some weights. Move anyway.
4. Listen to Dark Side of the Moon: I’m not a fan of Pink Floyd. In fact, that’s the only album I’ve known from them. But for some reason, I found it relaxing, especially track number 4, The Great Gig in the Sky. I feel those cries of desperation just like mine.
5. Listen to relaxing sounds: A river, ocean, or birds singing.
6. Watch stand-up comedy: You can’t be happy and stressed at the same time. Trick your brain into changing its mood.
7. Watch an episode of a TV show: TV can help you get out of your busy mind and distract you.
8. Meditate: Similar to #1. Repeat a mantra like: “breathe, calm down, and get out of your mind.”
9. Pray: Let your feelings out of your chest.
10. Do some cleaning: Again, it’s a way to trick your brain into doing something else. It helps you get out of your mind and into something physical.
18 Apr 2025 #mondaylinks
Hey, there.
Here are 4 links I thought were worth sharing this week:
#1. There’s a difference between a program and a product. It’s not the same hacking some lines for a one-time task as crafting an API for concurrent users. Vibe coding shines at one of the two (3min).
#2. Google claims AI generates 20% of its code. But those claims make us live in a post-developers era? (12min). AI is like driving a car in cruise mode. It goes where you point it, but you still need your hands on the steering wheel.
#3. Here are over 20 coding lessons (6min) from a coder with 25 years in the field. I had to learn the one about tracking request and responses the hard way.
#4. I’ll keep my personal blog, even if blogging is dead. A blog is a place without rules to share anything you want. If you have something to say, just put it on your blog (2min).
And in case you missed it, I wrote on my blog about “waking up experts” when specs aren’t clear (2min) and the first time I saw a computer (2min).
Here’s this week’s tip to get better at coding:
Learn some sort of automated testing.
Call it unit, integration, TDD, BDD, or anything else.
Chances are there are formal studies about the time required to maintain and fix bugs in codebases with unit tests compared to codebases without them.
But, empirically, the healthiest codebases I’ve worked with had unit tests.
Unit tests are a safety net when you’re making changes. Your coding life will be better with unit tests than without them. And you’ll miss unit tests when you work with a legacy application.
(Bzzz…Radio voice) This email was brought to you by…Join my course, C# NullReferenceException Demystified and in just 1 hour and 5 minutes, you’ll learn the principles, features, and strategies to get rid of that exception.
See you next time,
Cesar
Want to receive an email with curated links like these? Get 4 more delivered straight to your inbox every Friday. Don’t miss out on next week’s links. Subscribe to my Friday Links here.
17 Apr 2025 #career
I got fired from my first job, took down a database server with a badly written query, and was rejected from a FAANG. That all happened over the past 10 years.
But I’ve learned a lesson or two about coding along the way:
1. Estimates are just guesses. The problem is when your guesses don’t overlap with everybody else’s guesses.
2. Showing progress is better than doing the work. Did you guess you can finish a task in 4 days? No, no, no. You’re better off splitting it into smaller ones to show progress.
3. Proofs of concept are better than long documents nobody will read. When was the last time you read more than 2 or 3 pages of documentation? You’re better off creating a quick and dirty Pull Request to show an idea or a prototype.
4. The work isn’t over when you finish coding. Then come deployment, testing, adoption, customer support, and follow-up.
5. The more senior you become, the less it’s about coding and the more about meetings. Did you join Software Engineering because you like coding? Forget about that. You’ll spend more time in meetings. Daily meetings, estimation sessions, retrospectives, alignment meetings, brainstorming sessions, 1-on-1s, and on and on. In a perfect day, you’ll have 1 or 2 hours of coding without distractions.
6. You learn to love tests when you work with a legacy app. Call it unit, integration, end to end, TDD, BDD, or anything DD. You’re better off with anything that lets you know when you break something before shipping your code.
7. Don’t start a big major refactoring if nobody asks you to. This is what I call Massive Unrequested Refactorings. Either you refactor it as part of your tasks or make it official as part of your sprint planning.
8. Don’t waste time on pointless discussions about tools or tech. “Entity Framework is the best.” “No, it’s painfully slow.” “Nooo, stored procedures are the best”…Arrggg! Tools are just tools. That’s why we, coders, have the reputation of being opinionated and grumpy. And please, let’s not talk about clean code and best practices. That’s a subject I changed my mind about.
9. Always automate code style and best practices. Don’t ask a human to do the work of a machine. Code style perfectly matches the type of work for machines.
10. Projects fail because of communication problems. The same thing I’ve heard about marriages. At a past job, I was engaged in 3- or 6-month projects. We used the shiniest and brightest tools and frameworks. But some projects ended up off the rails. The only moving variable? Our communication patterns: Failing to communicate expectations, project goals and scope, action plans, and technical issues on time.
11. Every tech problem is a communication problem. It’s a corollary of #10. At a past job, I was new to ASP.NET Core and when trying to test my code, I changed a connection string in a settings file and ended up deleting another environment database. I used the wrong settings file in the wrong environment. Ooops! I didn’t ask, nobody told me, and there wasn’t any restrictions or guards in the code. It was a communication problem.
12. Solve the problem you have today. Premature optimization or just being lazy, don’t solve and optimize for a problem you don’t have yet. Avoid writing just-in-case code.
16 Apr 2025 #writing
For almost 5 years, I wrote and only heard crickets.
Then, everything changed when I bought my first writing course and started taking writing seriously, not just for fun, but something I was committed to improving.
I started to see more likes, comments, and shares on my content when I started doing these three things:
1. Study writing subskills
There’s more to writing than just typing.
Writing is a set of subskills to master: headlines, introductions, outlines, storytelling, copywriting, cliff-hangers, and conclusions.
I took a notepad and wrote a list of 10 writing skills I wanted to learn. Then I started working on each of those subskills one by one.
Instead of long and boring introductions, I started using one-sentence openings to attract readers into the rest of my writing.
2. Hand-copying to go to the writing gym
“Writing is learned mainly by imitation”—Writing to Learn by William Zinsser
I started copying sample pieces by hand as an exercise to learn enough copywriting to be dangerous. But I also applied it beyond copywriting.
When we write by hand, we’re forced to slow down and notice and absorb patterns. So next time, we sit down to write, we’ll have those patterns in the back of our heads.
Grab a post or a book section from your favorite writer and copy it by hand. These days, I’m hand-copying some of James Altucher’s books.
Copy, imitate, and then adapt it to your own style.
3. Tell more stories
“Let Wikipedia spit out facts, you have to spit out stories”—Tim Denning
There’s a reason why a Wikipedia article or a scientific paper sounds soulless and emotionless. They’re full of facts. They’re written for a selected few. They’re not written to be remembered.
The easiest way to make our writing memorable is with stories.
I could tell you, “No job is safe.” You’ll probably nod in agreement and forget it. But if I tell you, “The day my boss called me to his office and asked me to hand in my company ID, I learned there was no safe job.” Chances are you’ll remember the second one more.
We’re driven by stories. That’s what we’ve been doing as humans since we climbed down from trees and sat around the fire in caverns.
Thanks to sharing my stories from my past jobs, I finally saw traction with my writing. I finally got more than two likes and not just “Thanks for sharing” as comments.
If you want to stand out from AI-generated content, don’t just share facts. AI can generate facts. Only you can generate stories that connect.
15 Apr 2025 #misc
An owl blinking in a large forest made us all jump in surprise.
It was back in 4th grade.
We all were sitting in a large conference room while a guest teacher disassembled a computer. He took every part, showed it to the class, and told us its name.
# # #
That year, the school competition was to build a computer out of recycled materials.
I built mine with boxes and Styrofoam. OK, when I say “I built,” I mean my mom or my aunt. I don’t remember exactly who. My display was made with an old X-ray image.
We exhibited our computers on tables in the school hall while a group of teachers walked around taking notes, trying to find the most creative one.
I didn’t win the competition. My X-ray display wasn’t enough to win.
But after the competition, I put my computer on my desk at home. I pretended to work with it. Sometimes I still pretend.
# # #
After putting all the parts back in place, the guest teacher turned it on.
We all jumped in surprise. We started pointing at an owl blinking in a large forest. After a few seconds, the forest became an enchanted house with bats flying around. I was frozen sitting next to my friends, staring at that thing. Whatever it was that thing.
It was an animated wallpaper. LOL. It must have been Windows 95 or 98.
# # #
I don’t remember what happened to my first computer ever.
But, fast forward a few years, we had our first real computer at home. Or my second one.
It was a Windows 98 computer with a 56K internet connection plugged into a wired phone line. Oh! The famous buzz when we picked up the phone while my dad was connected to the internet. The days of Yahoo and Altavista.
Only my dad used the computer because “it wasn’t a toy.”
We had to restart the computer after every minor configuration and every software installation. We used a protection filter on our displays. They were almost radioactive. And after using it, we put pajamas on our computer before going to sleep. Dust was its arch-enemy.
My favorite wallpaper was an astronaut jumping around in outer space. That was Windows 98.
And that’s how old I am.