Avoiding Ageism in Tech: Building Proof via Public Projects

Last year I applied for a contract role at a company that shall remain nameless. The recruiter was enthusiastic on the phone. My experience matched perfectly. Then came the video call with the hiring manager — a guy maybe ten years out of college — and I watched his expression shift the moment my camera turned on. The conversation that had been warm and technical became polite and brief. I never heard back.

I'm 52. I've been writing code since I was a teenager. I've shipped products that are still running in production, led teams, built businesses, and published a book about training LLMs. None of that mattered in that moment. What mattered was that I looked like somebody's dad.

This is the reality of ageism in tech, and pretending it doesn't exist won't help you navigate it. But here's what I've learned: the single most effective weapon against age bias isn't complaining about it, fighting it in court, or trying to look younger on Zoom. It's building undeniable public proof that you're still dangerous.

---

The Problem Is Real, and It's Structural

Let's not sugarcoat this. The tech industry has a youth obsession baked into its culture. The median age at most major tech companies hovers around 29-33. Job postings that mention "high-energy environment" and "digital native" are saying the quiet part out loud. When a hiring manager sees gray hair and three decades of experience, they're not always thinking "wisdom and reliability." Sometimes they're thinking "expensive, slow to adapt, hard to manage."

I've talked to dozens of engineers over 45 who've experienced this. The patterns are consistent. Interviews that go nowhere despite strong technical performance. Feedback that's vague and contradictory — "not a culture fit" being the perennial favorite. Recruiters who ghost after seeing a LinkedIn profile with a graduation date from the 1990s.

The frustrating part is that most of these biases aren't even conscious. The hiring manager who dismissed me wasn't twirling a mustache. He probably genuinely believed he was making an objective assessment. The bias is in the assumptions: that older developers don't keep up with new technology, that they resist change, that they'll be difficult to work with.

You can't fix other people's assumptions. But you can make those assumptions look ridiculous.

---

Why Public Projects Are the Antidote

Here's the thing about bias: it thrives in the absence of evidence. When a hiring manager has nothing to go on but your resume and your face, they fill the gaps with assumptions. But when they can see a GitHub profile with recent commits using modern tools, a deployed application that's actually running, or a technical blog post that demonstrates current knowledge — the assumptions don't have room to take hold.

Public projects are proof that can't be argued with. They don't care how old you are. They either work or they don't. They either demonstrate competence or they don't.

I started getting serious about public projects about five years ago, and the shift in how I'm perceived has been dramatic. Not because I suddenly got better at programming — I was already good at programming. But because I created an artifact trail that makes my skills visible and verifiable.

Let me break down what's worked.

---

Strategy 1: Ship Something Real and Keep It Running

The most powerful proof is a live application. Not a tutorial project. Not a code sample. A real thing that real people use, that's deployed on real infrastructure, that you maintain and iterate on.

For me, that's several things. Grizzly Peak Software itself — this website you're reading right now — is an Express.js application running on DigitalOcean. I built it, I maintain it, I add features to it regularly. AutoDetective.ai is another one — a production AI tool with actual users.

The power of a live application is that it demonstrates a range of skills simultaneously. You didn't just write code. You deployed it. You handled SSL. You set up a database. You dealt with production issues. You iterated based on feedback. That's the full stack of professional software development, and it's visible to anyone who cares to look.

Here's how I think about setting up a public project:

// Even your project structure tells a story about your skills
// A well-organized Express app signals professional experience

var express = require('express');
var app = express();

// Modern middleware choices show you're current
var helmet = require('helmet');
var rateLimit = require('express-rate-limit');

app.use(helmet());
app.use(rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100
}));

// Clean route organization
app.use('/api/v1', require('./routes/api'));
app.use('/', require('./routes/pages'));

var port = process.env.PORT || 8080;
app.listen(port, function() {
  console.log('Server running on port ' + port);
});

That's not impressive code. It's competent code. And competence, demonstrated publicly, is the point.

---

Strategy 2: Use Current Technology Visibly

One of the strongest biases against older developers is the assumption that we stopped learning new things at some point. That we're still writing jQuery plugins and configuring Apache servers while the world moved on.

The counter is simple: use modern tools in your public work and make it obvious that you're using them.

When I built the jobs board feature for Grizzly Peak Software, I used the Claude API for AI-powered job classification. When I needed a content pipeline, I built it with Node.js and PostgreSQL. When I write about technical topics, I write about things that are current — LLMs, API design patterns, AI-assisted workflows.

This doesn't mean chasing every trend. I'm not going to rewrite my applications in the framework of the month just to look current. But it means that when I choose tools, I choose modern, well-supported ones, and I make those choices visible.

Your GitHub profile should tell a story. If someone looks at your repositories and sees recent activity with current libraries, that story is "this person is actively building with modern tools." If they see a bunch of repos from 2016 with no recent activity, the story is different — and it's the story that feeds the bias.

// Using current AI APIs demonstrates you're not stuck in the past
var Anthropic = require('@anthropic-ai/sdk');

var client = new Anthropic();

function classifyContent(text) {
  return client.messages.create({
    model: 'claude-sonnet-4-20250514',
    max_tokens: 500,
    messages: [{
      role: 'user',
      content: 'Classify the following text into one of these categories: ' +
               'AI, Architecture, Career, DevOps, Security. Text: ' + text
    }]
  }).then(function(response) {
    return response.content[0].text.trim();
  });
}

Nobody looks at code like that and thinks "this person can't keep up."

---

Strategy 3: Write About What You Build

Code alone isn't always enough. Not everyone is going to dig through your repositories and read your source files. But almost everyone will read a well-written article that explains what you built, why you built it, and what you learned.

Technical writing is a force multiplier for public proof. It takes a project that might be invisible and makes it discoverable, shareable, and memorable. It also demonstrates communication skills — something that experienced engineers have in abundance and that's genuinely valuable.

I've been writing technical articles for Grizzly Peak Software consistently, and the return on that investment has been enormous. Not just in traffic or SEO value, but in how people perceive my technical relevance. When someone reads an article I wrote about API gateway patterns or LLM fine-tuning, they're not thinking about my age. They're thinking about the content.

The key is specificity. Don't write generic "how to use React" tutorials. Write about specific problems you solved, specific decisions you made, specific tradeoffs you navigated. That kind of writing can't be faked, and it demonstrates depth that no resume bullet point can match.

---

Strategy 4: Contribute to Open Source (Even Small Contributions)

You don't need to maintain a popular open-source project. Even small, consistent contributions demonstrate engagement with the broader development community.

I'm not talking about gaming your GitHub contribution graph with trivial commits. I'm talking about genuine contributions: fixing a bug you encountered, improving documentation that confused you, adding a test case for an edge case you discovered.

The contribution record tells a story. It says you're active. It says you engage with other developers' code. It says you understand modern development workflows — pull requests, code review, CI/CD pipelines.

Even opening well-documented issues is valuable. A thoughtfully written bug report demonstrates technical communication skills and shows that you're using current tools in real scenarios.

---

Strategy 5: Build in Public and Talk About It

Social proof compounds. When you build something and talk about it — on LinkedIn, on Twitter, in dev communities, wherever — you create multiple touchpoints that reinforce the same message: this person is actively building and shipping.

I'm not a natural self-promoter. The idea of posting about my work on social media felt uncomfortable at first. But I've learned that there's a difference between self-promotion and simply sharing your work. When you post about a technical challenge you solved or a project milestone you hit, you're providing value to other engineers while simultaneously building your public profile.

The older developer who's quietly shipping production code from a cabin in Alaska is invisible. The older developer who's doing the same thing but writing about it and sharing it publicly is undeniable.

---

What Doesn't Work

Let me save you some time with strategies I've seen fail.

Hiding your age doesn't work. Removing graduation dates from your resume, dying your hair, using old photos — these are band-aids that fall off at the first video call. They also signal insecurity, which is worse than the thing you're insecure about.

Complaining about ageism doesn't work. I'm not saying you shouldn't advocate for fair hiring practices. You should. But leading with "the industry is biased against older developers" in professional conversations positions you as a victim, not a candidate.

Competing on junior-level terms doesn't work. You're not going to out-hustle a 25-year-old on hours worked per week, and you shouldn't try. Your advantage is experience, judgment, and the ability to solve problems that junior developers haven't seen yet. Lean into that.

Certification collecting doesn't work. A wall of certifications without corresponding projects tells me you can pass tests, not that you can ship software. The project is always more convincing than the certificate.

---

The Long Game

Here's what I've learned after years of navigating this: building public proof isn't just a defense against ageism. It's a career strategy that works at any age.

When I was 35, I got jobs based on my resume and interview skills. When I was 45, I started getting opportunities based on what people could find about me online. Now, at 52, the best opportunities come from people who've seen my work — my projects, my writing, my contributions — before we ever talk.

The resume becomes secondary when the evidence is public. The bias becomes harder to maintain when the proof is right there. The age becomes irrelevant when the work speaks for itself.

I'm not going to pretend that building a public portfolio eliminates ageism. It doesn't. There will always be hiring managers who make snap judgments based on appearances. But here's the practical reality: you don't need every door to open. You need the right doors to open. And the doors that open because someone saw your work and was impressed by it tend to lead to better rooms anyway.

---

Getting Started Today

If you're an experienced developer who hasn't built a public presence, here's what I'd do this week:

1. Pick a small project. Something you can build and deploy in a weekend. It doesn't need to be revolutionary. A useful tool, an API wrapper, a data dashboard — something that works and that you'd actually use.

2. Deploy it. Not on localhost. On a real server with a real domain. DigitalOcean, Railway, Render — pick one and get it running.

3. Write about it. One article. What you built, why, and what you learned. Post it somewhere public.

4. Push the code. Clean it up enough that you're not embarrassed, put it on GitHub, and write a decent README.

5. Repeat. Consistency beats intensity. One small project per month builds a portfolio that's impossible to dismiss.

The developers who thrive after 50 aren't the ones who figured out how to hide their age. They're the ones who made their age irrelevant by making their work impossible to ignore.

Start building. Start shipping. Start making the proof public. The bias doesn't disappear, but it becomes someone else's problem instead of yours.

---

Shane is the founder of Grizzly Peak Software. He builds AI tools from a cabin in Alaska and writes about the things they don't teach you in computer science programs — like how to stay relevant for three decades and counting.