05 Nov 2025 #coding
Every single job I’ve had has involved migrating a legacy app.
At my last full-time job, it was a WebForms app to manage hotels. First, they tried to modernize it by embedding modules powered by Bootstrap and Knockout.js into the main app. Then, React applications powered by ASP.NET Core API, still hosted within the main WebForms app. Management daydreamed of ditching the old WebForms app. But nah! Mission impossible. It had too much old code entangled with the new code. A zombie that refused to die.
Currently, I’m working on a WebForm app migration from VB.NET to Blazor. We fear Microsoft will deprecate Blazor before we finish the migration. Most likely, WebForms and VB.NET will still be around, seeing dozens of other languages and tools die.
Here I’m talking about WebForms applications. But it’s the same story with jQuery, PHP, and more “dead” languages and tools.
They’re dead depending on who you ask. The StackOverflow developer survey in 2025 registered 23.4% of respondents still using jQuery and ~8% using VBA/VB.NET. That doesn’t seem dead at all.
A business can’t wait for a new application
It’s tempting to rewrite legacy applications. We rebuild all the context, business rules, and constraints, which makes us confident in the code we’re writing.
Often, rewriting isn’t an option. Legacy code runs “successful” businesses. A business can’t stop while the new system is built. And paying off technical debt doesn’t guarantee more money.
Sylwia Laskowska puts it clearly on jQuery Will Outlive Half of Today’s JavaScript Frameworks:
You don’t get paid to build shiny new things. You get paid to keep existing things alive without breaking production.
Legacy code is code that simply works.
New coders don’t dream of working with “dead” languages and tools. I know! I thought I was going to work only with brand-new tools. But legacy code taught me more than any coding course, like navigating large codebases without any documentation or anyone to ask. That’s why it’s in my book, Street-Smart Coding: 30 Ways to Get Better at Coding.
Grab your copy of Street-Smart Coding here. That’s the roadmap I wish I had when I was starting out.
04 Nov 2025 #csharp #coding
I didn’t have writer’s block today. Naaah! I was just scrolling down the /csharp subreddit for inspiration.
Scrolling through, I realized I had answers and reactions. And to follow the popular YouTube format, here I go reacting/roasting/responding to the front page of /csharp:
#1. I wrote a cross-platform TUI podcast player in .NET 9 (mpv / VLC / native engine fallback) Source
Great! Put it on your portfolio.
#2. Best approach for background or async tasks Source
Mmm. Probably that’s Hangfire.
Hi.
In my last project, I had:
1 Api for backoffice
1 Api for app mobile
1 Worker Service for all the background tasks
…
So now I’m in new project, but I’m not sure if is necessary use Masstransit with RabbitMQ? Maybe channels? I mean, I want to keep it simple, but I don’t like put consumers or jobs in the same API, I always prefer to have a worker service dedicated to all asynchronous tasks.
Hangfire?! That’s definitely Hangfire. I don’t need to read more. And you don’t need to look for anything else.
#3. Is conciseness always preferred? (Linq vs Loops) Source
Not that I have a course about it, but LINQ is the best of all C# features. Yes, write a LINQ query first. Then, if you’re working on a high-performance scenario, go with loops.
#4. Can you explain result of this code? Source
Nah! I have a post to write. Ask ChatGPT or Copilot. It’s free.
But seriously, it’s a good exercise. Try debugging it yourself before asking.
#5. Let’s Talk About the Helper Classes: Smell or Solution? Source
Definitely a smell. Helper classes attract plenty of methods. “Where do I put this new method? Oh there’s a Helper class over there! I’m putting it there…”
If you’re tempted to write a Helper class, hold your horses.
#6. In general is it normal to have more than 2k lines in a file? Source
You shouldn’t have one. But yes, it’s normal.
Scroll…scroll…
Nah! Boring! Scroll…scroll…
#7. After seeing that LOC post, can anyone beat this? Source
Really?! Like, c’mon. We’re seeing who has a larger file?!
The other day, I shared that you know you’re in trouble when you try to open a file on GitHub and it says “(Sorry about that, but we can’t show files that are this big right now.)” Spoiler alert: The file has 69,923 and it’s called GlobalFunctions.vb.
You see? Helpers!
#8. Is C# good for beginners? Source
Hell, yes!
#9. Why is this issue only popping up at the 30 line? Source
Dunno! See #4.
#10. Career Guidance: .NET Backend Developer Role and Future Tech Stack Transition Source
“Blah…blah…blah… I’ve accepted the offer, but I sometimes question whether choosing the .NET path was the right decision. I’d like to understand the current job market for .NET developers.”
Hey, buddy! We’re in a bubble that is popping (or about to pop) now. In 2020-2021, “Software Engineer” on LinkedIn meant a line of recruiters with “life-changing opportunities.”
These days? Just look at the headlines. Amazon just “let go” thousands of employees in the past weeks. And that was right after an outage that took down pretty much every client. That’s for every stack, unless you have “AI” anywhere in your title.
OK, let’s call it a day! That’s enough roasting for today. I should be writing a YouTube script, but I don’t have a channel. Just a blog…and a book. Speaking of which…
This post is brought to you by… Check out my latest book, Street-Smart Coding: 30 Ways to Get Better at Coding. It’s not a C# textbook. It’s the roadmap I wish I had on my journey from junior/mid-level to senior. Some lessons are conventional. Others not so much. From Googling to debugging to clear communication.
Get your copy of Street-Smart Coding here
PS: In case you didn’t notice, this was half-joking. And yes, I’m promoting my book.
03 Nov 2025 #coding
AI might promise speed and productivity. But it comes with serious issues.
The other day I found a senior coder quitting AI coding after finding out that:
- AI was like a sloppy coder who bypassed tests and wrote bad code
- AI had stolen all the joy of solving problems from him
After experimenting with AI, I realized I was becoming lazier than usual. Since then, I’ve set simple rules to avoid losing my skills.
But those aren’t the biggest problems.
A failed experiment revealed a more serious problem
Today I found out about the experiment of a team of coders that revealed a deeper problem.
After trying to write a feature at work only by prompting, they realized:
[Even when AI is capable of writing all of our code], a huge issue remains: I lose my mental model of the codebase.
…
Until I can trust the AI completely, I need to keep my own mental model alive. Otherwise, every time I need to do something myself feels like joining a new company.
It takes time to get familiar with a complex codebase. At past jobs, it took me about a year to feel confident. Of course, your mileage may vary.
But when that happens, you feel like driving through familiar streets with only one hand on the wheel:
- You know the architecture, the folder structure, and even a rough sketch of code blocks.
- You know how modules connect and what to touch or avoid.
- You can even remember file and function names.
You’ve built the mental models and gained all the context. Without them, you feel like walking into a dark room.
When AI writes our code, it’s stealing the context and the feeling of knowing a codebase like the palm of your hand.
Use AI if you want, but be the one dictating what to do. Draw the boundaries of the solution, then let AI fill in the details. Be the pilot and let AI be your copilot.
When AI can handle syntax, it’s time to work on skills it can’t, like collaboration, clear communication, and problem-solving. 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.
Get your copy of Street-Smart Coding here
02 Nov 2025 #misc
Future me:
Yesterday I woke up to a comment on a coding post we reposted on Medium. It said, “you are just marketing your book.” It included some profanity, but I’m not adding it here.
I just launched Street-Smart Coding last week. And yes, I’ve been promoting it by turning every post into a sales rep. Hey, singers promote their concerts and writers go on podcast tours, right?
Here are three reminders for you, future me:
#1. Remember the 30/30/30 rule
Keep in mind that no matter what you do:
- 30% will love it
- 30% will hate it
- 30% won’t even care
Well, technically it’s 33.333333%, but you get the point. That commenter was just part of the second 30%.
And good or bad publicity is still publicity. That hateful comment was signaling Mr. Algorithm to promote your post even more.
#2. Remember why you started
There’s a hill to die on:
Either you sell something (even a $1 pdf) or sell your time in a 9-5. You’re not going to like one of the two.
And if you choose to stay away from a 9-5, you’ll have to embrace sales and marketing. You have to be your own sales team.
#3. Fight your negativity bias
A single negative comment will make you forget the thousands of positive ones.
Open your victories file and your book sales. That’s your first 30%. Show up for them. Here’s a small victory…and another one here.
You spent years building somebody else’s dream and business. Now build yours. Don’t be ashamed of promoting your own work. Influencers and millionaire writers do it. You can do it too.
Let them talk. You keep doing your work.
Read this as many times as you need.
01 Nov 2025 #coding
We’re searching for the best way to get working code from LLMs.
To avoid falling into the vibecoding trap, some developers are turning into structured approaches.
The other day, while catching up with some friends, one of them preached Spec Kit and its Specify/Plan/Tasks/Implement process like the holy Gospel. That’s GitHub’s approach to coding with AI.
More recently, I found The AI development trap that wastes your time on dev.to. It includes these four questions to regain control after drifting from too much prompting:
Do I understand exactly the specifications I’m trying to implement, or the bug I’m trying to solve?
Do I have an exact plan for implementing my changes?
What is the current abstraction level to which I should be prompting now?
Which other information am I lacking?
Spec Kit and those four questions capture the essence of coding.
So to better code with AI, we have to do what we’re supposed to do as coders in the first place:
- Understand the problem to solve
- Decompose that problem into smaller ones
- Think at the right level of abstraction
- Ask enough clarifying questions
Ironically, AI is making us go back to the mindset we should have never left behind.
Context comes before coding, with or without AI.
That’s why one of the principles I included in my book, Street-Smart Coding: 30 Ways to Get Better at Coding is “Don’t rush to code.” (That’s on Chapter #3.) That’s even more helpful with AI as your coding assistant.
Coding isn’t just about syntax. It’s about clear communication, thoughtful problem-solving, and knowing what questions to ask.
Grab your copy of Street-Smart Coding here