Honestly, the software job market has always been small. The big lie pushed by tech giants was that everyone should learn to code, not because there were unlimited jobs, but because they wanted a massive talent pool to cherry-pick from.
But the reality? We’ve always been competing. Against overseas devs. Against the founder’s nephew who built a WordPress site once. Against the tides of startup hype and budget freezes.
And the software engineering job? It was never just about writing code. It’s about selling yourself. Convincing PMs not to ship garbage. Debugging messes without crying for help. Surviving org chaos. You need a whole toolkit beyond just syntax.
The current contraction isn’t just about LLMs, it’s about companies pulling back on risk. When the economy picks up, AI won’t be a convenient excuse anymore. The market ebbs and flows, same as it ever was.
Jobs aren’t really about what you know, they’re about the problems you can solve. The knowledge matters, sure, but it’s secondary to: can you fix this, and can you do it efficiently enough that it’s worth paying you for it?
If you’re a solid problem-solver, you can usually convince someone to give you a shot. You keep the job by solving problems well, over and over. And you get the next one by showing that you’ve done it before, faster, better, smarter. That’s the cycle.
Doesn’t matter if you use AI, pen and paper, or carrier pigeons, as long as you solve real problems, consistently then you’ll never have trouble finding work.
As someone who makes a living with programming and has a CS degree and have a 14 year old starting college for CS next semester, I just want to say: your juniors shouldn’t be discouraged in the field of software engineering.
LLM Tools don’t eliminate developer jobs, they shift where the value is. There’s now more opportunity for devs to focus on the things LLMs can’t do well yet: writing good tests, hardening security, building robust systems, and understanding edge cases.
It’s kind of like what happened when cars replaced horses. The transportation industry didn’t vanish, it evolved. The buggy makers and blacksmiths just had to adapt to a new kind of vehicle and maintenance strategies. Same goes here. LLMs won’t replace CS skills, they’ll just nudge us to aim them in a new direction.
Encourage your kids and juniors to learn these tools and figure out how to leverage them. That’s where the next wave of dev work is heading in my humble opinion and that’s okay.
I love that, yep I think not enough is said about encouraging individual creativity in an organization, if you can pull something off you should be allowed to, at least for as long as the company can afford it.
Good point, I think it makes me somewhat more human that I actually care about my people's personal lives, it's more the military guy in me than the technologist per say but you're right if they don't want to say they should have that right.
I had someone tell me the other day that they don’t like it when their employees work on side projects. I actually encourage my team to work on side projects in their free time of course, even if those projects may eventually lead them elsewhere.
That’s why I ask upfront if they’ve got other technical interests during an interview. No one stays at a company forever, and I’m not hiring them because I can’t do the job without them.
What I’ve found is: folks who are building on the side tend to bring fresh ideas to the table. They’re more engaged, more creative, and way more valuable than someone just checking off tasks. Plus, supporting their side projects helps defuse resentment, especially the kind that builds when people feel stuck or held back.
When they try to build something of their own, they get a firsthand look at how hard it is to run a business or ship a product. And weirdly enough, that often makes them more loyal. They see that we’re in the trenches together.
People tend to stay when they feel like they’re still learning from you, and they leave when they’ve outgrown you. I’m okay with that.
Been doing this kind of work since the 90s, and if there’s one thing I’ve learned, it’s that there’s never been a shortage of hot takes on what makes a “real” engineer.
I was self-taught for my first decade, then got my CS degree while working already as a full-time dev. I’ve seen both sides of the “self-taught vs. formal education” debate. I’ve also lived through the IDE vs. non-IDE wars, the Vim vs. Emacs battles, and was a Linux dev for a decade when everyone else was using Macs and switched sides 5 years ago then everyone went Linux.
Here’s the truth as I’ve seen it: opinions in this field come and go. They’re often rooted in personal insecurity or in “this worked for me so it’s the only right way” thinking.
So here’s mine: no one went back to using encyclopedias after Google showed up. I’m not printing MapQuest directions when GPS exists. Very few of us are still writing assembly, those who are usually do it for niche reasons or street cred.
I remember getting pushback in 2014 for building backend systems in node with JavaScript. Now look where we are.
At the end of the day, whether you’re using LLM tools or not, the only thing that matters is this: can you execute? That’s it. That’s the measure. Everything else is just noise.
I’ve shipped plenty of production apps with help from models, long before tools like Cursor or Lovable were even around 2 years ago. I’m excited for what juniors will create using these tools with intent and curiosity. That’s how they will learn. That’s how they will grow.
We all talk about “moving fast” and “shipping features,” but who picks up the tab for those shortcuts? In Part 2 of our series on Technical Debt vs. Technical Assets, we tackle the pushback head-on:
• Why the true “lender” is your future self—and every developer (and stakeholder) who follows
• How calling it “debt” sparks the urgency executives and engineers need to act
• Why every asset carries upkeep costs—and how to keep your investments healthy
If you’ve ever wondered how to make smarter trade-offs between shipping now and scaling later, this one’s for you.
I just published a deep‑dive on how a GitHub Actions workflow can cut, tag, and publish a fresh release every single week, no matter whether you’re running on Python, Go, React, or a poly‑glot monorepo.
Here’s the gist of what the post covers:
Cron‑driven cadence – A simple cron: '0 0 * * 0' keeps your release train on schedule (every Sunday at 00:00 UTC).
Language‑agnostic workflow – Uses actions/github-script to create a tag like 2025‑07‑13 and generate release notes automatically.
Zero manual toil – If there are no new commits since the last cut, the job exits gracefully; otherwise it publishes in seconds.
Easy to extend – Add build matrices, package publishing (PyPI, npm, Docker), or artifacts with one extra step.
Benefits – Faster feedback loops, predictable delivery, smaller diffs, and an always‑up‑to‑date changelog.
Read the article for the step‑by‑step implementation, copy‑paste YAML, and best‑practice tips.
Why does this matter?
Automating release duty eliminates the “Who’s on deck?” scramble and frees engineers to focus on value, not version bumps. Your consumers get predictable updates, and your team gets a healthier shipping rhythm.
Already using something similar? Drop your experience, or questions, in the comments. Let’s compare notes on continuous delivery without the overhead.
Some people see technical debt as a list of missing features, but it should be a list of the problems that you know you have to vs want to solve. The list can vary but should include known bugs and errors in your code. It should also include how readable your code is and any bloat you might carry. Slowness in build and execution time needs consideration as well.