25 Oct 2025 #career #coding
I used to be a problematic team member.
I delivered my tasks late. Sometimes I worked late fixing bugs and finishing my tasks on the sprint’s final day. That was in my second job.
My previous job was in a non-tech company. I wasn’t used to Scrum, deadlines, and working as part of a development team. In this job, I had to work hard just to keep up.
After a year or two, I had the chance of working next to the team’s architect. Maybe that was part of a performance improvement plan and nobody told me. Who knows?
I learned a lot from my team’s architect. He became my mentor, although I never explicitly asked him to. Here are 5 lessons I’ve learned from him:
#1. Read for 1 hour.
My mentor spent ~1 hour after work going through blogs, Reddit, Hacker News, and other news sites. Often, he arrived at work saying, “Hey, check out what I found yesterday.”
Apart from staying up to date, there was a real reason behind that habit.
Sometimes, the CEO, who used to be a coder, arrived at the office asking my mentor, “Hey, did you read about…?”
I remember my mentor telling us, “It can’t be that, being the architect, the CEO asks me about something and I don’t know how to answer.”
You don’t have to know it all, but always find time to learn.
#2. Struggle first.
Apart from being the architect, my mentor was the “team enabler.”
He told us, “If you’re still stuck after one hour, come back and ask for help.” He didn’t answer immediately, he made us struggle first, so the answers would stick.
That’s the same trick I use when I help others.
#3. Read code.
No coding class taught me the value of reading code.
My mentor was the one who taught me. He read the source code of almost all libraries and tools we used. That’s how he knew about their hidden features or undocumented behavior.
Reading code was how my mentor learned from the best.
#4. Simplify problems.
Break down coding problems into one-liners, just like movie plots.
Instead of “a complex async system,” say “a queue and a processor.” It helps you present and explain complex ideas, especially to non-tech people. Helpful to keep the larger picture when coding too.
#5. Don’t be a one-trick pony.
I remember my mentor saying, “Imagine an architect who builds the same house over and over.”
For him, every project was a chance of learning. Don’t build the same thing twice. Of course, there’s nuance here. Don’t suffer from shiny object syndrome either.
After more than 5 years of working with my mentor, I’ve kept the habit of setting aside time to read. I use idle moments to scan headlines and see what’s going on in the tech world.
My mentors taught me lessons that college or bootcamps don’t teach, like how to ask for help, read code, and say no politely. I’ve included some of those lessons in my book, Street-Smart Coding: 30 Ways to Get Better at Coding.
That’s me passing on the lessons my mentors taught me and the ones I’ve learned on my own. That book is my way of mentoring you to help you to grow and code like a pro.
Grab your copy of Street-Smart Coding here
24 Oct 2025 #mondaylinks
Hey there.
Here are 4 links I thought were worth sharing this week:
#1. Junior me wanted to refactor everything around me to follow “conventions.” Mid-level me worked extra hours and on weekends to prove I was “committed.” The thing is as we get more senior, all those implicit expectations change (5min). They often make you lose trust.
#2. Early developers didn’t have StackOverflow or YouTube or ChatGPT. They relied on “skill, curiosity, and persistence.” Wow! I found a post about RFC (13min), (the documents with the building block of the Internet), but I found a manifesto for coding creativity.
#3. As AI-generated content floods social media and the whole internet, we need places where there’s still a human touch. And that might be your own website (4min).
#4. These days, we all agree on one thing: there’s too much hype around AI. It’s the new tool in town promising to kill coders. But that’s not the majority view on AI (5min) and someone dares to say it out loud.
And in case you missed it, I wrote on my blog about AI being a sloppy junior coder (2min) and my 5 writing principles for consistency (2min).
(Bzzz…Radio voice) This email was brought to you by…
Ten years ago, I thought coding was only about syntax and languages. I was wrong! It’s about collaboration, communication, and skills far from the keyboard. That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, the guide I wish I had on my journey from junior to senior.
Grab your copy here
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.
23 Oct 2025 #writing
On August 27th, 1997 the world as we knew it changed: Skynet became self-aware.
That was almost 30 years ago. Maybe Terminator 2 wasn’t just a movie, but a documentary. Who knows? But while we wait for nuclear destruction, humanity’s extinction, or simply UBI, here’s my statement on how I use AI:
I use AI for coding (but with some rules)
After a few days with AI, I was becoming dependent, even for simple tasks.
That’s why I don’t recommend new coders rely on AI to generate code, but use it as a learning aid. And that’s also why I’ve put some rules: AI stays outside my editor.
I don’t swear by AI. It’s far away from replacing coders. But coding will look different in 10 years.
That’s for coding. But for writing, my approach is different.
Zero AI for writing
I write every word here and elsewhere. All of them. By a human. Me.
I use AI to proofread and edit my words. I’ve replaced Grammarly (at least the basic, free version) with a simple prompt.
I used to make posts eye-catching with AI-generated images of humanized cats doing everyday tasks. Who doesn’t like cats? But after changing my approach to blogging, I stopped using images and covers on my posts. So no more AI cat images.
When social media and the whole Internet get flooded with soulless, dull AI-generated content, I’m also in the small crowd standing up with stories, an authentic voice, and a message worth reading.
I’m in the “if you don’t care to write them, why should I care to read them?” team. We don’t need another AI-generated post starting with “In today’s world…”
22 Oct 2025 #coding
I just wanted to reply with a link to letmegooglethat.com. But that felt rude.
I had received a WhatsApp message late at night. It was a friend’s sister, a junior backend developer. She asked how to extract an IP address from a request in an old WebForms app.
Instead of the “let me Google that for you” answer, I replied saying it was part of the HttpContext object or something. “You’re better off Googling, I can’t remember,” I said.
As juniors, we think we are expected to memorize every single method, command, and option from the standard library, frameworks, and tools. That’s not true.
Unlike exams and interviews, when coding, you can use Google or ask ChatGPT.
Here are 7 things I always have to Google:
#0. Diffing two Git commits or branches. I Google this every time I want Copilot to review a code block.
#1. Undoing stuff with Git. How to undo a commit or unstage files. Is git undo a valid command?
#2. Formatting numbers. Is it myNumber.ToString("C") or with "F"? I can’t remember.
#3. Formatting dates. Even when I came up with my own mnemonics, I still have to look it up. How many f for milliseconds?
#4. Anything AutoMapper-related. Just this week, I Googled how to ignore properties again. When using AutoMapper, I often end up pulling up my own TIL posts or going down a rabbit hole in StackOverflow.
#5. Parsing numbers. Does a cast work? Is it ToDouble() or double.Parse?
#6. Anything about enums. How to list all enum members. How to parse from an int to an enum. How to print a member name. But since I’ve started using SmartEnum, I haven’t looked back to “normal” enums.
As a coder, Google is your friend. Learn to search, find your own answers, and ask for help when you’re stuck. Even with AI, these three are the most important skills for new coder.
That’s why I made those three the first strategies in my book, Street-Smart Coding: 30 Ways to Get Better at Coding. That’s the practical guide I wish I had on my journey from junior to senior. Because coding isn’t about memorizing syntax. It’s about knowing where to look, and how to learn.
Get your copy of Street-Smart Coding here
21 Oct 2025 #coding
“Focus on one thing,” a coworker used to tell me. But I didn’t listen.
I was in my first job about 10 years ago. I was learning C#, catching up with PHP, and reading about Python. I remember going through Hangfire documentation without knowing how I’d use it.
Like most new coders, I suffered from shiny object syndrome.
I was focused only on mastering syntax
At that time, for me coding was only about syntax, symbols, and languages.
One day, my boss called me to his office and I arrived late because I was “coding.” He lectured me that day. And I deserved it. Looking back, I’m surprised I didn’t get into more trouble.
And to make things worse, I picked Clean Code. By the time I finished it, I had become a Clean Code cop. I started to look for violations around me. Every piece of code had to follow the book.
Wrong! Wrong! Wrong!
The hard lesson: Coding isn’t only about syntax
Yes, coding is about syntax. But it’s more than just typing symbols.
Most coding happens away from a keyboard: in meetings, brainstorming sessions, and on whiteboards. You’ll spend a lot of time talking to non-tech people, negotiating deadlines, and managing change.
Junior me didn’t know that. And by trial and error, I had to learn the lesson. Getting fired was part of it.
Learning more languages will grow your toolbox, but it won’t necessarily make you a well-rounded coder. Work on your collaboration, clear communication, and writing skills too.
I wish someone had told me that when I started out. And that’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding. Because coding is more than typing symbols fast.
Get your copy of Street-Smart Coding here