Pinned — 28 Oct 2025 #codingStreet-Smart Coding: 30 Ways to Get Better at Coding Without Losing Your Mind
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— a roadmap of 30 lessons I wish I had when I started. For every dev who’s ever typed “how to get better at coding” into Google or ChatGPT. (Back in my days, I didn’t have ChatGPT… Wait, I sound like a nostalgic grandpa…)
Preview of the first ~12 pages
Inside “Street-Smart Coding”
This isn’t a textbook. It’s a battle-tested guide for your journey from junior/mid-level to senior.
Some lessons are conventional.
Others were learned the hard way.
And a few are weird.
One lesson comes from a TV show. Nope, not Mr. Robot or Silicon Valley. That’s on Chapter #29. It will teach you about problem-solving.
You’ll learn how to:
Google like a pro
Debug without banging your head against a wall
Communicate clearly with non-tech folks
…and 27 more lessons I learned over ten years of mistakes.
After 3 months of work, today was the day to test a brand-new invoicing module for a hardware shop.
We’re building a Blazor app to charge companies based on active users and license fees.
By “we” means a team of contractors I’m part of.
At the beginning of every month, the CEO creates invoices and charges cards manually.
Zero automation.
One by one.
It takes him two or three days of work.
Yes, in the 21st century.
Today, the CEO decided to compare his manual process to the new module.
On the first attempt to charge a card, we got a “Not Found” response code from the payment gateway API.
It turns out, on Octopus Deploy, our CI/CD tool, the API url and credentials were missing.
Someone added it by clicking “Add to the List” under the Project Variables.
But they forgot to hit “Save.”
Adding to the list isn’t the same as saving.
Who would have known it?
Arrgggg!!!
Fifteen minutes later, after a deployment, we got the same “Not Found” on the logs.
This time, we forgot to append a “/” at the end of the API url on Octopus Deploy.
From https://acoolapi/something/rest to https://acoolapi/something/rest/.
Noticed the subtle difference?
Well, it seems .NET built-in HttpClient’s SendAsync() does a simple string manipulation to build urls.
I wanted to find the source code to check my assumption, but it was too late and I’m lazy—And this post is getting long.
I guess today I learned to hit Save and append slashes on urls.
Even with AI, troubleshooting matters more than ever. Street-Smart Coding shows you a roadmap with 30 lessons—troubleshooting is one of them—to help you build future-proof skills.
Is it still worth to code or should I learn to use ai instead?
What do you actually need to be able to do without AI?
Today I went to Reddit for inspiration and found almost the same question all over the place: Should I still learn to code?
Yes! Here’s why:
#1. Coding teaches you transferable skills. Like problem solving and troubleshooting.
#2. Coding teaches you how to learn any skill. You can’t simply learn all “coding” at once. You have to divide a skill into subskills and other learning strategies.
#3. AI needs real skills. When things breaks, you can’t vibe your way by prompting “Fix this” or “Don’t make mistakes.”
#4. AI is only making code generation faster. There’s more to be a coder or software engineer than writing lines of code.
#6. AI can’t be hold accountable. When things break, you can’t simply say, “AI did that.”
#7. Foundational skills won’t change much. There will be something else “replacing” coders. Yesterday, it was no-code, UML. Today is LLMs or agents. Tomorrow, chances are it will be something else. Problem decomposition, encapsulation, abstraction…Those fundamentals will be the same and matter more than ever.
“AI” isn’t the most important skill. It takes 10 years and a weekend to master coding with AI: 10 years to learn coding and a weekend to learn the most popular AI tool these days.
To build skills that last a career, check out Street-Smart Coding. The roadmap I wish I had on my coding journey.
#1. Lack of documentation: We all complained about poor or non-existent documentation, but who wants to write it in the first place?
#2. Unclear requirements:“That’s what the use case/Jira ticket/user story said” or “It wasn’t clear from the use case…“ That excuse never fails.
#3. Unreadable code:“This code is a mess.” Then, why do we write messy code in the first place? Or let it become messy?
#4. Existing code:“That code was already there, I just tweaked it.” Or if you’re working with legacy code, written in an obscure language: “That’s from the original implementation.”
#5. Unfamiliar codebase:“This is the first time I see this code…“ Especially when you’re asked to act as a rubber duck to help a coworker with a tricky bug.
#6. QA team:“QA is reporting a lot of existing issues. I just came here to fix this little corner. Now I have a full page of bug reports.” True story. It happened to a friend of a friend of mine.
#7. A new (or old) language: Probably this was only me when switching from desktop apps with WinForms and C# to SPAs with JavaScript back in the early 2010s. Knockout.js, anyone else?
#8. Someone who already left the company:“I don’t know. That’s something $teammate did. He was the only one who touched that code.” Easy to blame someone who can’t defend themself. Don’t be the only one touching something, by the way.
#9. A tight deadline:“That’s what the best I could think of…I only had 1 day. So…“ Insert shrug emoji.
#10. A more senior coder who was busy enough to help and answer my questions:“Oh, I asked $seniorCoder, but he was busy, and I didn’t know what else to do, so I did what I could.” Insert shrug emoji again.
And as a bonus,
#11. StackOverflow, online tutorials, and these days, AI:“I don’t know… that’s what I found online” or simply “AI did that.”
And please don’t blame Street-Smart Coding or any of my books. Jokes aside, if you want to build skills that last a career, check it out. It’s the roadmap I wish I had on my journey from junior to senior coder.
The other day, I reviewed a PR that solved a bug in a Blazor app.
It had only 1 line of code to change a framework setting.
Nothing from another world.
Until I noticed the commit authors in GitHub: Claude was in there too.
I felt like Really?! and closed the browser tab.
That explained the property formatted comment on top of the 1-line change.
Comment I’d trust even less.
If we’re only redirecting anything to a LLM, agent, chat, or whatever, anyone can do the same—that’s not good laziness.
We’ll be replaced anytime soon.
We have to be better.
I’ve had them once or twice in my career.
The first time, it was with a challenging problem, casual Fridays, and monthly birthday celebrations.
The next time, it was with flexible hours, decent salary, and the promise of building any role I wanted.
Each one had more “freedom” than the previous one.
Just more loosen handcuffs.
Today as always, men fall into two groups: slaves and free men. Whoever does not have two-thirds of his day for himself, is a slave, whatever he may be: a statesman, a businessman, an official, or a scholar.
By Paul’s definition, I’m not a slave anymore.
And an aunt recently taught me a lesson:
Freedom is doing whatever you want, whenever you want.
