Forem: Walter G.

Why developers can't get interviews in 2026

Walter G. — Thu, 12 Mar 2026 18:07:03 +0000

You've applied to 47 jobs. You've tweaked your resume countless times. You've written cover letters that felt genuinely thoughtful. You've hit "Submit" dozens of times and watched the applications disappear into the void. You've refreshed your inbox and still nothing. Not even a rejection letter.

And this is happening everywhere and to everyone these days. At least that's what it would seem like if you read all the headlines. But just how widespread of an issue is it, and is it sign of the software development doomsday we've been facing for 20+ years now?

This isn't an article about a broken job market. It's a story about a market that is drowning in noise. Noise created by large layoffs, vast automation, career pivots, and tools that have made applying for a job as frictionless as ordering takeout. And understanding where the noise comes from is the first step to cutting through it.

The Numbers Are Staggering

Let's start with scale. According to Jobscan's 2025 ATS Usage Report, corporate job postings attract an average of 250 applicants and only 4 to 6 of those will be called for an interview. That's the average.

For well-known companies, it's far worse. Jobscan, a resume optimization company, reported receiving over 1,400 applications for a single visual designer role they posted.

I can attest that this is very much true. On average, during the past several years we've received from 200 to 400 applications for a single job posting. And this was true whether we were looking for an intern or for a full time developer or product manager.

For reference, during my corporate years I would often be tasked with reviewing resumes for potential hires to the team, and back then I was looking at maybe 12-15 resumes max for any given candidate. The number of prospects was so manageable that we could easily schedule an interview with each of them. And this was less than 10 years ago.

And it's getting more challenging. Research shows that many applicants now submit anywhere from 32 to over 200 job applications before receiving an offer, with only 0.1% to 2% of cold applications resulting in a job offer. Read that again: at the low end, cold applications succeed at a rate of one in a thousand.

The average time-to-hire has expanded to around 42 days, meaning even if your application does land somewhere, you're waiting over a month to find out. The process is longer, harder, and less transparent than it's been in years.

The FAANG Fallout

After years of pandemic-fueled hypergrowth, the largest tech companies in the world overcorrected dramatically. The mass layoffs of 2023 saw over 262,000 employees lose their jobs across tech companies, with Google, Meta, Amazon, and other industry giants among the biggest cutters.

It didn't stop there. In 2025, around 127,000 U.S. tech workers were laid off, and cuts have continued into 2026.

These weren't fringe employees or underperformers. These were the core teams that built the products you use every day.

The companies framed these cuts as necessary corrections. Some, especially those in e-commerce, had nearly doubled their headcount to meet pandemic demand, and later found themselves overstaffed as daily life returned to normal.

Others pointed to investor pressure around a metric called revenue per employee: when headcount rises faster than revenue, investors push for cuts and the moment FAANG companies announced layoffs, their stock prices began to rise.

So while layoffs are a part of the corporate game and shouldn't shock anyway, mass corporate layoffs are something else entirely, because these people need to go somewhere.

Where Did All Those Workers Go?

Here's what didn't happen: those hundreds of thousands of laid-off workers did not quietly exit the labor force.

The median time to a first job offer for laid-off tech workers increased 22% to 68.5 days in 2025, meaning they were back in the market, competing directly with everyone else, for months at a time.

But it also means that a massive wave of experienced, credentialed, often overqualified workers re-entered the job market and started competing for roles they might not have previously considered.

The FAANG exodus accelerated a trend that was already underway: workers moving laterally across industries and roles, not just up or down. In 2024, 1 in 3 U.S. workers changed jobs, a clear indication that employees are actively exploring new opportunities rather than staying in roles for the sake of stability.

This created a flood across every category of role. A senior engineer laid off from Meta isn't just applying for senior engineering jobs, they're applying for technical program management, AI product roles, startup positions, and consulting gigs simultaneously.

Entry-level roles are getting applications from people with a decade of experience trying to break into a new vertical. Mid-level roles are overwhelmed from both directions.

The Algorithm That Stands Between You and a Human

Even if your experience and credentials are a strong match for a role, you probably won't be evaluated by a human first.

More than 90% of employers now use automated systems to filter or rank job applications, and 88% of companies employ some form of AI for initial candidate screening.

Nearly 98% of Fortune 500 companies use an Applicant Tracking System (ATS) as of 2025.

These systems scan resumes for keywords, credentials, and formatting compliance before a recruiter ever sees them. The problem is that they're imperfect filters at best. Research suggests that 75% of qualified candidates are rejected by ATS because the system can't read the resume correctly, often for trivial reasons like the wrong file format or missing keywords.

So everyone knows the filter is broken. Employers know it. Candidates know it. And yet the volume problem is so severe that no one can process applications manually at scale, so the broken filter stays in place.

The candidates who do clear the ATS aren't necessarily the most qualified either. They've learned to game the inputs. The process selects for optimization, not talent.

AI Made the Volume Problem Exponentially Worse

If the ATS problem was bad before, AI tools turned it into a crisis. On two different fronts.

On the one side you have AI-powered ATS tools that may or may not know exactly what a company is looking for and may leave many a good candidate out in the rain.

On the other hand, you now have more "perfect" looking resumes and cover letters circulating the web fuzzing up the hiring landscape.

The spray-and-pray approach to job hunting, once limited by the sheer time and effort required to write individualized applications, is now nearly frictionless. Tools exist that can generate customized cover letters and tweak resumes for specific job descriptions in seconds. The result is that application volumes have exploded while the signal quality has collapsed.

The Entry-Level Squeeze

If you're early in your career, the situation is particularly worse.

New graduates in 2025 face the most constrained entry-level labor market in five years, according to Cengage Group's 2025 Graduate Employability Report. 33% of 2025 graduates and 20% of 2024 graduates are unemployed and actively seeking work. Only 30% of 2025 graduates find jobs in their field.

The reasons are structural, not cyclical. Entry-level roles are now competing with a broader applicant pool than ever, experienced workers who are willing to take a step back to break into a new industry, or who simply need a paycheck while they regroup.

The unemployment rate for recent graduates hit a high of 5.3%, the highest it had been in three years.

Meanwhile, the skills gap is real as well. 48% of recent graduates feel unprepared to apply for entry-level positions, and 56% of those who feel unprepared cite job-specific skills as their biggest gap.

That's genuinely good news for career changers though. It's cold comfort for fresh graduates who graduated expecting their degree to open doors and are finding it's no longer enough on its own.

So What Actually Works Now?

The honest answer is that volume-based job searching, the spray-and-pray approach, is close to dead at this point. The math doesn't work in your favor. Thirty focused, customized applications will outperform three hundred generic ones every single time. Here's what the data and practitioners consistently point to:

Get a referral. This has always been the single most effective path to an interview, and the advantage has only grown. An internal referral doesn't just help your odds, it bypasses the algorithmic screening entirely and puts your application in front of a human being before the ATS has a chance to reject you for a formatting quirk.

Lead with evidence, not credentials. A portfolio, a GitHub repo, a case study, a published article, a project with measurable results, anything that lets a recruiter understand in ten seconds what you actually do. In a world where everyone has a degree and a list of job titles, tangible evidence of output is a rare differentiator.

Be visible before you're applying. The best interview conversations start before a role is ever posted. Writing in public, speaking at events, being active in professional communities, building a reputation in your specific niche, these create relationships that turn into referrals, warm introductions, and direct outreach from hiring managers. The goal is to be the person they already want before they post the job.

Target aggressively, apply sparingly. Know the companies you want to work for. Understand their business problems. Customize every application as if it's the only one you're sending. Generic is invisible. Specific is memorable.

Treat the ATS as a first exam, not a bureaucratic obstacle. Mirror language from the job description. Use standard formatting. Make sure your resume can be parsed cleanly. Recognize that the first reader of your application is a machine, and machines need clear inputs.

Looking Forward

None of this is happening in isolation. The Bureau of Labor Statistics projects the U.S. economy will add 5.2 million jobs from 2024 to 2034, with healthcare and social assistance growing fastest, and professional and technical services including AI-related roles close behind. Jobs are being created. The market isn't contracting.

What's contracting is the signal-to-noise ratio. The same technological forces that are displacing jobs are also making it easier than ever to apply for them, flooding the system with volume that no hiring process was designed to handle.

The tools that were supposed to make hiring more efficient (ATS, AI screening, one-click applications) have instead created a new layer of chaos that disadvantages everyone: companies that can't find great candidates, and candidates who can't get in front of the humans making decisions.

The job market in 2026 is noisy. The candidates getting interviews have figured out how to be a clear signal in a sea of static, through relationships, through evidence, through specificity.

The only question now is how long it will take before more people change how they search. And how many opportunities they'll miss in the meantime.

Every Developer Is Essentially Always On-Call

Walter G. — Tue, 07 Oct 2025 20:18:50 +0000

I've recently come across several articles and videos titled "What it's like to be an on-call software developer" or "The harsh truths of being on-call." That framing puzzles me a bit.

Throughout my 20+ year career, being on-call has been an implicit expectation of the role, irrespective of employment contracts, company policies, holidays, or weather conditions.

Because despite what your employment contract says about "standard business hours", as a developer, issues don't wait for you to clock in.

Not officially, not contractually, not morally or ethically, but practically and inevitably, you are always on call.

The Myth of the 9-to-5

Remember when you could clock out at 5 PM and genuinely disconnect from any and all work? Neither do I, because as far back as I can remember, work has never been done.

And this isn't "new" or simply just an artifact of a broken employment system. College and university required all-nighters in the computer labs. High school gave rise to bizarre sleep schedules for most everybody. We've always had a rough relationship with our work and the professional world isn't any different.

Here's what actually happens in the modern dev ecosystem:

A critical bug that surfaces at 10 PM on a Friday, one that's leaking customer data or impacting conversion rates, doesn't wait for Monday morning.

It demands attention regardless of your plans, and often before anyone else has even noticed it.

In my experience, most developers instinctively do the right thing. I've responded to countless off-hours incidents myself, and long before I took on that responsibility, I watched senior developers around me addressing issues around the clock as a matter of course.

The real question is never whether to address it, but when. Does this need to be resolved in the next five minutes, or can it wait a few hours until you're at your desk?

I frequently get pinged on my phone at 3am letting me know that one of the many servers I run is down and can't get up. I think it has something to do with maintenance tasks that run after midnight (of course). And there's only been a handful of times where I've pretended I was dreaming and went back to sleep.

Most of the time, I mechanically reach my hand over to the table next to my bed, and I open up my fast-booting laptop and I reset the server.

The New Social Contract

This article isn't about toxic work culture though. It's about the fundamental nature of software development in 2025. We've built systems so complex and interconnected that the traditional boundaries between "work time" and "personal time" have become artificial constructs.

Consider this: When AWS goes down, do their engineers say "sorry, I'll look at this Monday morning", while the entire north-east quadrant of the country goes down? When your startup's payment processing fails during a product launch, do you tell your CEO it'll have to wait until business hours? Of course not.

We're professionals and that carries a certain responsibility.

The moment you became the person who "knows how the authentication service works" or "understands the deployment pipeline," you became the human single point of failure. Your expertise created an invisible tether to the systems you've built.

And that's not a bad thing. Rising the ranks and climbing the corporate ladder means exactly this. You become the point of contact for a software system and your role is indispensable.

The Uncomfortable Economics

Let's talk money, because that's what makes this really controversial.

Most developers are paid salaries, not hourly wages. Theoretically, this means you're compensated for getting the job done, not for punching a time clock. But here's the kicker: tech salaries are premium precisely because the role includes this implicit around the clock availability.

You're not just paid to write code from 9-5. You're paid to own the problem.

That's why a senior developer makes $150K+ while other professions with similar education requirements top out at $80K. The salary premium isn't just for your technical skills, it's hazard pay for being perpetually on standby.

Companies know this, even if they won't say it explicitly. The unspoken deal is: "We'll pay you well above market rate for other jobs, and in exchange, you'll care about our systems like they're your own."

Again, this isn't something that you're aware of during your first job. But you will pick up on it relatively quickly. Particularly if you are working on a complex system that generates substantial revenue.

Modern Phones Don't Help

Git notifications, Slack alerts, PagerDuty pings, server monitoring dashboards, they're all in your pocket, all the time. You can ignore them for a little while, but you can't forget about them forever. That little red notification badge isn't just an alert, it's a psychological weight.

And the more skilled you become, the deeper you fall into this trap. Junior developers can legitimately say "I don't know how to fix that." and they'll usually be left alone. Senior developers can't. With great power comes great responsibility, and with great responsibility comes great sleep deprivation.

You know that weird bug in the legacy codebase. You understand the quirks of the CI/CD pipeline. You're the one who can diagnose why the cache is behaving strangely. This knowledge makes you valuable, irreplaceable, and perpetually accountable.

When I quit my first programming job, it wasn't long before my old managers rang me up because they couldn't figure out where the morning scheduled tasks were hosted. I was on-call, even when not working there anymore.

But Wait, There's More

Here's where I'll really lose some of you: This isn't a bad thing.

The always-on nature of development has created unprecedented opportunities:

Rapid iteration cycles that let us ship features in days, not months
Global collaboration that accelerates innovation
Remote work flexibility that lets you live anywhere
High compensation that reflects your true value to the organization
Continuous learning that keeps the job intellectually stimulating

The traditional 9-to-5 job offers security and boundaries, but it also offers stagnation and limited upside. The always-on developer lifestyle offers chaos and responsibility, but also growth and outsized rewards.

The world can only enjoy the many innovations that we have today, because engineers worldwide stayed the extra hours, had one more cup of coffee and pushed towards that advancement.

Every developer is essentially always on call because we've built a world that depends on software, and software depends on developers. Fighting this reality is like fighting gravity, you'll tire yourself out and change nothing.

The question isn't whether you're always on call (you are), but whether you're okay with that trade-off. Because it is a trade-off: traditional work-life boundaries in exchange for intellectual stimulation, high compensation, global opportunities, and the chance to build things that matter.

Some of us thrive in this environment. Others burn out. Neither response is wrong, they're just different.

But let's stop pretending that development is a 9-to-5 job. It's not, it never was, and it never will be. Once we accept that reality, we can start having honest conversations about compensation, boundaries, sustainability, and what it really means to be a professional software developer in 2025.

Why "It Works on My Machine" Is The Biggest Lie We Tell Ourselves

Walter G. — Fri, 08 Aug 2025 06:09:00 +0000

After 20+ years as a software developer, I can attest that "it works on my machine" is still one of my most used catchphrases, even when I have a slight hint as to its inaccuracy. It's become a safety blanket in a sea of uncertainty and poorly refactored code.

This five-word phrase has become the ultimate shield in code reviews, bug reports, and failed live demos. And for a good reason. It actually works.

Most non-developers staring at a developers workstation will see a combination of IDE's, console windows, database monitoring tools and hidden YouTube videos slightly off screen. That chaos mixed with "it works on my machine" give off this aura of elevated complexity that most people would rather not be a part of.

So 9 out 10 times, people will believe the excuse and assume that some cryptic ghost in the machine is the main cause of the issue and they'll leave us be. And our reward is that we save face and keep our hard earned credibility. At least until the next error springs up.

However, let's be honest, most of the time, this statement is not actually true. And even when it is technically accurate, it's usually masking a deeper problem that we're too embarrassed or rushed to admit.

We sometimes suck at testing.

Let's start with the obvious. When you say "it works on my machine," what you often mean is "it worked on my machine that one time I tested the happy path with the expected variables." Did you test edge cases? Error conditions? Different input sizes? Network failures?

Probably not...

The truth is that most of us have a very generous definition of "works." We run our code a few times, see it produce the expected output for our carefully crafted test case, and declare victory. Meanwhile, there are seventeen different ways it could fail that we never even considered.

And yes, this is where testing libraries and QA teams are worth their weight in gold. But these things aren't guaranteed at every workplace. I've only worked at 1 company that had a dedicated QA team and most codebases that I've had the pleasure of working on, were void of any test-driven development.

More often than not, you are the sole tester. And that level of pressure is why "it works on my machine" is so popular. Because having to do thorough edge to edge testing takes a considerable amount of time and typically it isn't scheduled in to the weekly task list.

Most developers working on mature codebases have to contend with hundreds of thousands of lines of code, written by 5-10 people throughout the years, poorly written documentation and an agile scrum meeting in the next few hours where they have to showcase yet another new feature that may or may not see the light of day.

We're usually under pressure, juggling multiple tasks, and genuinely believe our changes are safe. At least safe enough for a deployment.

The biggest issue isn't that code sometimes doesn't work. Because that's expected in any development environment. The biggest issue is that "it works on my machine" has become a conversation stopper instead of a conversation starter.

When we say this phrase, we're essentially saying: "The problem is with your setup, not my code." It shifts responsibility away from us and onto the person reporting the issue. It's defensive rather than collaborative.

And truth be told, in a world of Docker containers, CI pipelines, and cloud-based everything, “my machine” doesn't matter all that much anymore. Unless your machine is production, which, if it is, we have bigger problems. Then it’s irrelevant. The real question should always be: Does it work in the environment that actually matters?

At its core, this excuse exposes something deeper about our craft though, and that's how fragile modern software can be. How a slight version mismatch in a dependency or a config file not checked into source control can bring the whole thing down. We're building with Lego bricks on top of Jenga towers, and every deploy is a dice roll.

Still, maybe that’s the opportunity here. Instead of letting “it works on my machine” be the end of the conversation, we can treat it like a starting point. "Okay, it works locally. What’s different about staging? About production? Let’s dig." That turns a dead-end phrase into a debugging mindset.

Because let’s be honest: the more times we say "it works on my machine," the more we train ourselves not to look deeper and to get sloppier with our deployments. And when the stakes are high, production outages, customer impact, reputation hits, that little phrase can go from harmless excuse to costly crutch.

So maybe it's time we retire the phrase, or at least say it with an asterisk. “It works on my machine*, but let me actually help you figure out why it doesn’t on yours.”

You Can Still Succeed Without a FAANG Job

Walter G. — Mon, 23 Jun 2025 19:18:07 +0000

After more than two decades as a professional software developer, I've never set foot inside a FAANG company. When I taught at a coding bootcamp years ago, however, it seemed to be all some of my students could think about, the ultimate destination, the golden ticket that would validate their career pivot.

I've received the recruiter emails, tackled the coding challenges, and even entertained the idea on multiple occasions. Yet each time an opportunity arose, I ultimately chose to walk away. This wasn't some contrarian stance or attempt to be different, I simply took an alternative path organically and decided to stay on it.

And overall, I've found great success in doing so without having to battle it out with tens of thousands of candidates fiending for my position.

Building Experience in the Corporate Trenches

My journey led me through over a decade in traditional corporate environments, working with real teams on real products under real deadlines. I wasn't living the digital nomad lifestyle, building passion projects from exotic locations. I was in the trenches, doing the daily work of software development, just not at one of the Big Five.

The opportunities to make the leap did present themselves. Recruiters reached out regularly, interviews were scheduled, and colleagues would occasionally ask, "Have you ever thought about Google?" But nothing ever compelled me to pull the trigger.

The closest I came was an initial screening with a recruiter who outlined the gauntlet ahead: three months of interviews if I wanted to be considered for the position.

He even sent me a giant list of coding challenges and data structure questions to brush up on. At this point, I was already 6-7 years into the field and had worked on various large scale applications. I was a senior developer for all intents and purposes. And the idea of having to sit through a barrage of linked list questions was not appealing in the least.

Perhaps it was a cultural mismatch, or the prospect of becoming another cog in an enormous, hyper-efficient machine. Maybe I simply didn't want to start over in an environment where the rules were established by people I'd never meet and couldn't influence.

Whatever the underlying reason, I remained where I was and built a career that I'm genuinely proud of.

The Corporate Advantage: What You Gain Outside FAANG

Working in traditional corporate environments offers a different kind of experience. One that even the most prestigious tech companies can't always replicate, at least not easily.

End-to-end project ownership becomes the norm. Rather than building isolated microservices, you're developing complete features and sometimes entire applications.

You see projects through from conception to deployment, gaining a holistic understanding of the development lifecycle.

In most jobs where I was hired as a senior developer, I typically found myself being the only developer on that particular website.

Versatility becomes essential. One sprint you're debugging production issues, the next you're collaborating with the marketing team on feature requirements.

This constant context-switching accelerates learning and builds a broader skill set than hyper-specialization ever could.

Individual impact is amplified. You're not one developer among 200 React specialists, you're often the developer for your domain. This pressure, while sometimes intense, forces rapid professional growth and builds confidence in your abilities.

During one of my software developer jobs, I was the only C# developer in a pool of 200 developers, where most were specialized in PHP. Anytime the company acquired a new web application written in C#, I was brought in to be a part of that team temporarily to make sure that everything was up and running.

Cross-departmental collaboration is standard. Regular interaction with stakeholders outside engineering provides crucial business context.

You understand how your code translates into business value and customer outcomes.

Work-life balance remains intact. Professional growth doesn't require grinding LeetCode problems after hours or sacrificing personal time to stay competitive.

If you're currently the sole engineer on a 20 million dollar application, you're more than likely catching more attention than someone who knows how to balance red black trees.

Truth be told, at most normal software companies where I've worked, I've rarely had to solve any cryptic riddles or niche algorithm challenges that never appear in real life.

At most jobs, my experience was the forefront. What I've built, how I built it and how I manage and maintain those applications.

Rapid iteration and feedback loops characterize the development process. Your work goes live quickly, you see immediate results, and you learn faster through this shortened cycle.

On the negative side though, you also tend to break more things on production, because of the lack of this formal scaffolding that big tech teams spend years optimizing.

While some FAANG teams certainly offer similar experiences, they typically come with significant caveats and constraints.

The Trade-offs of Scale

In organizations with tens of thousands of employees, the fundamental nature of software development shifts. Everything becomes more segmented, more process-heavy, and more diluted.

Scope becomes artificially narrow. You're hired to work on one specific slice of a larger system, and that's precisely where you stay. The breadth of experience that comes from working across multiple domains is sacrificed for deep specialization.

Feedback loops extend dramatically. You implement a bug fix and then... wait. Layers of process, approval workflows, and rollout procedures create distance between your work and its impact.

This extended cycle can be frustrating for developers who thrive on seeing immediate results.

Process often supersedes speed. More systems mean more approvals, which means more meetings. The infrastructure is undeniably robust and the colleagues are brilliant, but autonomy, visibility, and development velocity often become casualties.

The Interview Industrial Complex

Then there's the hiring process itself, a multi-stage marathon that has evolved into its own specialized discipline. Algorithmic whiteboarding sessions, system design panels, behavioral interviews, and culture-fit assessments all stand between candidates and positions that might involve maintaining internal tooling or fixing CSS bugs.

Contrast this with the straightforward hiring processes common in traditional corporate environments. My first development role? A single thirty-minute conversation with the IT director, a handshake, and a start date the following week.

Despite this streamlined entry point, I still became a capable engineer. I shipped products, resolved production outages, architected scalable systems, and mentored junior developers. No binary tree inversions were harmed in the making of this career.

The FAANG interview process optimizes for test-taking ability rather than real-world engineering competence. Personally, I never had the bandwidth, or the inclination, to train for assessments so disconnected from the work I already knew how to do well.

Choosing Your Own Path

FAANG companies aren't inherently problematic. For the right person at the right moment in their career, they can provide extraordinary opportunities for growth, learning, and impact. The compensation is undeniably attractive, the technical challenges can be fascinating, and the networking opportunities are unparalleled.

For me, however, the trade-offs never aligned with my priorities. I wasn't chasing external validation or industry prestige. I was focused on building a sustainable career on my own terms, with autonomy, variety, and direct impact on the products I helped create.

And twenty years later, I remain comfortable with that choice.

Would love to hear your thoughts.

Remote Work Leaves Junior Developers Behind

Walter G. — Mon, 02 Jun 2025 18:31:43 +0000

My very first gig as a professional software developer was around 2008 for a medium sized publishing agency. During the interview process I had to meet with the IT Director as one of the last bosses to land the job and his very last question before he signed off on it (or not) is a question that I still talk about today:

"You know you have to show up everyday, right?"

I thought it was a silly question for the most part. Of course I know that, it's a job. But the reason why he asked was because I had no prior work experience. Zero. This was my very first job of any kind. And the hesitation in his tone was clear. And he explained it as such.

He said committing to showing up on time every single day for years on end isn't something younger employees really understood. And boy was he right.

From day 1, there was so much more to my 'Developer' job than just development. In fact, I didn't really touch any code for weeks in the beginning. First I had to meet the other departments that I would inevitably end up working with. I had to read hundreds of pages of documentation, attend meetings, take notes, become support for non-technical departments, etc.

But eventually I was allowed to start to contribute code and to have my commits accepted. And it made much more sense after having gone through this introductory phase.

What I didn’t realize at the time was how much I was learning just by being there. Not just from the tasks themselves, but from proximity.

I watched how senior developers handled requests under pressure. I overheard how product managers communicated deadlines. I learned how to read between the lines when QA flagged a “maybe-bug.” None of that was part of a formal onboarding doc. It was ambient learning, absorbed just by being in the room.

Now imagine trying to get all of that through Slack and Zoom. It doesn’t happen as easily.

That’s the gap I see growing in the remote era. We gave junior devs the same tools, but not the same access. Not to human behavior, not to decision-making processes, not to context. And without those, you’re not really learning how to be a developer, you’re learning how to be a ticket-closer.

When I got stuck, I didn’t file a ticket or schedule a 30-minute sync. I stood up, walked five feet, and said, “Hey, can I show you something real quick?”

That simple act, turning confusion into collaboration in seconds, is nearly extinct in remote-first environments. Today, junior developers might hesitate to “bother” someone that they can't directly see. They might sit on a bug for hours, second-guessing their approach, or draft a carefully worded Slack message only to get a reply the next morning: “Looks fine to me.”

That delay compounds. Not just in productivity, but in confidence. You second-guess yourself more. You move slower. And worst of all, you stop asking questions.

It’s not that remote work can’t support junior developers, it’s that most teams haven’t done the hard work of redesigning the mentorship layer. We tossed out proximity and didn’t replace it with anything close to being as effective as being in person.

And no, weekly check-ins and Notion onboarding portals don’t cut it. You don’t get better at coding by reading about someone else’s architecture decisions. You get better by being inside the conversation when it’s happening.

Looking back, I realize that what helped me grow the most in those early years wasn’t coding tasks or assigned tickets. It was everything that wasn’t in the job description: shadowing senior developers, picking up on team habits, and learning how a real software team functions day to day.

Remote work has its place, absolutely. For mid-levels and seniors, it’s often more of a blessing than a curse. But for juniors? It can be a maze with no map.

If we want remote work to actually work for them, we can’t just hand them a laptop and a Slack login. We need to rebuild the mentorship scaffolding from scratch. That means intentional pairing, real-time collaboration, visibility into decision-making, and a culture where asking questions is frictionless.

Otherwise, we’re not really training the next generation of great software engineers. We're just waiting for them to slowly burn themselves out and to become disenfranchised with this technical craft.

How Do You Actually Get Promoted to Senior Programmer?

Walter G. — Mon, 12 May 2025 18:25:13 +0000

The typical answer to the question of “How do I become ‘x’?” is more often than not a blank statement that sounds good on paper, but that doesn’t really give you any direct instructions.

For example, you want to become a senior programmer? Well then, buckle down and show up daily and do the hard work and you will get there one day.

None of that is wrong. You should do all of those things and more every single day. But more than likely you were already doing those things to some degree by default. So, while it sounds like useful advice, there is a good chance that it didn’t help you in any real way.

So I won’t be reiterating those concepts here. I want to give real-world steps and processes that any developer can follow and that I myself followed as well in my 20 year career as a software engineer.

I’ve been a junior developer and I’ve been a senior developer and the path from one to the other isn’t exactly clear, but there have been common patterns that I've noticed in climbing my way up.

Stand Out More

To start, if you want to climb that corporate ladder and eventually get that Sr. prefix attached to your title, then you need to stand out in some shape, way or form. People at the top need to know your name, somehow.

When you are first starting out as a programmer, this can be very difficult. For one, you’re new to a company, so odds are you won’t be getting the top-tier high profile projects in your to do list just yet.

I know I didn’t. At my very first programming job right out of college, the projects assigned to me were essentially the tasks that none of the other developers had time to get to.

That involved documentation, preparing reports for meetings, testing and debugging and not much else. I pretty much was under the radar for the first 6 months. And my documenting skills weren’t sharp enough to make up for it.

I needed to stand out. At some point during my stay there, a new project began to make its appearance around the office and since all of the other developers were busy with their own work, I was asked if I wanted to take it on.

I’ll say now, this was a large project with the CEO’s direct involvement and I would be the only person working on it for the course of 1 month. But it felt like if I wanted to break free of the tedious work assigned to me, that I needed to accept this request. And so I did.

You can read about that challenging experience over on my blog here.

This wasn’t without risk of course. If you can finish the work in the allotted time and everything goes as planned, then for sure your name will circulate around the office and you might be able to consider yourself an office hero for some time.

But if you fall short and the project is late for any reason, or even worse, if you fail to complete it, then your name might still circulate around the office, just not for the right reasons.

I personally did manage to finish this project and the company thanked me with extra paid time off and several congratulations from various managers and developers. From that moment on whenever a high profile project appeared on the managers desk, my name was on the list to work on it.

I wasn't quite "senior" yet, but the foundation was being laid.

But if you think that one month of hard work will propel you to the VIP meetings at your company, then you might still be missing the mark. Not every project will go smoothly and get your name placed on the leader board.

At some point, you will miss deadlines or delete a database or bring the company website down. I’ve done all those things, to some extent. So there’s still more work that needs to be done.

Be a Team Player

Besides taking on more and more complex assignments and tasks in the hopes that managers begin to remember your name, you also need to get your team to know that they can rely on you when things get tough. Like with any partnership, that takes time and work.

The best way to show that you are a team player is to actively be a part of your group. That may sound obvious, because it is. But I’ve worked with plenty of developers in my day that would show up at 9am and that would be out the door by 4:59pm without hesitation. They wouldn’t stay to socialize and working any extra time was not in the cards.

There is nothing wrong with that of course. We are all free to do as we wish. But when the servers go down at 4pm on a Friday evening, I can assure you that senior developers and lead developers are probably sitting back down to find the issue without hesitation.

In my career, I’ve found it incredibly fruitful to be one of those that stays behind to help out (even if you can't). Not only because you might be helping the other senior developers in some small way, but because you also get more exposure to parts of an application that you wouldn’t otherwise get.

And it’s that extra supplemental knowledge that really turns someone from a junior into a more experienced senior developer at the end of the day. I still remember the first time that I volunteered to stay late with my team during a late night deployment. I didn’t do much in terms of the actual work, as I was still relatively new. But I helped where I could with testing and debugging and people remembered me more for that reason.

This ties in to what I mentioned earlier as well. The more your name circulates around the office, the more opportunities that you will have when it comes to taking on projects.

Jack of all Trades

And lastly, a senior developer has to have a substantial amount of knowledge in a wide range of areas, not just programming in a specific language. This includes database management, server management, fundamental networking concepts and even project management skills. And that right there, takes time.

I personally did not get any real server management experience until my second job as a web developer. During my first job, a dedicated system admin handled most of those requests and I wasn't allowed near any server.

I did however spend a fair amount of time working with databases during my first job. And because of my experience with database management and reporting, I was frequently brought in to different departments at my second job to help fill in the knowledge gaps where I could.

I was also fairly skilled at ASP.NET Deployments, due to my first job being .NET heavy. And this knowledge made me a fan favorite at my second job, where most developers were working with PHP and Apache.

All to say, that the more experience you have in different facets of software development, the more visibility you will have in a company setting.

I started off this article by stating that buckling down, showing up daily and doing the work is essentially a must for any kind of career growth, but that few people actually explain what those words mean.

I hope that I was able to convey a bit more meaning behind those often spoken phrases that we hear so often.

In this particular case, it means taking on more complex projects whenever possible, risking looking bad if things go south and helping out your team as often as you can in order to help both them and yourself. And more importantly to learn as much as you can during those critical early years.

If you follow those steps, inevitably the senior prefix will get associated with your name and once that happens it’s yours to keep for as long as you work in this field.

How Do You Really Become a Senior Programmer?

Walter G. — Mon, 17 Mar 2025 18:30:22 +0000

Most career advice sounds great on paper but lacks actionable steps.
The typical answer to the question of “How do I become a senior developer?” is more often than not a blank statement that doesn’t really give you any direct instructions.

For example, you want to become a senior programmer? Well then, buckle down and show up daily and do the hard work and you will get there one day.

None of that is wrong. You should do all those things and more. But more than likely you were already doing those things to some degree. So, while it sounds like useful advice, there is a good chance that it didn’t help you in any real way.

I’ve been a junior developer and I’ve been a senior developer and the path from one to the other isn’t exactly clear, but there have been common patterns in how I’ve managed to work my way up.

You need to stand out

Climbing the corporate ladder isn’t just about showing up. It’s about getting noticed. If you want that Sr. prefix next to your name, you need to make an impact.

But here’s the catch, when you're first starting out, you're at the bottom of the totem pole. High-profile projects? Those are usually handed to the senior developers. Instead, you’ll likely get the leftover tasks.

At my very first programming job right out of college, the projects assigned to me were essentially the tasks that none of the other developers had time to get to.

That involved documentation, preparing reports for meetings, testing and debugging and not much else really. I pretty much was under the radar for the first few months. And my documenting skills weren’t sharp enough to make up for it.

I had to stand out.

Then came my chance. A new project surfaced in the office, and every senior developer was already swamped. No one had the bandwidth to take it on. So, I stepped up.

This wasn’t just any project though. It had direct CEO involvement, and I was the only developer assigned to it. One month. No safety net. And to top things off, I had zero experience in the tech stack chosen by my higher ups.

The stakes? High. Nail it, and my name would be all over the office, in a good way. Mess it up? Well, my name would still be all over the office… just for the wrong reasons.

I did manage to finish this project and the company thanked me with extra paid time off and several congratulations from various managers and developers.

From that moment on whenever a high profile project appeared on the managers desk, my name was on the list to work on it.

Being a team player

One big project won’t rocket you into VIP meetings. Success isn’t just about landing high-profile work but more about consistency.

Because here’s the truth. You will mess up. You’ll miss deadlines. You might even delete a database or take down the company website (I've done those things). And when that happens, what really matters isn’t the mistake, it’s how your team sees you afterward.

Becoming a senior developer isn’t just about tackling bigger challenges, it’s about being someone your team can count on. When things go sideways, do they turn to you? Or do they see you as just another dev punching the clock?

Building that trust takes time, effort, and showing up when it counts.

The best way to show that you are a team player is to actively be a part of your team. That may sound obvious, because it is. But I’ve worked with plenty of developers in my day that would show up at 9am and that would be out the door by 4:59pm without hesitation.

They wouldn’t stay to socialize and working any extra time was not in the cards.

There is nothing wrong with that. We are all free to do as we wish. But when the servers go down at 4pm on a Friday evening, I can assure you that senior developers and lead developers are probably sitting back down to find the issue without hesitation.

In my career, I’ve found it incredibly fruitful to be one of those that stays behind to help out. Not only because you might be helping the other senior developers in some small way (maybe), but because you also get more exposure to parts of your company that you wouldn’t otherwise get.

And it’s that extra supplemental knowledge that really turns someone from a junior into a more experienced senior developer at the end of the day.

I still remember the first time that I volunteered to stay late with my team during a late night deployment. I didn’t do much in terms of the actual work, as I was still relatively new. But I helped where I could with testing and debugging and people remembered me more for that reason.

Master of none (but knows a bit of everything)

A senior developer isn’t just a coding machine. To truly level up, you need to understand the bigger picture. That being databases, servers, networking and even project management.

And here’s the kicker. You won’t learn it all at once.

I didn’t touch server management until my second job. My first company had a dedicated sysadmin, so I never had to deal with it. But I did spend a lot of time knee-deep in databases, which ended up being just as valuable.

Often times when a second pair of eyes were needed in another department in order to debug an issue, I would also volunteer myself, just to see if I could either help or if I could learn something new in the process.

Your learning speed isn’t always about how hard you work but is often shaped by your company's structure. Some places throw juniors into the deep end, while others keep them in a bubble. The key? Stay curious.

Volunteer for things outside your comfort zone. The more you branch out, the faster you'll grow.

I started off this article by stating that buckling down, showing up daily and doing the work is a must for any kind of career growth, but that few people actually explain what those words mean. I hope that I was able to convey a bit more meaning behind those often spoken phrases that we hear so often.

And more importantly to learn as much as you can during those critical early years.

If you follow those steps, inevitably the senior prefix will get associated with your name and once that happens it’s yours to keep for as long as you work in this field.

A Beginner's Guide to Prompt Engineering

Walter G. — Mon, 10 Mar 2025 15:59:28 +0000

For the past few years people in the AI community have been promoting that prompt engineering is the future and the only career option you'll soon have. And if you don't learn it now, you're going to be out of luck when finding a job.

As someone who's been spending the past few months working on a new AI startup, I can say that it definitely is a complex skill to acquire and to get good at.

So in this post I'll break down much of what I've learned. The more technical side of prompt engineering that often doesn't get talked about. We're talking structured schemas, tokenization, temperature and parameter configurations. The fun stuff.

What people think it is

Let's start here, because I often talk to many people that proclaim they are prompt engineering, but really, they're just typing prompts into ChatGPT and then storing them in an Excel sheet.

Technically not 'wrong', but I'd consider that maybe a Jr. level prompt engineer. The following is indeed a prompt that I engineered.

Write a JavaScript function that validates an email :)

And on the more complex side, you often times see massive prompts that span thousands of tokens with the hope that the output is somehow 100% perfect.

# Modern Next.js Portfolio Site Template

Please create a modern, responsive portfolio website using Next.js 14
 with the following specifications:

## Project Structure
- Use the Next.js App Router
- Implement TypeScript for type safety
- Structure the project with the following directories:
  - app/ (for routes and layouts)
  - components/ (reusable UI components)
  - lib/ (utility functions and configurations)
  - public/ (static assets)
  - styles/ (global styles and CSS modules)
...hundreds of lines more...

There's a chance that you'll actually end up with a more accurate response in the simple prompt above than the complex one. I've seen plenty of long-form prompts online that claim to do miracles, like build and launch an entire SaaS product in an hour. But when you actually go and paste that prompt into any model, the results are random and chaotic at best.

Now that we've covered the common misconceptions, let's dive into the core technical components that truly define prompt engineering

Understanding the models

Every AI company implements their own models, versions, and modalities. Some offer multimodal capabilities spanning text, speech, and image recognition, while others specialize in text-only processing but may excel in particular domains.

Context window sizes vary dramatically between models—some only accept up to 4,096 tokens, while others handle 100,000 or more. However, a larger context window doesn't automatically guarantee better results. Smaller context models can sometimes deliver more focused responses for specific tasks, while larger models can maintain comparable accuracy while processing much more information.

When comparing model quality, specialization matters. Domain-specific models trained on relevant data often outperform general-purpose models on targeted tasks, even with fewer parameters or smaller context windows.

Pricing structures also differ significantly across providers. More expensive models don't necessarily deliver higher accuracy; sometimes you're paying for faster inference times, higher reliability, specialized knowledge, or enhanced capabilities rather than raw performance.

The optimal choice depends on your specific use case, required response quality, and operational constraints.

Costs

If you're doing all of your prompt engineering on a browser client, like ChatGPT or Claude or Gemini, then your costs are essentially the monthly subscription fee.

If your using any of the API's however, then pricing can get tricky. Most providers offer different tiers of pricing depending on the specific model that you use.

Anthropic API models and pricing
OpenAI models and pricing

And pretty much every provider charges based on the number of tokens that you're using per request. For most developers just getting started, the pricing is typically so low that you won't have to stress too much.

As an example, running a few dozen tests per day with moderate token sizes costs me a few cents on average.

But if you know that you're going to be pushing volume at some point, then you definitely need to take this into consideration when creating your prompts.

Most people don't realize that the input prompt goes towards your token limit, meaning if you have a 2000 token prompt, then you only have 2096 tokens left for output (on a 4096 max model).

Tokenization

Tokenization is how AI models break down text into processable units called tokens. These tokens serve as the fundamental building blocks that language models can understand and manipulate.

From a technical standpoint, tokens vary significantly across models. A token might represent a single character, a complete word, a word fragment, or even punctuation. This variability stems from each model's specific tokenization algorithm, which is designed to optimize processing efficiency and language understanding.

For example, the sentence "I love programming" might be tokenized as:

["I", " love", " programming"]

While a complex word like "unbelievable" might be broken down as:

["un", "believ", "able"]

Understanding tokenization becomes crucial when working with models that have token limits. These limits constrain how much text you can include in a single prompt (input) and how much the model can generate in response (output).

English text typically averages about 0.75 tokens per word, but this ratio varies by language and writing style. Technical content with specialized terminology often consumes more tokens than conversational text.

Token usage directly impacts:

Costs: Most commercial AI services charge by token count
Response time: Longer prompts generally take more time to process
Context utilization: Effective use of available context window

Prompt engineers often need to balance comprehensiveness with conciseness, crafting prompts that provide sufficient guidance while minimizing token consumption. This becomes particularly important when working with complex tasks requiring detailed instructions or when processing large documents within token limitations.

Temperature

Temperature is a key parameter that controls the randomness and creativity in AI-generated text. Ranging typically from 0 to 1 (or sometimes 0 to 2), this setting fundamentally alters how the model selects its next tokens when generating responses.

At a low temperature (0-0.3):

The model becomes highly deterministic, consistently selecting the most probable tokens
Responses are more predictable, factual, and conservative
Ideal for tasks requiring accuracy and consistency: factual Q&A, technical documentation, or logical reasoning

At a medium temperature (0.4-0.7):

The model balances predictability with variety
Outputs maintain coherence while introducing some creative elements
Well-suited for conversational interfaces, explanations, and general-purpose applications

At a high temperature (0.8-1.0+):

The model explores lower-probability token selections
Responses become more diverse, surprising, and creative
Excellent for creative writing, brainstorming, poetry, and unconventional thinking

Temperature doesn't just affect creativity. It impacts the risk profile of your applications. Higher temperatures can produce more engaging content but may also increase the likelihood of errors, logical inconsistencies, or off-topic diversions.

The optimal temperature setting depends heavily on your specific use case and quality requirements. For mission-critical applications, consider implementing human review for high-temperature outputs or using multiple generation attempts with varied temperatures and selecting the best result.

Handling Edge Cases in AI Systems

Edge cases represent the boundary conditions where AI systems are most likely to fail or produce unexpected results. While your prompt engineering might work flawlessly 90% of the time, that remaining 10% can significantly impact user experience, reliability, and the overall viability of your application.

For production-grade applications with substantial user bases, addressing these edge cases becomes critical. Consider implementing:

Prompt Guardrails:

Include explicit instructions to handle known problematic patterns
Provide clear format specifications: "Return only JSON with these exact keys..."
Set boundaries on content: "Provide exactly three recommendations, no more and no less"
Add fail-safe instructions: "If you're uncertain about any answer, acknowledge this uncertainty"

Post-Processing Validation:

Implement programmatic validation of AI outputs before displaying them to users
Verify structural integrity (JSON parsing, expected fields)
Check content against business rules and constraints
Sanitize outputs to remove potentially harmful or malformed content

Robust Error Handling:

Develop graceful fallback mechanisms when the AI response doesn't meet quality thresholds
Consider multi-pass approaches where initial outputs are refined through follow-up prompts
Implement automatic retry logic with modified prompts when failures are detected

Remember that even with extensive guardrails, some edge cases will inevitably emerge in production.

Design your systems with the assumption that AI components will occasionally fail, and ensure these failures don't compromise the core user experience or system integrity.

Contextual priming

Priming is a technique used to guide an AI models responses by providing some kind of relevant background information that it may need. It's important to remember that AI models don't have memory by default, and your prompt should contain any and all data needed in order to produce a specific output.

So if you're writing a prompt that helps someone to learn quantum physics, instead of writing:

"Explain quantum physics"

You would rather prompt:

"Explain quantum physics to a high school 
student using simple language and focus on superposition"

The first prompt above might return an overly complex explanation that gives a bad user experience, while the more specific prompt primes the model ahead of time, in order to produce a more directive response.

You can also prime the model by giving it a specific persona as well, such as a known figure or a known role:

Take on the role of a quantum physics 
professor, who uses humor to teach complex topics.

Few-shot learning

Few-shot learning is a technique used to improve the accuracy of a response by giving the model a few examples in order to teach it how to output content in a specific way.

The more examples that you give, the better the chance that you'll get a response closer to what you are looking for.

And you can do so by specifying any sample input that's required, and the expected output of that sample input, followed by the real data and a placeholder for the output.

For example:

Sample Transcript: "The CEO emphasized the importance 
of customer satisfaction. 
A new product line will be introduced 
in Q2, and employees are encouraged 
to share ideas for innovation."
Key Points:

Customer satisfaction is a top priority.
A new product line will be launched in Q2.
Employees are encouraged to contribute innovative ideas.
Transcript: {transcript}
Key Points:"*

In the snippet above, the sample transcript and the key points after it are not at all related to the real output values. They are just used to show the model what it should be generating.

You then provide the model with the real information and the model assumes what it must do next.

It's definitely a clever technique that can help you get more exact with how you want to return data.

Chain of thought thinking

Chain-of-thought prompting is a technique where the AI model is encouraged to "think step-by-step" by explicitly guiding it through intermediate reasoning steps before arriving at a final answer.

This method is particularly effective for tasks that require logical reasoning, complex problem-solving, or multi-step calculations.

Instead of asking the model for a direct answer, you structure the prompt to encourage a progressive breakdown of the problem. The intermediate steps provide a clearer pathway for the model, improving its reasoning and accuracy.

For example, if you wanted to ask a simple math question without chain of thought thinking, you might prompt something like the following:

Prompt: "If a store has 7 apples and sells 3, 
how many are left?"
 Response: 4

With chain-of-thought thinking, your prompt might look something like the following:

Prompt: "A store has 7 apples. It sells 3 
apples. First, determine how many 
apples are sold. Then subtract that 
number from the total apples. 
How many are left?"

Response: The store starts with 7 apples. It sells 3 apples. Subtracting 3 from 7 gives 4 apples left.

By specifying the particular steps that you want the model to follow, you are able to get a more detailed and accurate response.

This technique might be more beneficial in cases where you have to process user input in a very specific way in order to get an exact response.

Response formatting

Most people are used to AI models responding to a prompt in a single response output and mainly as a giant string of text.

The latest models however are able to respond in more complex ways, such as structured JSON schemas that you yourself specify in the prompt.

For example, let's say that you were working on an app that generated random coding questions for people to practice with. It would be difficult if a model responded with a giant string that you would then have to parse yourself.

Instead, you can specify the JSON schema that you would like the response in and tell the model to only return the data in that format.

Generate 3 technical programming questions and 
return then in JSON with the following schema:
[{title: 'title goes here', question: 'question goes here'}]

This is really the heart of prompt engineering. In a real-world application, you're going to need structured data in order to do anything with the UI/UX.

If you're building someone a resume using AI then you need to know what data corresponds to their past experience, education, skills, etc.

Do note though, that this isn't guaranteed to work 100% of the time either. From my experiments so far, it works 'most' of the time. But on occasion, the model might respond with a "You got it. Here's the data! [{...". Which will make it difficult to parse out.

But most of these edge cases can also be fixed by specifying to the model that it shouldn't return anything else except for valid JSON. But again, this seems to work 'most' of the time.

A few last words

Prompt engineering is evolving rapidly. The rules change as models improve, meaning that the best engineers are those who stay adaptable and continuously refine their methods.

Being able to craft concise input strings for an AI model in order to generate exact and accurate data on the other end is going to be huge in the near future as people interact more and more with artificial intelligence.

Code, Context, and AI: Why Human Developers Still Matter

Walter G. — Fri, 07 Mar 2025 19:18:04 +0000

This year has been somewhat of a wake up call to the developer community in terms of A.I. It seems like each and every month now a new tool comes out that can produce code faster and more accurately than the models before it.

Needless to say, this is going to keep happening for the foreseeable future. And many newer developers find themselves at a crossroads.

Do they continue to invest time and money into a field of study that's going to evaporate in the next decade? Or do you pivot now and save yourself the headaches?

Let's separate the hype from reality. Because after two decades of supposed "developer extinction events," I've learned something important about our industry's evolution and why human developers aren't going anywhere (yet).

What's really going on

Every few months, a headline declares that programmers are becoming obsolete. The latest AI model generates a todo app in seconds, and social media floods with predictions about the end of software development careers.

You're also starting to see articles claiming that A.I. coding assistants are making junior developers worse, so they should stop using them. I would argue that the junior developer struggle is perfectly normal and that most companies are aware of the fact and are willing to work with younger developers.

Many of these articles are way over-simplified and most are written by non-developers unfortunately. Because there's a lot missing to their narrative.

So before junior developers abandon their learning paths or seniors consider career changes, let's separate the hype from reality.

A.I. is still very limited

Today's AI coding tools are impressive but they are still very limited. They excel at generating boilerplate code, suggesting completions for repetitive patterns, and implementing well-defined features in familiar frameworks.

What they lack is genuine understanding of business contexts, architectural trade-offs, and system-wide implications of design decisions. They also lack the ability to make financial decisions, which is a key part of corporate development.

You might be responsible for an API that costs a company $100 a month based on usage and so you keep those constraints in the back of your mind. A.I. can't quite manage your books just yet.

When an AI model generates a React component or a Python function, it's drawing on patterns it's seen in training data—code written by human developers.

It can mimic structure and syntax remarkably well, but struggles with novel problems that it has never encountered.

It still lacks training data

Much of the software that exists in production today is relatively old, and it's kept that way on purpose. Mainly because the code is stable and presumably generating some form of income for a company. Most companies won't disrupt that unless there's some return on investment on the other side of things.

When I personally worked on a Classic ASP project years ago, my job wasn't to modernize it or to convert it to React. It was to figure out how it worked and to make sure that no matter what it kept running.

Much of the code was outdated, archaic, less secure and even deprecated (to some extent). But being a human developer, I knew those limitations and I was able to work around them.

I also worked with a very talented Classic ASP developer who had decades of experience and who knew the entire framework by heart. His personal 'training data' was much more abundant than any A.I. model at the time.

Currently, there's a high chance that most modern coding models are not well trained on older programming languages and frameworks. Simply because there's just less of them in public repos.

This makes them less than ideal for code generation as there's a good chance that hallucinations would be higher.

Limited capabilities

Take this scenario as an example. You meet with your product manager to discuss a new feature that they designed. A custom sticker feature like the ones you would see on a social media site.

As a developer (of the human kind), you know that this involves a new database schema, some form of image management (or even A.I. image generation) and an admin to manage all of the data.

You might even need to integrate it with your companies in-house asset management service which serves images to every website the company owns. This would be a very unique workflow that only a handful of people would know.

This might even involve creating a new Amazon S3 Bucket or possibly even storing images as Blob's in the database. Maybe you discuss it with your project manager to see what the budget is.

And you might even discuss it with your DBA (database administrator) to figure out what the best approach is when it comes to the database.

Most of these steps, A.I. can't do. At least not right now. It would need real-time data on the entire companies inner workings and it would require the input from multiple people in order to successfully build this feature out.

And this feature isn't even really that complex or innovative. So imagine having to build something that requires the input of even more people in real-time and that is constantly having its requirements changed on an hourly basis.

A.I. still needs code reviews

Furthermore, AI tools frequently produce code that looks correct at first glance but contains subtle bugs, security vulnerabilities, or inefficiencies that only become apparent during testing or production.

The ability to critically evaluate generated code and to know whether a solution is merely functional or truly optimal remains a distinctly human skill.

What we're witnessing right now isn't the replacement of developers but the evolution of development workflows.

The most successful engineers aren't fighting against AI tools but incorporating them as accelerators and using them to handle routine tasks while focusing their human creativity and problem-solving abilities on higher-level challenges.

This relationship between developer and AI amplifies productivity rather than diminishing the developer's role.

What's the best thing developers can do?

First and foremost, don't panic. If you read an article telling you that your job is in danger because ChatGPT wrote a 200 line to-do list application, then find a different news source.

If you're currently studying Computer Science, continue your studies and try your best to build a strong foundation on core programming principles.

The more AI tools evolve, the more important it becomes to understand core computer science concepts. Deep knowledge of data structures, algorithms, and system design isn't just academic—it's what helps you evaluate and optimize AI-generated code.

Embrace AI as a tool

Instead of viewing AI as competition, learn to leverage it effectively. Use AI coding assistants for what they're good at—generating boilerplate code, suggesting refactoring options, or helping with documentation.

But maintain a critical eye and understand that you're the pilot, and AI is your co-pilot.

Focus on system integration and architecture

Complex systems integration, microservices architecture, and cloud infrastructure decisions require deep understanding of business needs, security implications, and performance trade-offs.

These high-level architectural skills are far beyond current AI capabilities and will remain valuable for years to come.

Stay adaptable

More importantly though, be fluid with your learning and with your career options. Things are going to change, as they always have.

In my past career, I was a Windows Desktop developer, an X++ developer, a Classic ASP developer and an ASP.NET Web Forms developer.

All deprecated and forgotten technologies. But they were still invaluable in my career growth.

Now I mainly focus on React and other JavaScript based frameworks, because that's where the market is. And there's a chance that in the future, I will be looking back at React the way that I look back at Classic ASP.

The Future is Collaborative

The future of software development isn't about AI replacing developers—it's about developers who can effectively collaborate with AI tools outperforming those who don't. By focusing on these areas, you'll position yourself to thrive in this evolving landscape.

Remember: every major technological advancement in our field has been predicted to make programmers obsolete. Instead, each one has created new opportunities for those willing to adapt and grow.

AI will be no different and it's not an ending, but a new beginning for those who embrace it wisely.

It’s Not A.I. — Junior Developers Have Always Struggled to Code

Walter G. — Mon, 03 Mar 2025 17:16:23 +0000

AI, as of late, is taking the blame for making junior developers “worse” at writing code, but in my 20 years of experience—junior devs have always struggled to code well. Well being the keyword. It’s not a new problem. The difference? AI is just simply just highlighting the fact.

For decades, junior devs have relied on Stack Overflow, online tutorials, and helpful senior engineers to guide them in their day to day work. AI tools like Copilot aren’t replacing deep learning—they’re just streamlining what has always been a part of the learning process.

Before the time of A.I.

I started coding before Stack Overflow existed. Back then, we had 10-20lb textbooks, binders full of half-legible notes, and forums where getting an answer could take days.

In 2003, this was the way. And for the most part, we made it work. You weren’t going to become the #1 ranked programmer in the world overnight, but you were going to learn about algorithms, data structures, operating systems, and a bit of SQL (a bit).

Then Stack Overflow came along—and guess what? It faced the same scrutiny that AI tools are facing today. Developers were supposedly getting lazy. Universities banned it. People claimed it would make engineers worse because they didn’t have to struggle as much to find answers.

Did enforced struggle make better developers?

Maybe. It’s hard to say. And honestly, whatever my feelings are on the subject might be way too subjective to define all developers.

But I will say this—even with all that “pure” learning, I was still a terrible junior developer.

And nobody I worked with was surprised or resented me for it. Because that’s just how learning works.

Companies don't normally give 20 million dollar projects to the new guy who struggled to configure his dev environment. That takes time and alot of trust.

Once I entered the corporate workforce though StackOverflow was everywhere. It was refreshing that we didn't have to read 10 year old forums written in a different language in order to find out how to use a function properly.

Did reading StackOverflow daily make me a better developer? Did it make me worse, because I was relying on somewhat opiniated answers? I don't know. Maybe the answer is a bit of both.

But the fact is, I normally just copy and pasted whatever answer I found and modified it until it worked for my use case. As did many of the other developers surrounding me.

The goal wasn't to master a programming language at the end of the day. It was to check off our to-do lists for the week and hope that we worked well enough to provide some value.

The role of senior engineers

For the first five years of my career, I relied heavily on the guidance of senior developers. Not just because they could code better than me—though they definitely could—but because that was only one part of the equation.

They had experience. They had done things with code that I was never asked to do in college or in any tutorial. And when it came down to actually getting my work done, that’s what I was missing.

I still remember the first time I had to remote log into a Linux server to configure some obscure network parameters for a website migration.

I was two years into my career. I had never remote logged into anything. The acronyms my manager was throwing at me might as well have been an ancient language. And my only response was "You got it!".

Lucky for me, a senior developer was sitting two feet behind me. He walked me through the entire process, step by step, after he saw me sweating in my chair for 2 hours.

And this pattern repeated itself alot through my early years.

There were even days where high priority tasks were due within hours, and my lead developer would take the chair, start typing at lightning speed, all while dictating their every move. While I sat there confused wishing the clock would strike 12pm.

All to say, that whether you're using StackOverflow, ChatGPT, Copilot or a forum post from 2001, it's all the same thing. It's a tool to help you get some task done.

The real learning and experience really comes from repetition and from the person sitting 3 feet away that's done what you've never done, and that will gladly take their time and show you the way.

Is A.I. Hurting or Helping More

I think the answer to that question depends entirely on the developer using it and what their goals are.

Not every developer wants to memorize every search algorithm, data structure, or encryption cipher. Many just want to build cool things, to the best of their ability, while earning a paycheck.

And that’s fine.

The truth is, AI doesn’t make bad developers worse—it just exposes gaps that were always there. A good developer will use AI as a tool to accelerate learning, automate the tedious, and improve efficiency. A bad developer will copy-paste blindly, just like they always have, whether from AI or Stack Overflow.

The difference between the two? Experience. Curiosity. A willingness to learn.

AI won’t replace real-world experience. It won’t teach you why something works or save you from a debugging nightmare at 2 AM. And it definitely won’t replace the senior engineer sitting next to you, showing you how things actually get done.

So is AI hurting or helping?

That’s not up to the tool. That’s up to the developer.

Originally published at https://www.thatsoftwaredude.com on February 24, 2025.

It’s Not A.I. — Junior Developers Have Always Struggled to Code

Walter G. — Mon, 03 Mar 2025 17:05:00 +0000

Before the time of A.I.

I started coding before Stack Overflow existed. Back then, we had 10-20lb textbooks, binders full of half-legible notes, and forums where getting an answer could take days.

Did enforced struggle make better developers?

Maybe. It’s hard to say. And honestly, whatever my feelings are on the subject might be way too subjective to define all developers.

But I will say this—even with all that “pure” learning, I was still a terrible junior developer.

And nobody I worked with was surprised or resented me for it. Because that’s just how learning works.

Companies don't normally give 20 million dollar projects to the new guy who struggled to configure his dev environment. That takes time and alot of trust.

Did reading StackOverflow daily make me a better developer? Did it make me worse, because I was relying on somewhat opiniated answers? I don't know. Maybe the answer is a bit of both.

But the fact is, I normally just copy and pasted whatever answer I found and modified it until it worked for my use case. As did many of the other developers surrounding me.

The goal wasn't to master a programming language at the end of the day. It was to check off our to-do lists for the week and hope that we worked well enough to provide some value.

The role of senior engineers

They had experience. They had done things with code that I was never asked to do in college or in any tutorial. And when it came down to actually getting my work done, that’s what I was missing.

I still remember the first time I had to remote log into a Linux server to configure some obscure network parameters for a website migration.

Lucky for me, a senior developer was sitting two feet behind me. He walked me through the entire process, step by step, after he saw me sweating in my chair for 2 hours.

And this pattern repeated itself alot through my early years.

All to say, that whether you're using StackOverflow, ChatGPT, Copilot or a forum post from 2001, it's all the same thing. It's a tool to help you get some task done.

The real learning and experience really comes from repetition and from the person sitting 3 feet away that's done what you've never done, and that will gladly take their time and show you the way.

Is A.I. Hurting or Helping More

I think the answer to that question depends entirely on the developer using it and what their goals are.

Not every developer wants to memorize every search algorithm, data structure, or encryption cipher. Many just want to build cool things, to the best of their ability, while earning a paycheck.

And that’s fine.

The difference between the two? Experience. Curiosity. A willingness to learn.

So is AI hurting or helping?

That’s not up to the tool. That’s up to the developer.

Originally published at https://www.thatsoftwaredude.com on February 24, 2025.

The importance of having good folder structure in your code

Walter G. — Mon, 22 Nov 2021 19:28:14 +0000

Folder structure is something that most developers usually take for granted because often times it is something that is already present when you join a project.

When you start work at a new company, the projects are typically already set up with whatever structure the original developer came up with. If you clone a project from GitHub, then you also don't have to worry about such things.

But if you are starting a project from scratch with zero code, then coming up with correct file structure can be the most important step in the whole thing. And the most difficult as well.

What makes bad structure?

In order to figure out what makes a good file environment, let me first discuss what makes for a bad one. Because there's quite a few things.

The most notable being the lack of any consistency in terms of capitalization and special characters. The following for example isn't an ideal scenario.

__ main

__Src

__Image_Files

__ More-Image-Files

__evenMoreFiles

For one, depending on the OS that you are hosting your files on, some of these might not be valid at all. But assuming that they were valid, they still lack any form or order. If you are going to go lowercase, then ensure every directory is lowercase. If you want to use the underscore as a separator, then avoid having camel casing.

Decide early on and then stick with it through the course of the project.

This will ensure that you won't have to write any kind of special code later on in order to access directories, since they will all be following the same conventions throughout the entire project.

What makes for good structure?

Having a good naming scheme is only the beginning. There's also the issue of having too many deeply nested folders, making it both difficult to reference files in your code and also difficult to find what you are looking for.

This would look something like the following:

__src

______pages

__________accounts

______________registration

Again, this is totally valid and allowable in pretty much every OS. But the real issue happens when you continue to create more and more child directories time after time. Eventually you will end up with hundreds of folders, some with only 1 or 2 files, and a directory structure that a newcomer would easily be lost in.

Remember, you are not the only one that will be looking at the code. Typical convention aims to have a maximum of 3 levels when it comes to child folders. And if you find yourself needing to nest folders 10 layers deep, then maybe there's another issue that needs to be addressed causing that complexity.

And one last point to mention. This is one that I've personally encountered frequently in the corporate world. And that's too many files in a single directory.

The theoretical maximum number of files that you can add to a folder on Windows is around 4 billion. That's alot. And there's a good chance that you will probably never see that limit reached. But you don't need to hit the max to begin to have issues.

Because having even 10,000 files in a folder is a giant headache for a developer. For one, it becomes increasingly slower and slower to load those directories the more data they accumulate. Especially if these are large files. And secondly, it's just hard to find anything inside of them.

I've mainly seen this happen with image folders, dealing with a website that had around 80,000 image files in a single directory. Opening that folder on its native machine was pretty much an impossible task as it would hang for minutes at a time and taking a huge chunk of the performance.

On a few rare occasions, it even took the website down. Mind you this was on an older server, but still.

The solution to this problem is to pretty much split the files into more folders. Not children of each mind you. Just siblings. And that would look something like the following:

__images

__1

__ 2

__3

Essentially, sub directories with the appropriate numeric paging, splitting each folder into a set number of files. You would need to store the numeric value of the directory that the particular file finds itself in.

This only applies if you are hosting the files on your own servers of course. If you are using a cloud storage provider like Amazon S3, you can avoid much of this hassle.

I hope this post gave you an idea of the trouble that folder and file structure can bring, even before you write a single line of code. But it is something that should be planned out and built accordingly for your particular needs. It's pretty much where everything starts.