28 Oct 2025 #coding
I spent five years in college learning to code.
A stupid dissertation delayed my graduation. But that’s another story.
Most of my five-year program didn’t prepare me for real-world coding. My real coding journey began at my first job, with one Google search: “how to get good at coding.”
I found a lot of conflicting advice:
- “Use comments”
- “Don’t use comments”
- “Do this”
- “Don’t do that”
Arrggg!
It took years of trial and error to learn what worked.
I had to survive on-call shifts, talk to stakeholders, and say “no” politely. More importantly, I had to learn that coding takes more than just syntax.
That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding Without Losing Your Mind, so you don’t have to go down the same rabbit hole.
I wrote it for every developer who’s ever typed “how to get better at coding” into Google or ChatGPT, just like me back in my first job.
Inside “Street-Smart Coding”
Some lessons inside Street-Smart Coding are conventional.
Others were learned the hard way.
And a few are weird.
One of the tips will save you from staying at work until 3:00 a.m. That’s on Chapter #21.
Another tip is to watch a TV show. And no, it’s not Mr. Robot or Silicon Valley. That’s on Chapter #29. It will teach you about problem-solving.
But all the tips and lessons are battle-tested.
These are the lessons I wish I had starting out, the lessons I learned over ten years through plenty of mistakes. Now they’re yours.
Get your copy of Street-Smart Coding here
27 Oct 2025 #coding
Yesterday, I shared a surprising way to improve at coding: watching a TV show.
It wasn’t Silicon Valley or Mr. Robot or any other TV show featuring hackers. It was a show about doctors. I never thought hospital drama could teach problem-solving.
Watch House M.D.
Let me introduce you to Gregory House, the protagonist.
He’s not a regular doctor. He doesn’t like patients. He doesn’t wear a white coat or use a stethoscope either. He’s even sick and under constant medication. Weird, right?
But he gets the most complex, rarest cases because he’s a brilliant problem solver. He even runs his own department at the hospital.
Every episode is a masterclass in how to solve complex problems.
The #1 rule of problem-solving
There’s a line Dr. House says almost all the time:
“Everybody lies.”
That’s why Dr. House doesn’t like to see patients. He only trusts brain scans, blood tests, and other exams.
Let me ask you this:
How many times have you received a bug report and Customer Support claimed they had verified logs, reproduced steps, and validated user data… And after hours of debugging, you realize the real problem was something they had claimed to have checked in the first place? Arrggg!
If you ask Dr. House, everybody lies:
- End users lie.
- Documentation lies.
- Customer Support lies.
- Other engineers lie.
- Even you and I lie.
Always trust but verify.
That’s Dr. House’s #1 rule to solve problems.
House M.D has conflict and drama with excellent storytelling. But it also teaches powerful problem-solving lessons. I expand on what Dr. House has to teach us as coders in my book, Street-Smart Coding: 30 Ways to Get Better at Coding.
In my book, I suggest watching a TV show and hanging out in cafes to become a better coder. Yes! Because coding isn’t just syntax and speed. It’s also thinking like a doctor with complex cases.
Grab your copy of Street-Smart Coding here
26 Oct 2025 #coding
Junior-me was obsessed with syntax.
Ten years ago, coding only meant learning languages. I was learning C#, keeping up with PHP, and sneaking into Python. I thought coding was only about symbols and lines of code.
But to grow as coders, you need more than learning syntax and typing symbols. Here are 7 unconventional ways to grow as a coder:
#1. Detach yourself from your code. You’ll write simpler code and become a better teammate. You’ll let others touch, critique, and work on your code.
#2. Reinvent the wheel to learn. It forces you to read, dissect, and really understand code. Try rebuilding one of your favorite libraries and tools. Just to learn, once you’ve understood how they work, stick to the real one.
#3. Do on-call at least once. Being paged after hours isn’t a pleasant experience. But you’ll learn to triage, debug, and stay calm under pressure. And more importantly, to communicate with non-technical people.
#4. Watch House M.D. This isn’t a TV show about coders or hackers, but about doctors. It’s a masterclass in problem-solving. You’ll see how they tackle complex problems until they find a solution. More useful than most coding classes.
#5. Learn to write. Not lines of code, but clear, direct prose. Writing sharpens how you present ideas and solutions. That’s why every coder should write. And it’s no surprise the higher up you climb the ladder, the less it’s about coding and the more about communication.
#6. Start and monetize a side project. A side project will teach you:
#7. Learn polite ways of saying no. You’ll need this a lot. You will have to say no to unneeded complexity, scope creep, and burnout.
If you want to stand out as a coder, you need more than mastering syntax. Nobody ever taught me that starting out.
That’s why I wrote Street-Smart Coding: 30 Ways to Get Better at Coding, the roadmap I wish I had on my journey from junior to senior. Because the best coders don’t just type. They collaborate, build, and solve.
Grab your copy of Street-Smart Coding here
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.