Forem: Cesar Aguirre

The other day, in another adventure with AI, I asked Copilot to turn a couple of SQL table definitions into mapping classes for Entity Framework Core. It was the classical 1-to-many relationship.

The problem came when I asked it to generate an API endpoint to store a parent record with a bunch of child records. Something like: create a parent record from this request, then read a table to create its children.

Its first solution was to persist the parent record. Then inside a loop, persist every child record. The classical N+1 problem. Well, the inverse one. Arrggg!

When I prompted it to change it, saying there was no need for the loop, it replied with a "Yes, you can simplify it that way." Caught you Copilot!

Why coding skills still matter

The N+1 problem was something I could find on the spot.

Now imagine how many AI answers we blindly accept without question. When coding, documenting, researching, testing...

Coding skills still matter. Without them, we wouldn't even notice the problem.

Blindly trusting AI is what makes us say AI kills CS degrees, what gets us into trouble, what makes us dangerously lazy.

Reviewing the code AI spits out puts in the top 50% of coders. The other 50% don't always review. You still need your coding muscles for that.

AI is like a semi-autonomous car. It always needs hands on the wheel. Build skills. Then leverage AI—Keep your hand on the wheel.

To help you build hype-proof skills, I wrote Street-Smart Coding. Because syntax alone won't make you stand out.

Si aun no has leido Street-Smart Coding, te dejo uno de los reviews: "Está escrito desde la experiencia. Es decir, no te dice cómo hay que hacer las cosas, sino cómo aprendió personalmente cómo hay que hacer las cosas."

Cesar Aguirre — Wed, 01 Apr 2026 16:11:59 +0000

Baltasar García Perez-Schofield

Apr 1

Street Smart Coding

#book #spanish #review #development

Comments 1

3 min read

A career "plan" sounds like a blueprint with every career scenario figured out in advance. Instead, think of a career intention.

Cesar Aguirre — Tue, 31 Mar 2026 13:35:07 +0000

Cesar Aguirre

Mar 30

Why You Need An Intention For Your Coding Career

#coding #beginners #career #careerdevelopment

Comments 1

2 min read

Why You Need An Intention For Your Coding Career

Cesar Aguirre — Mon, 30 Mar 2026 05:00:00 +0000

Last week, I wrote about the most painful lesson my best job taught me. The concept of a "plan" generated some discussion. Here I'm expanding on that.

It took me over 10 years to connect the dots.

For years, I didn't have a career plan. I jumped from job to job feeling something was missing. OK, when I say "jump," I mean fired, bored, and laid off. That was my most painful lesson. It cost me my health at the lowest point.

A "plan" sounds like a blueprint with every career scenario figured out in advance.

Nobody starts with a perfect plan. The early stages of our careers are about discovery, experimentation, and building our coding skills while learning to navigate the corporate world.

Plans are hard to follow when layoffs are always around the corner and AI is changing job descriptions.

An intention helps you decide when to move

Instead of "plan," think of an intention:

A guiding principle that helps you decide whether to stay or move on.

There's always luck, setbacks, and resets. It's impossible to account for all of them in a "plan." But an intention pushes you to act instead of waiting.

Here's how an intention helps you in practice.

If your intention is money, a couple of years without raises or bonuses should push you to move. That's not the job that will fill your pockets. Maybe a better choice would be joining a startup in early stages.

If your intention is growing a network, sitting in a cubicle isn't the best idea. A better role might be DevRel, evangelist, or consultant, positions that takes you out of your cubicle.

Money was just an example. It could be gaining leadership experience, climbing the ladder, or learning opportunities.

Use your career intention as your flashlight. Otherwise, wait to leave only when bored, fired, or burned out. I wish someone had told me that when I started my coding career. It would have saved lots of headaches. Set your intention today.

If you liked this lesson, you're going to like, Career Lessons From the Trenches, my free 7-day email course where I distill 10+ years of career lessons into 7 short emails–to help you navigate your coding career.

When the pain is real. So is the urge to leave.

Cesar Aguirre — Thu, 26 Mar 2026 14:23:01 +0000

WeCoded 2026: Echoes of Experience 💜

Cesar Aguirre

Mar 23

The Most Painful Career Lesson My Best Job Taught Me

#devchallenge #wecoded #dei #career

Comments 38

2 min read

If it makes you sick, you don't need more signs to leave.

Cesar Aguirre — Tue, 24 Mar 2026 14:07:10 +0000

WeCoded 2026: Echoes of Experience 💜

Cesar Aguirre

Mar 23

The Most Painful Career Lesson My Best Job Taught Me

#devchallenge #wecoded #dei #career

Comments 38

2 min read

The Most Painful Career Lesson My Best Job Taught Me

Cesar Aguirre — Mon, 23 Mar 2026 05:00:00 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

The most toxic job I ever had didn't break me.

I've had only one job that fit all the definitions of a toxic place. Inexperienced management, competing deadlines, scope creep... To cope with the 9-5, I hung out with coworkers, worked out, and engaged in hobbies. That kept me sane. But it wasn't the job that burned me out. It taught me enough lessons for a book.

The way to the exit door was clear.

Lesson: When the pain is real. So is the urge to leave.

The job that burned me out

A few years later, I landed my best job.

I was working from home, learning new subjects, and making a good salary. It wasn't Silicon Valley, but it was where most coders wanted to be. It turned out more painful than my "worst" job.

Everything was good until the honeymoon ended. Another project doing the same tasks. No new roles for me. All seats were already taken. Same grind, same story.

This time, the way out wasn't that clear. Updating a CV to play the hiring game made staying seem tolerable. "The pay is good." "I don't work overtime." "I'll wait until I finish this project." Meanwhile, hiring trends were tougher and tougher each year.

The next thing I knew, I was rushing to the bathroom. It wasn't to throw up, but I'll spare the details.

My job became a burden. I rushed to finish my daily tasks and skipped my meals. Painful mistake! That brought stomach issues. (Eating when stressed out isn't a good idea) When I least expected it, I was sick and burned out. The way down was slow. But the way up was more painful and slower.

Lesson: If it makes you sick, you don't need more signs to leave.

My most painful and expensive career mistake

Not having a career plan was my biggest, most painful, and expensive mistake.

I didn't stop to think what I wanted out of my career. Money, title, connections, challenges? Maybe my only plan was to gain experience and make some money. Whatever that meant for my past self.

Lesson: Choose wisely. Or wait to leave when sick, bored, fired, or burned out.

A plan or intention would have made me move out and saved me a lot of pain. But like a frog in a pot, the water wasn't boiling, it was slowly heating up. By the time I noticed the exit sign, the damage was already done.

Update (Mar 30th, 2026): Here, briefly I touched the idea of an intention. After some comments, I expanded on the need for a career intention in a separate post.

Tip #1: Always ask why. Especially relevant these days of vibecoding, AI-assisted coding, or whatever it's called now.

Cesar Aguirre — Fri, 20 Mar 2026 15:49:54 +0000

Cesar Aguirre

Mar 16

4 Tips to Avoid Rushing to Code (and Building the Wrong Thing)

#coding #programming #beginners #softwaredevelopment

Comments 16

2 min read

You spent days on your JIRA ticket or GitHub issue... only to be told to redo it after your team lead reviewed your code?

Cesar Aguirre — Tue, 17 Mar 2026 14:10:17 +0000

Cesar Aguirre

Mar 16

4 Tips to Avoid Rushing to Code (and Building the Wrong Thing)

#coding #programming #beginners #softwaredevelopment

Comments 16

2 min read

4 Tips to Avoid Rushing to Code (and Building the Wrong Thing)

Cesar Aguirre — Mon, 16 Mar 2026 05:00:00 +0000

You spent days on your JIRA ticket... only to be told to redo it after your team lead reviewed your code?

A few years ago, I was working on a hotel management tool. My team lead asked me to redo an apparently trivial task. I had to store emails before sending them. It wasn't a full rework, but I had to change my approach. We had completely different expectations from the same task. Two days of work almost wasted.

If I had only asked one single question before starting... "Hey, I'm doing it like this, are we on the same page?"

If you're like me, eager to jump into the code, confident in your solution, hold your horses and follow these four tips:

#1. Always ask why.

Don't start coding if you don't understand what needs to be done—Especially relevant these days of AI-assisted coding.

Before coding, ask:

Why this task?
What's the real problem?
Why solve it now?

#2. Read the existing code before starting.

Your changes might be simple, unless you have to refactor some legacy code first.

If you rush to code without knowing that, you'll give the wrong impression you're taking too long on a simple task. Yes, estimates are hard.

#3. Outline your solution with comments.

Start by sketching your "coding" plan in comments. That's your blueprint.

Of course, once you're done, don't forget to delete the noisy comments. Remember: names over comments and types over names.

#4. Write a one-page spec.

Draft a summary of the changes you need to implement, just for yourself. It's for you to think clearly before writing a single line of code.

A simple question would have saved me from wasting two days of work. Make sure everyone agrees on your solution before you start. It could save you from building the wrong thing.

It's better to annoy people by asking too many questions than by making mistakes for not asking any questions at all.

Strive for context before coding. Always! Because typing isn't the hardest part of coding, but knowing what to type.

I cover 30 lessons like the one in this post in my book, Street-Smart Coding here. That's the roadmap I wish I had on my journey from junior to senior.