16 Jul 2025 #productivity
About five years ago, I became obsessed with productivity.
I devoured the entire Lifehacker site, looking for the best system and the perfect tool to finish my work. Pomodoro technique, Eisenhower matrix, inbox zero, a todo.txt file. I tried them all.
After testing some of those techniques and simplifying my system, I’ve found what really works, at least for me.
#1. Follow your energy levels. Work on the most important tasks when your energy is at its peak. For me, that’s in the morning, after breakfast and working out. Exercise or meditate to boost your focus.
#2. Protect your sacred hours. When tackling your most important tasks, remove all distractions from your environment. 99% of the time, that means your smartphone. Even if you keep it around, it still distracts you. Yes, that’s backed by science.
#3. Work in cycles of 90 minutes of work followed by 20 minutes of rest. This is a tip I recently learned, and I’ve been trying it since then. The brain needs that rest in between to work at its peak. Tweak those 90/20 to suit your natural rhythm.
#4. Follow the 5 minute rule. When you don’t feel like working, start with a simple task and sustain it for 5 minutes. Or start with a task you can do the fastest. You need a small push to finish your more demanding work.
#5. Use a parking lot. During your sacred hours, if you come up with new tasks, write them down (paper, app, whatever works) and do it later. You should still protect your deep work time.
15 Jul 2025 #writing
Headlines and opening lines get you 80% of the results.
Because, based on Small Brevity, readers spend 17ms deciding if they keep reading or move on. So no matter how helpful your content is, nobody will click it if you write a poor headline.
Want to gain readers? Master your headlines with these ideas:
- Study your favorite YouTuber’s titles.
- Follow this 3-step formula.
- Use one of these emotions: fear, curiosity, desire.
- Follow title-driven creation: Headline first, content comes second.
- Rewrite the headlines of posts you read.
When you write online, you’re really in the business of writing headlines. Online writing is headline writing. No headline = no readers.
14 Jul 2025 #misc
Did you join Software Engineering because you liked coding and time alone? Think again.
You’ll spend more time in meetings than coding:
- Daily stand-ups
- 1-on-1s
- Team retros
- Five minutes (that become hours) with another dev revisiting code you wrote a year ago, and you barely remember it
With all these interactions, technical skills alone aren’t enough. You need strong communication skills.
The best resource for that? How to Win Friends and Influence People. Newer books exist, but this one is a true classic.
Here are two ideas from that book that changed how I approach conversations at work:
Never, ever, ever tell anyone they’re wrong.
That’s the worst way to start or end a conversation. And you won’t change the other person’s mind.
At a previous job, I had the chance to apply that principle.
We were working to connect our hotel solution to a third-party API using the PKCE flow. One developers read an outdated tutorial and wanted to implement it incorrectly.
If I hadn’t read the book, I would have said, “You’re wrong. Here’s how to do it… You, moron!” OK, I would have only thought the last part.
But instead I said something like, “Hey, maybe I read an outdated tutorial or something. Here’s what I found…“ A few moments later, I got a “You’re right!” with a facepalm emoji.
Avoid blaming. Instead, pretend you’re the one who might be wrong.
Be careful with your “but.”
Often what comes after a “but” is something negative.
And people remember more the last words they hear. So if your “but” comes last, that’s all what they will remember.
“That’s a good idea, but we will go over budget” is different from “That’s a good idea, and if we stay within budget, it’ll be perfect.”
Find ways to replace your “no, but…” with a “yes, and…”
Ten years ago, I thought coding was just cracking symbols. It took me years to learn coding is also about being in countless calls and sync-ups: negotiating deadlines and sharing expectations with non-tech people.
That’s why working on our communication skills is one of the 30 proven strategies in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the roadmap I wish I had when I was starting out.
Grab your copy of Street-Smart Coding here
13 Jul 2025 #coding
There’s good laziness and bad laziness.
One day, the VP of a company I was contracting with called me “lazy.” That was a compliment. You know the lazy that finds an easy way to solve a problem. The good lazy way.
But AI is turning us into bad lazy. The “I don’t want to think” kind of lazy. And I don’t want that type.
I’ve been experimenting with AI for my coding. When I sit down to code, I open Copilot on a browser to see what I can offload.
Recently, I’ve been migrating a legacy Visual Basic app and I’ve used Copilot to code faster by helping me with boring tasks.
The problem? Last week, I was stuck on a stupid problem: finding a value in a dictionary from a list of possible keys. Maybe I needed some rest, but I couldn’t think of a LINQ query for that. I was so tempted to wake up the genie in the bottle for that. It felt like the easy way out.
It’s so tempting to go directly to the AI and outsource our thinking.
Just the other day, I found a coder desperate because he couldn’t code without AI anymore. If we’re not careful enough, any one of us could become that coder.
AI is faster at generating code than we are. No doubt!
But being a good coder isn’t about typing fast. It’s about teamwork, clear communication, and other skills that don’t show up in autocomplete.
I’ve packed those lessons into my book: Street-Smart Coding: 30 Ways to Get Better at Coding. It’s the roadmap I wish I had when I was starting out.
Get your copy of Street-Smart Coding here
12 Jul 2025 #coding
Flying is safe but… accidents happen.
When they happen, it’s all over the news. But the thousands upon thousands of safe flights don’t make it to the headlines.
The magic of the Internet took me to Admiral Cloudberg on Medium. Each post breaks down a rare accident, tracing the failed part or procedure that triggered the disaster.
After every accident, there’s an investigation
After binge-reading some of Admiral Cloudberg’s deconstructions, what struck me was the meticulous investigation after every accident.
A committee finds out exactly what happened and why. Their task is to find the root cause and the subsequent chain of events.
After finding the root cause, they:
- release bulletins to manufacturers
- update procedures and checklists
- add the accident scenario to simulators to train pilots
Their goal isn’t to blame the captain or anyone else, but to prevent the same mistakes in future flights.
Coding isn’t flying
As software engineers, often we hear or say,
- “Something went wrong. We don’t know why. It hasn’t happened since then.”
- “OK, let’s move on. If that happens again, we’ll take a deeper look.”
Imagine if we treated coding the same way:
Coding would be as safe and reliable as flying.
We must adopt the same commitment to safety protocols and procedures to never let the same mistake happen twice.