Friday Links: Tricky bugs, Google Translate, and AI

Hey,

Here are 4 links I thought were worth sharing this week:

#1. I don’t know how many times I’ve had to flip the conditions inside an if. Maybe not my trickiest bugs, but still… Anyway, here are 9 lessons from a coder’s trickiest bugs (8min).

#2. This coder doesn’t use AI and explains why (8min). One of his main concerns? Speed.

#3. Google Translate hasn’t killed translators and interpreters (6min). Maybe AI won’t kill coding either. At the end of the day, we as coders are translators too.

#4. It feels like coders will be AI’s first victims. But this might be the best time to learn software development (8min). Well, some time ago it was with textbooks, StackOverflow, forums, and instruction manuals.


I’ve been playing with Copilot recently. It’s already saved me hours of repetitive work. And in case you missed it, I’ve written about the tasks Copilot has helped me with here (3min) and here (2min).


(Bzzz…Radio voice) This email was brought to you by… Check my Gumroad store to access free and premium books and courses to level up your coding skills and grow your software engineering career.

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.

How Copilot Has Helped Me Code Faster—With These 4 Boring Tasks

This week, I’ve been running a coding experiment.

Every time I sit to code, I open Copilot (on a browser, not inside my IDE) and look for tasks to delegate.

Yesterday, while migrating a legacy Visual Basic application, I found myself doing some mundane and repetitive work. So I hired Copilot as my junior coder. And here are the tasks it helped me with:

#1. Populate an enum.

I had a large While loop full of If statements on the VB side.

It used magic strings for the comparisons. I gave the original VB code and asked Copilot to populate an existing C# enum with the missing magic strings.

#2. Use comments to emulate named parameters.

A method with dozens of parameters isn’t that weird in a legacy app.

To make it easier to port, I gave Copilot the signature of a method and a code block that invoked it, and asked it to use comments to document each parameter name.

Later, I found out VB has named parameters. Arrggg! Anyway, that wasn’t code I was planning to commit. It was just to make it easier to read and port to C#.

#3. Avoid jumping between files.

Why create constants when we could use magic strings, right? Another common mistake on legacy apps.

In a unit test, in the Arrange part, I needed to generate identical objects, except for the values for a pair of properties.

The problem? I needed to look at three VB files to come up with the right combination of values for each object. So I gave Copilot the three code blocks and asked it to generate a 3-column table with the values I needed. No more jumping between files.

#4. Convert stored procedures into Entity Framework Core queries.

I’m not going to discuss which one is better. Stored procedures or ORMs.

But I found myself migrating stored procedures with fairly simple queries to LINQ-like queries with Entity Framework. So I gave Copilot my entity classes and asked to generate the equivalent queries.

This might not work for large and complex queries inside stored procedures.

#5. Review a patch looking for typos.

Before opening PRs, I asked Copilot to look for typos and suggest more descriptive class, method, and variable names.

Naming is hard and it always generates a lot of back and forth in code reviews. To avoid long discussions, I gave Copilot a git diff of my changes and asked it to be my code reviewer.

I’ve found Copilot shines at text-heavy processing tasks and filling the blanks of well-defined tasks. I’ve already tried these five tasks. But it’s not great at vague instructions like “migrate this to C#” or “refactor this code block.” With clear instructions, it’s the best intern for tedious tasks.

5 Lessons I Learned from a World-Class Peak Performance Expert

What’s the first thing that comes to mind when you hear “productivity?”

Eisenhower matrix? Eat that frog? Pomodoro technique? Listing daily and weekly priorities?

We often mistake productivity for choosing the right tools and techniques. And we procrastinate by tweaking tools instead of doing actual work.

I was one of those people. Multiple to-do lists, constantly syncing them between devices. But since last year, I’ve ditched my to-do and goal lists. Instead I’ve been focusing on my energy levels and working on my mind, body, and spirit every day.

Yesterday, I stumbled upon a webinar by Leon Castillo, “an entrepreneur, investor, and university professor obsessed with peak performance & entrepreneurship.” He helped me confirm some of my ideas and made me realize what I was doing wrong.

Here are 5 lessons I learned from him:

#1. We aren’t wired for focus. I guess our primitive brain developed to look for small clues in our environment. A slight movement behind a bush could mean we were a fierce predator’s dinner. So we need to create the right conditions for focus.

#2. Reduce the amount of information you consume. Everything and anything around you competes for the same reserves of attention and energy. Use them wisely. For example, don’t use your cellphone first thing in the morning. Instead use it at lunch or at night if you’re a morning person. Take the Morningness-Eveningness Questionnaire (MEQ) to find out if you’re a morning person or a night owl. “Moderate morning” person around here.

#3. Have a clean and organized environment for work.

#4. Batch focused work on 90-minute sessions, followed by 20-minute rest sessions. Our brain works best in periods of high intensity, followed by periods of low intensity. And the best type of rest activities? Meditation or napping.

#5. Meditation doesn’t have to be complicated. Sit in silence for 15 minutes, with as little sensory input as possible, and notice your breathing.

After watching that recording, I felt the urge to audit my daily routines. I need to protect my mornings. No more social media until afternoon.

And if I could summarize his talk in one single line, it would be: It’s not how hard you push, it’s how well you rest.

10 Reasons Why I Write 10 Bad Ideas Every Day

Since October 2024, I’ve been writing 10 bad ideas every day.

OK, maybe I’ve missed a day or two. But when that happens I write another 10-idea list to keep up.

I found this habit by pure accident. I was looking for ways to improve my writing skills. And I found “write 10 headlines a day.” That was inspired by James Altucher’s concept of becoming an idea machine.

Since then, I’ve written 10 bad ideas for books I could write, courses I could create, and writing experiments to run. The point isn’t to come up with good ideas and execute each one, but to think freely and expand our horizons.

That’s one of the habits I’m sticking to, here are 10 reasons why:

#1. It helps me calm myself down when stressed. Writing 10 ideas redirects my brain from a stressful situation to a higher-priority task.

#2. It helps me generate content ideas for blog posts and LinkedIn posts. Often I turn my 10-idea lists into multiple pieces of content I post online. This post started as a 10 idea list.

#3. It helps me decompose a big project into smaller tasks. Before starting a big project, list 10 initial ideas. Then pick one of those first 10 ideas and write another 10 to execute on it.

#4. It helps me keep my brain sharp. It’s exercise for my brain. Alzheimer’s, stay away from me.

#5. It helps me do something creative every day. Writing 10 bad ideas a day keeps my possibility and creativity muscles strong.

#6. It helps me avoid ruminating thoughts. Again, it shifts my focus from reliving the past to a more productive task.

#7. It helps me train my focus. I try not to think about anything else until I write 10 ideas. But there are thousands of thoughts coming and going. The goal is to focus on hitting 10 ideas. And that’s hard.

#8. It replaces note taking. After finishing a podcast episode or book, I write a “10 lessons learned” list. It helps me with recalling and retention.

#9. It teaches me to simplify my sentences. I use a notepad that fits into my back pocket, so I don’t have much space to write a paragraph. I need to write a short sentence.

#10. It helps me use my cellphone less. Life happens away from screens. And since I use old pen and paper to write my ideas, that’s time away from my phone. I started with a DIY notepad made from recycled materials. Then I bought a real notepad.

I don’t think I’m exaggerating when I say writing 10 ideas a day has made me more creative. Well, without any drama, it has helped me keep my daily writing streak.

Grab pen and paper and write your first 10 bad ideas. They will push your brain and challenge your creativity.

There's Nothing Wrong With Blogging for Attention

I’m jumping into the online conversation about blogging expectations.

I found out about it on joelchrono’s blog. But somebody else started it. I can’t find those initial posts anymore.

Here’s what I expected from my blog

I started blogging to improve my coding.

That’s what Google recommended and I bought the idea. So in 2018, I started blogging to document my learning as a coder and the problems I was solving at work.

A couple of years after my first post, I added analytics with GoatCounter. And to my surprise, some people read my posts. Thanks, Google!

Then to increase my pageviews, I started to repost on dev.to and to share my posts on LinkedIn. That was the strategy I found to increase my blog traffic.

So I was writing:

  • To document my journey,
  • To please the SEO gods,
  • To rank on Google first page, and
  • To have people reading my posts.

I started with no plans, just to improve my coding skills. But I discovered SEO and a love for writing.

Blogging has given me a few moments of attention

Since then, my blog has done more for my career than a portfolio.

Apart from occasional virality and a bit of lunch money, my blog led to unexpected results:

  • Getting my blog curated on Minifeed
  • People on Reddit roasting one of my posts
  • A reader compiling his favorite posts from my blog
  • One of my blogging heroes reacting to one of my posts
  • An interview going faster after I showed my unit testing posts
  • One veteran coder emailing me after one of my posts going viral
  • Readers emailing me to point typos or issues in my code samples
  • One reader emailing me to share how one of my posts resonated with them
  • Another writing hero tagging me in one of his posts after a discussion in the comments

Those unexpected moments showed me that my writing resonated with people. Sometimes I’m not writing into the void.

Even if I had to start over, I’d still blog. For my mental health and creativity. And yes, for a bit of attention.