The Most Dangerous Problem With Using AI for 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.

What Software Engineering Should Learn from Aviation

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.

Friday Links: Coding, calling, and networking

Hey there.

Do you remember the first time you saw a computer? I do. And I originally wrote that story on my blog (2min). But this week, it went kind of “viral” when I reposted it on dev.to.

Anyway, here are 4 links I thought were worth sharing this week:

#1. AI can make us code faster. But writing code has never been the bottleneck (3min). It’s everything around writing that code in the first place.

#2. Curious about the backstory of some coding jargon? Here’s why we “call” functions (10min). Funny enough, we also say “invoke” a function and in Spanish, everyone associates “invoking” with ghosts.

#3. Instead of forcing devs to use AI, here are some ideas for managers to adopt AI (7min) in their teams.

#4. Also an introvert? Here’s a quick guide to networking (5min) for you. Not the networking type with cables and switches.


And in case you missed it, I wrote on my blog about the “I just went on vacation” effect (2min) and 4 lessons to start your first online business (3min).


(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.

The Branding Exercise That Felt Like Free Therapy

I didn’t know a branding exercise would make me reflect on my life.

I’m taking a branding/writing course online. One of the exercises was to identify our main achievements, mistakes, and lessons to build our online presence around that.

Here are some of my answers for the career-related questions.

What were the most notable things that happened during your young adulthood (20-30 years)?

What were the most notable things that happened in your career?

  • I learned English to land high-paying jobs. But I found out I like learning languages. So I learned another two. French and quite a bit of Brazilian Portuguese.
  • I found out I’m a lifelong learner.
  • By accident, I started writing online and made my first dollars online.
  • I doubled my salary and took one year off.

What have been some of the hardest or painful moments in your life?

  • I hit rock-bottom. Got burned out, depressed, and stomach sick. In that order. All of that because I decided to keep a “good” job with a decent salary.

What have been the most valuable lessons you learned in life and how did you learn them?

  • We’re just a cog in a machine if we keep a “safe” job. I learned this when I got fired and laid off multiple times.
  • If I don’t come up with my own life plan, somebody else will give me one. I had to overcome my burnout to learn this.
  • I’m not my job and my job title. I should diversify my joy. It shouldn’t come from a single place. Thanks, burnout for teaching me this.

What have been your biggest mistakes and how did it change you?

  • I stayed too long at stagnant jobs, expecting things to change without taking any action. It cost me years and thousands of dollars. One of the few things I regret. It made me take control of my career and life.

What transformations have you gone through in life (physical/financial/emotional/spiritual/etc.)?

  • After months of waking stressed and anxious, I recovered from burnout by working on my health and writing again. Finally, after almost a year, I could wake up feeling fulfilled and accomplished.
  • I lost about 5 kg in the last year, thanks to reordering how I eat. It turned out to be the best productivity hack I’ve discovered.

What are your most significant achievements?

  • I paid with my own money for a fancy family dinner.
  • I made my first internet money with coding courses and writing online.
  • After a layoff, I survived one year without a job, living off my savings and investments. It was a tough time, but I remember it as the season where I grew the most.

The "I Just Went on Vacation" Effect in Dev Teams

After years of working in dev teams, I’ve learned one rule the hard way:

Don’t ask someone leaving to finish a critical task, even if they’re the only one who knows how.

Someone going on vacation, or worse, leaving the job already has their mind elsewhere. They’re already thinking about packing, buying tickets, or finishing paperwork.

Even if they finish the task, something will go wrong after they’re gone. Maybe it’s a requirement change, an unexpected bug, or a new scenario nobody saw coming. And they’re the only one who knows how to handle it.

Too late, they’re already gone. People who stayed will have a hard time catching up.

I don’t know if that’s ever happened inside your teams. But I’ve seen it more than once. Let’s call it the “I Just Went on Vacation” effect. And make sure we don’t fall into it, especially if you’re the one leaving.

Starting out or already on the coding journey? Join my free 7-day email course to refactor your software engineering career now–I distill 10+ years of career lessons into 7 short emails.