27 years of Web Development: Key Lessons Learned

In 1999, I wrote my first professional code: Classic ASP connecting to SQL Server, building an e-commerce site for OneTravel.com. Twenty-five years later, I'm building React Native apps with offline-first architecture and GraphQL APIs. The technologies changed completely, but the fundamental lessons remain constant.

Here's what 27 years of building software taught me.

Technology Lessons

Lesson 1: Fundamentals Never Change

I've learned JavaScript three times: ES5 (2009), ES6 (2015), and TypeScript (2020). I've learned databases four times: SQL Server (1999), MySQL (2005), MongoDB (2012), PostgreSQL (2018).

But the fundamentals—data structures, algorithms, system design, HTTP, databases, security—remain unchanged. A hash table works the same in 1999 and 2025. Understanding indexes mattered in SQL Server 7.0 and matters in PostgreSQL 16.

Invest in fundamentals, not frameworks. Frameworks come and go (remember Backbone.js? CoffeeScript? Gulp?). Fundamentals compound over decades.

Lesson 2: Boring Technology Wins

The most successful projects I've built used proven, "boring" technology:

PostgreSQL over the latest NoSQL database
REST APIs over the newest RPC framework
Server-side rendering over complex client-side hydration
Monorepos over microservices (for most projects)

New technology is exciting. Boring technology ships products and keeps you employed.

Lesson 3: Premature Optimization is Real

In 2003, I spent a month optimizing a query from 500ms to 50ms. Turns out, only 5 users ran that query per day. Those 2.25 seconds saved per day weren't worth 160 hours of engineering.

Meanwhile, the login page—used by 10,000 users daily—loaded in 8 seconds. I should have optimized that.

Measure first, optimize second. Profile production, not your assumptions.

Lesson 4: Simple is Better Than Clever

Early in my career, I wrote "clever" code:

// 2005: "Clever" code I was proud of
const validate = (v) => !!(v && v.match(/^\w+@\w+\.\w+$/));

Today, I write "boring" code:

// 2025: Boring code I'm proud of
function isValidEmail(email: string): boolean {
  if (!email || typeof email !== 'string') {
    return false;
  }
 
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return emailRegex.test(email);
}

The second is longer but clearer. Future me (and my teammates) can understand it instantly.

Code is read 10x more than written. Optimize for reading.

Lesson 5: Tests Are About Confidence, Not Coverage

I've seen projects with 95% test coverage that were still buggy, and projects with 60% coverage that were rock solid.

Coverage percentage doesn't matter. What matters:

Can you refactor without fear?
Can you deploy confidently?
Do tests catch real bugs?

Test the critical paths users take, not every edge case.

Lesson 6: Architecture Matters More as Codebases Grow

A 1,000-line project doesn't need architecture. A 100,000-line project desperately needs it.

Bad architecture shows up around 10,000 lines. Everything becomes harder: adding features, onboarding developers, debugging, testing. Technical debt compounds.

Good architecture (Hexagonal, CQRS, DDD) pays dividends as codebases grow. Catalyst PSA hit remained maintainable because we invested in architecture early.

Architecture is an investment that pays off over years, not weeks.

People and Process Lessons

Lesson 7: Code Reviews Are About Knowledge Sharing

Early in my career, code reviews felt like judgment. Am I good enough? Will they find mistakes?

Now I see them as knowledge sharing:

Junior developers learn patterns
Senior developers catch edge cases
Everyone understands more of the codebase
Team standards emerge organically

Best code review comment: "I didn't know you could do it that way! Thanks for teaching me."

Lesson 8: Communication > Code Quality

I've worked with brilliant developers who couldn't communicate. They wrote perfect code that no one understood, solved problems no one asked for, and frustrated every teammate.

I've also worked with good (not great) developers who communicated constantly. They asked clarifying questions, documented decisions, explained tradeoffs, and helped everyone ship faster.

The second group had more impact.

Clear communication—in PRs, docs, Slack, and meetings—multiplies your effectiveness.

Lesson 9: Estimates Are Guesses, and That's Okay

In 2007, I estimated a feature would take 2 weeks. It took 6 weeks. I felt terrible.

In 2025, I estimate a feature will take 2 weeks. It takes 6 weeks. I don't feel terrible—I update the estimate and communicate why.

Software is inherently uncertain. Hidden complexity, changing requirements, integration challenges—these are inevitable.

Estimate with ranges (1-3 weeks), update frequently, and communicate changes early.

Lesson 10: Rewrites Usually Fail

I've participated in four major rewrites:

2004: VB6 → .NET (failed, went back to VB6)
2009: Classic ASP → Ruby on Rails (failed after 18 months)
2013: PHP monolith → Node.js microservices (succeeded but took 3 years)
2019: Angular → React (succeeded in 6 months with incremental migration)

The successful rewrites were incremental—gradually replacing the old system. The failed rewrites were big-bang—rewrite everything from scratch.

Strangler fig pattern > big rewrite.

Lesson 11: Production is the Hardest Environment

All my bugs looked fine in development. Most looked fine in staging. They only appeared in production:

When 1,000 users hit the system simultaneously
When the database has 10 million rows, not 1,000
When cellular connectivity drops mid-request
When users do things you never imagined

Production is where software lives. Monitor it obsessively.

Lesson 12: Delete More Than You Add

The best code is no code. The best feature is a deleted feature.

I've spent weeks building features users never adopted. I've maintained complex code paths used by 5 customers. I've debugged systems where 40% of the code was dead.

Before adding, ask: Can we delete something instead? Can we simplify?

Career Lessons

Lesson 13: Specialists and Generalists Both Win

I've been both:

Specialist (2005-2010): Deep .NET expertise
Generalist (2010-2020): Full-stack JavaScript, mobile, DevOps
Specialist again (2020-2025): React Native and enterprise architecture

Both paths work. Specialists command higher rates. Generalists have more opportunities.

Follow your curiosity, not a career plan.

Lesson 14: Teaching Compounds Your Learning

I've learned more from writing blog posts, mentoring junior developers, and giving conference talks than from building features.

Teaching forces you to:

Understand deeply (can't explain what you don't understand)
Identify patterns (teaching requires generalization)
Get feedback (students ask questions you never considered)

If you want to master something, teach it.

Lesson 15: Side Projects Are Overrated

I've built dozens of side projects. Most failed. A few made money. None changed my career as much as doing great work at my day job.

The developers who got promoted, who built reputation, who got interesting opportunities—they weren't the ones with the most side projects. They were the ones who shipped great products at work and helped their teammates succeed.

Side projects are fun, but excellence at work matters more.

Lesson 16: Network > Portfolio

I've gotten exactly zero jobs from my portfolio. I've gotten every job from my network:

Former coworkers who recommended me
Conference connections who remembered me
Open source contributors I helped

Your reputation with people you've worked with is your true portfolio.

Lesson 17: Imposter Syndrome Never Ends

In 1999, I thought: "Once I'm a senior developer, I'll feel confident."

In 2010: "Once I'm an architect, I'll feel confident."

In 2025: "Once I'm a CTO, I'll feel confident."

Imposter syndrome doesn't go away with experience. Everyone—even 25-year veterans—feels it.

Accept it. Feel it. Ship anyway.

Technical Philosophy Lessons

Lesson 18: Build for Today, Design for Tomorrow

Don't over-engineer for scale you don't have. Also don't paint yourself into corners you can't escape.

Use PostgreSQL (scales to millions of rows) instead of SQLite
Use TypeScript (refactorable) instead of JavaScript
Use interfaces/abstractions (swappable) instead of tight coupling

Build the simplest thing that works, but design it so you can grow.

Lesson 19: Security is Everyone's Job

I've seen security as an afterthought lead to:

SQL injection vulnerabilities in production
Exposed API keys in client-side code
Unencrypted sensitive data
Cross-tenant data leakage

Security can't be "the security team's problem." It must be baked into every PR, every feature, every deployment.

Security review is as important as code review.

Lesson 20: Users Don't Care About Your Stack

I've been excited about GraphQL, excited about React, excited about Kubernetes.

Users don't care. They care about:

Does it work?
Is it fast?
Can I accomplish my task?

Your job is solving user problems, not using cool technology.

Lesson 21: Automate the Boring Stuff

In 2005, I manually deployed to production: FTP files, run SQL scripts, restart IIS. It took an hour and broke regularly.

In 2025, I push to main and CI/CD deploys automatically in 5 minutes. Database migrations run automatically. Rollbacks are one click.

The time I invested in CI/CD (maybe 20 hours) has saved thousands of hours and prevented countless deployment bugs.

Automate anything you do more than twice.

Lesson 22: Monoliths Are Fine

Microservices are trendy. But I've built successful products as monoliths and struggled with premature microservices.

Unless you have Netflix's scale and team size, start with a monolith. It's:

Easier to develop (one codebase)
Easier to deploy (one service)
Easier to debug (one log)
Faster to build features (no network calls between services)

Monoliths scale farther than you think. Microservices scale teams, not technology.

Lesson 23: Documentation is a Love Letter to Future You

I've inherited codebases with zero documentation. I've spent weeks reverse-engineering business logic that could have been explained in a paragraph.

I've also inherited codebases with great docs. I was productive on day one.

Documentation isn't for users—it's for:

Future you (in 6 months)
Your teammates
Your replacement

Document why, not what. The code shows what. The docs explain why.

Lesson 24: Burnout is Real

I've burned out twice:

2008: Working 70-hour weeks on a failing rewrite
2016: Maintaining a legacy system solo while building a replacement

Both times, I thought: "I just need to push through." Both times, I crashed hard—depression, health issues, months to recover.

Sustainable pace > heroic sprints. Career is a marathon.

Lesson 25: Software is About People

The best code I've written doesn't matter if it doesn't help people. The perfect architecture doesn't matter if it doesn't ship.

Software engineering is ultimately about:

Solving user problems
Enabling business goals
Collaborating with teammates
Building things that last

Technology is the tool. People are the purpose.

What I'd Tell My Younger Self

If I could go back to 1999 and give myself advice:

Learn fundamentals, not frameworks
Write simple code, not clever code
Communicate more, code less
Delete more, add less
Build relationships, not portfolios
Ship products, not perfect code
Take care of yourself—it's a marathon

But honestly, I probably wouldn't listen. Some lessons only stick when you learn them yourself.

Conclusion

Twenty-five years is a long time in technology. I've seen languages rise and fall, paradigms shift, entire platforms emerge and disappear.

But the core lessons remain: Build for users. Keep it simple. Invest in fundamentals. Communicate clearly. Take care of yourself and your team.

Technology is the easy part. The hard part is everything else—people, process, product, priorities.

Here's to the next 27 years. I have no idea what technology we'll be using, but I know the lessons will be the same.

The best time to start learning was 27 years ago. The second best time is today.