mbastos

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.

Automatically merge Dependabot pull requests after your CI workflow succeeds.

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.

These were all valuable marketing approaches to take a decade or more ago so the reason why people are still doing it isn’t ignorance because they did once work very well once. The real reason is complacency and or an inability to change tactics and acknowledge that strategies have and must change.

Is the office really the problem? Think again. It's the commute that's the true culprit. As companies consider bringing employees back to the workplace, let's not forget the hidden costs and frustrations of commuting. Long hours spent in traffic is an unnecessary strain for some, the commute can take a toll. Instead of focusing solely on fancy office spaces, let's address the real challenge – improving productivity. #CommuteWoes #RemoteWork

I wrote up a blog post for the dependabot automation stuff I worked on last month. Figured this could help

At the start of October we sent some of our code generation folks to Apollo’s GraphQL Summit in San Diego, California to talk to industry folks and better understand the trends the industry is headed, below are some of our findings and how they apply to what LibLab is going to be doing when generating GraphQL SDK’s as we near our production rollout.

As someone in Tech who has worked both in Sorrento Valley and Downtown as well as places like LaJolla, Point Loma and now remotely from home in Lakeside I can only say that as a developer I preferred my experience working downtown vs anywhere else. Keep in mind this wasn't me the Entrepreneur, this was merely me the software engineer working for someone else, I was living in Fashion Valley at the time and could take the trolley right up to the office across the street from the main train station and it was a great commute. My wife would bring the kids down for lunch and we'd meet up at the water fountain park at City Hall or at the Children's museum. If I had to work late it didn't matter because the trolley ran late into the night and would drop me off right at home. The dev team could walk outside of the office and go to pretty much any restaurant in little Italy or within a short walking distance so we were never limited to mall or fast food and team lunches were the highlight of the week. If you didn't want to go to a restaurant there were always food trucks on some days of the week and the views from the high rises made you feel like the kind of work you were doing was important. As an entrepreneur now having an office downtown is crazy expensive and an unnecessary commute but if you're trying to understand it from the perspective of the workers and the talent themselves, I would always pick a job downtown vs one in Sorrento Valley or LaJolla any day of the week but that's just me and different people have different desires and perspectives. I'm not a beach guy though but I can also see a beach office being a huge talent draw for you as well, I guess it just depends on the personalities of the folks you're trying to draw that's all.