DEV Community: Kirill Tolmachev

ORMs Are a Lie We Tell Junior Developers So They Don't Have to Learn SQL

Kirill Tolmachev — Fri, 27 Feb 2026 14:00:00 +0000

ORMs Are a Lie We Tell Junior Developers So They Don't Have to Learn SQL Every time I see another developer struggle with a performance issue that could be solved in 30 seconds with raw SQL, I wonder: what have we done? We've created an entire generation of backend developers who think databases are magic boxes that respond to method chains. Here's the uncomfortable truth: teaching ORMs first is like teaching someone to drive using only cruise control and lane assist. Sure, they'll get from point A to point B, but the moment something goes wrong, they're helpless. ## The Comfortable Lie ORMs promise productivity. They promise safety. They promise that you never have to think about the database layer again. These promises aren't just false—they're actively harmful. When you use an ORM, you're not writing database queries. You're writing code that generates database queries. That extra layer of abstraction doesn't eliminate complexity; it hides it. And hidden complexity is the most dangerous kind. I worked on a project where a single API endpoint was taking 8 seconds to respond. The ORM was generating 47 separate queries to fetch data that could have been retrieved with one well-crafted JOIN. The developer responsible had three years of experience and genuinely didn't understand why `User.orders.items.categories` was slow. The ORM made it look so simple. ## What We're Actually Teaching When we start junior developers with ORMs, we're teaching them that databases are implementation details. We're teaching them that performance is someone else's problem. We're teaching them to trust magic. But databases aren't implementation details. They're the foundation everything else sits on. A poorly designed database will cripple your application no matter how clean your business logic is. A poorly understood database will generate bugs that are invisible until production load hits. The N+1 query problem isn't an edge case. It's a fundamental misunderstanding of how relational data works. When your ORM lets you write `user.posts.each { |post| puts post.comments.count }`, you're not writing elegant code. You're writing a database destroyer. ## The Performance Trap ORMs optimize for developer convenience, not database efficiency. They generate safe, generic SQL that works in all cases but excels in none. Your ORM will happily SELECT * from a table with 50 columns when you need just 2. It will use subqueries where JOINs would be faster. It will generate WHERE clauses that can't use indexes. And because it's hidden behind a friendly API, you won't notice until it's too late. I've seen production systems where adding eager loading (.includes() in Rails, .Include() in Entity Framework) improved performance by 95%. That's not optimization—that's fixing fundamentally broken data access patterns. ## SQL Is Not That Hard The real reason we reach for ORMs isn't complexity. SQL is not a difficult language. Basic CRUD operations take minutes to learn. JOINs take an afternoon. Window functions take a weekend. The real reason is that SQL feels old-fashioned. It doesn't look like the modern languages we use everywhere else. It doesn't have method chaining or fluent interfaces. It looks like what it is: a specialized tool for a specific job. But specialized tools exist for good reasons. You wouldn't use a Swiss Army knife to build a house, and you shouldn't use an ORM to handle complex data relationships. ## When ORMs Make Sense I'm not saying ORMs are always wrong. They excel at simple CRUD operations on single tables. They handle migrations well. They provide useful abstractions for connection pooling and transaction management. But they should be tools in your toolkit, not the foundation of your data layer. Use them for the easy stuff. Drop down to SQL for the complex stuff. And always, always understand what queries your ORM is generating. ## Teaching SQL First Imagine starting junior developers with SQL instead of ORMs. They would: - Understand exactly what their code is doing to the database - Write more efficient queries from day one - Debug performance problems with confidence - Design better database schemas - Ask the right questions about data access patterns Would they be slower initially? Maybe. But they'd be building on solid foundations instead of convenient abstractions. ## The Way Forward Stop treating SQL like assembly language. It's not a low-level detail you graduate away from. It's a powerful, expressive language for working with relational data. Start new developers with SQL. Teach them to write queries by hand. Show them how to read execution plans. Make them understand indexes. Then, and only then, introduce ORMs as productivity tools. Your junior developers will thank you when they're not debugging mysterious performance issues at 2 AM. Your database will thank you when it's not processing 50 queries instead of 1. Most importantly, you'll have developers who understand their tools instead of just using them. And that makes all the difference. ## What You Can Do Right Now If you're a senior developer, stop accepting "the ORM handles it" as an answer. Require your team to explain the SQL their code generates. If you're learning, spend a week writing raw SQL before you touch an ORM. Create tables, insert data, write JOINs. Understand what you're abstracting away. If you're hiring, ask candidates to write a SQL query during interviews. Not a trick question—just a basic JOIN. You'll be shocked how many can't do it. The lie we tell junior developers isn't protecting them. It's crippling them. Time to tell the truth.

I Replaced a 2,000-Line Service with a SQL Query. It's Been Running for 3 Years.

Kirill Tolmachev — Wed, 25 Feb 2026 14:00:00 +0000

I Replaced a 2,000-Line Service with a SQL Query. It's Been Running for 3 Years.

Most developers are afraid of their database. I mean truly, deeply afraid. They'll spend weeks building elaborate application-layer solutions to problems that SQL could solve in fifteen minutes. I've watched brilliant engineers write thousands of lines of Python to do what a window function handles elegantly. Stop it.

Three years ago, I inherited a service that was the poster child for this madness. A sprawling, 2,000-line Python monster that calculated user engagement scores by pulling data from six different tables, running complex transformations in memory, and somehow managing to be both slow and wrong. The original author had clearly never heard of a JOIN.

The Problem Was Simple (The Solution Wasn't)

We needed to calculate engagement scores for users based on their activity patterns. The score combined:

Comment frequency over the past 90 days
Post quality metrics (views, likes, shares)
Session duration patterns
Peak activity timing

The Python service did this by:

Fetching all user IDs
For each user, querying comments table
For each user, querying posts table
For each user, querying sessions table
Loading everything into pandas DataFrames
Running transformations
Calculating weighted averages
Storing results back to the database

This ran every hour. It took 45 minutes to complete. On good days.

The service had its own Docker container, its own logging pipeline, its own monitoring dashboard. It consumed more resources than our main API. For what? Math that belonged in the database from day one.

SQL Doesn't Need Your Permission to Be Powerful

Here's the uncomfortable truth: Your application logic is probably just reimplementing SQL poorly. Modern databases are phenomenally capable. PostgreSQL has window functions, CTEs, advanced aggregations, and JSON operators that most developers never touch.

The replacement query took me four hours to write:

WITH user_comments AS (
  SELECT 
    user_id,
    COUNT(*) as comment_count,
    AVG(LENGTH(content)) as avg_comment_length
  FROM comments 
  WHERE created_at > NOW() - INTERVAL '90 days'
  GROUP BY user_id
),
user_posts AS (
  SELECT 
    user_id,
    COUNT(*) as post_count,
    SUM(view_count) as total_views,
    AVG(like_count::float / GREATEST(view_count, 1)) as engagement_rate
  FROM posts 
  WHERE created_at > NOW() - INTERVAL '90 days'
  GROUP BY user_id
),
session_patterns AS (
  SELECT 
    user_id,
    AVG(duration_minutes) as avg_session_duration,
    COUNT(*) as session_count,
    EXTRACT(hour FROM created_at) as peak_hour
  FROM user_sessions 
  WHERE created_at > NOW() - INTERVAL '90 days'
  GROUP BY user_id, EXTRACT(hour FROM created_at)
),
peak_activity AS (
  SELECT 
    user_id,
    MODE() WITHIN GROUP (ORDER BY peak_hour) as most_active_hour,
    AVG(avg_session_duration) as avg_duration
  FROM session_patterns
  GROUP BY user_id
)
UPDATE user_engagement_scores 
SET 
  score = LEAST(100, GREATEST(0, 
    (COALESCE(uc.comment_count, 0) * 0.3) +
    (COALESCE(up.engagement_rate, 0) * 40) +
    (COALESCE(pa.avg_duration, 0) * 0.2) +
    (CASE 
      WHEN pa.most_active_hour BETWEEN 9 AND 17 THEN 10
      WHEN pa.most_active_hour BETWEEN 18 AND 22 THEN 15  
      ELSE 5
    END)
  )),
  updated_at = NOW()
FROM users u
LEFT JOIN user_comments uc ON u.id = uc.user_id
LEFT JOIN user_posts up ON u.id = up.user_id  
LEFT JOIN peak_activity pa ON u.id = pa.user_id
WHERE user_engagement_scores.user_id = u.id;

This runs in 2.3 seconds. On our largest dataset. Every time.

Why Developers Fear the Database

I think the real issue is control. Application code feels safe because you can step through it with a debugger. You can add print statements. You can unit test each tiny piece in isolation.

SQL feels opaque. Black magic happening inside the database. What if it's slow? What if it locks tables? What if the query planner picks the wrong index?

But here's what that 2,000-line service taught me: Complex application logic is infinitely harder to debug than complex SQL. When the Python service broke (and it broke constantly), finding the bug meant tracing through layers of abstraction, debugging pandas operations, and hunting down edge cases in the transformation pipeline.

When the SQL query has issues? You run EXPLAIN ANALYZE and fix the obvious problem.

The Performance Wasn't Even Close

The old Python service:

45 minutes runtime
8GB memory usage at peak
Failed silently when data was inconsistent
Required constant babysitting

The SQL replacement:

2.3 seconds runtime
Zero memory overhead (database handles it)
Fails fast with clear error messages
Runs unattended for three years

We deleted 2,000 lines of code, removed a Docker container, eliminated three monitoring dashboards, and improved performance by 1,100x.

Sometimes the best code is no code.

When SQL Is the Wrong Choice

I'm not advocating for putting all business logic in the database. SQL is terrible for complex branching logic, external API calls, or anything requiring loops and conditionals.

But for data transformation, aggregation, and analysis? Stop fighting your database. It's optimized for exactly this work.

The sweet spot: Use SQL for what it's good at (data), use application code for what it's good at (business logic, external integrations, user interactions).

Your Action Plan

Look at your codebase right now. Find the services that:

Pull large datasets into memory
Run aggregations in application code
Take forever to execute
Handle mostly data transformation

Ask yourself: Could this be a SQL query?

Don't let fear of the database drive architectural decisions. Your PostgreSQL instance is probably more capable than the last three microservices you built combined.

The 2,000-line service is gone. The SQL query remains, quietly doing its job every hour for three years. No maintenance, no failures, no drama.

Sometimes the old ways are better.

You Don't Need Kubernetes. You Need a Single $40/Month Server.

Kirill Tolmachev — Tue, 24 Feb 2026 14:00:00 +0000

Your startup just burned three months and $50k implementing Kubernetes for an app that serves 200 concurrent users. The same workload runs flawlessly on a single DigitalOcean droplet that costs less than your daily coffee budget.

Stop. Breathe. You've been fooled by the complexity industrial complex.

The Kubernetes Cargo Cult

I've watched brilliant engineers spend weeks debugging why their "hello world" microservice won't start in their 47-node cluster while their competitor ships features on a $5 VPS. We've created a generation of developers who think you need an orchestration platform before you need customers.

Here's what actually happens when you choose Kubernetes for your 10-user MVP:

Your simple three-tier app now requires 12 different YAML files. You need to understand ingress controllers, service meshes, persistent volume claims, and network policies. Your deployment pipeline breaks every Tuesday because someone updated a Helm chart. Your monitoring stack uses more resources than your actual application.

The $40 Server That Could

A modern VPS with 4 CPU cores, 8GB RAM, and SSD storage handles more traffic than most startups will see in their first two years. I've run production systems serving millions of requests monthly on hardware that fits in your laptop bag.

Here's what this looks like in practice:

Web server: Nginx reverse proxy (handles 10k concurrent connections easily)
Application: Your app in Docker containers, managed by systemd
Database: PostgreSQL with proper tuning (yes, on the same box)
Caching: Redis for sessions and hot data
Monitoring: Prometheus + Grafana, lightweight setup
Backups: Daily snapshots, rsync to object storage

Total monthly cost: $40. Total management overhead: 2 hours per month.

But My Scaling Requirements!

No, you don't have scaling requirements. You have scaling fantasies.

Your app that struggles to retain 100 daily active users doesn't need horizontal pod autoscaling. You need product-market fit. Your database that stores 50MB of user data doesn't need sharding strategies. You need customers who want to give you money.

Most "scale problems" are actually performance problems. I've seen single-server setups handle 50,000+ concurrent users with proper caching, database indexing, and optimized queries. The bottleneck isn't your infrastructure. The bottleneck is your code.

When You Actually Need Kubernetes

Real talk: Kubernetes solves real problems for real companies. But those companies look different than yours.

You need Kubernetes when:

Multiple teams deploy independently dozens of times per day
You're running 100+ services with complex interdependencies
Compliance requires strict resource isolation and audit trails
You have dedicated platform engineers (plural) on staff
Downtime costs more than infrastructure complexity

Notice what's missing from that list? "I might need to scale someday" isn't there.

The Single Server Playbook

Ready to escape YAML hell? Here's your migration plan.

Week 1: Provision a VPS, install Docker, migrate your simplest service. Set up basic monitoring and backups. You'll be shocked how fast it is.

Week 2: Migrate your database. Use connection pooling, enable query logging, set up automated backups to cloud storage. Benchmark everything.

Week 3: Move remaining services, set up CI/CD that actually works, implement blue-green deployments with simple bash scripts.

Week 4: Enjoy your newfound simplicity while your competitors debug their ingress controllers.

The Performance Reality Check

I ran load tests comparing identical applications on Kubernetes vs single-server deployments. The single server won every benchmark under 10,000 concurrent users. Lower latency, higher throughput, zero network overhead between containers.

Your database queries run faster when they're not crossing container network boundaries. Your cache hits improve when Redis sits on localhost. Your debugging sessions shrink from hours to minutes when you can SSH into one box and see everything.

Escape Velocity

The dirty secret of modern infrastructure: complexity compounds faster than benefits. Every abstraction layer adds failure modes. Every orchestration tool requires specialists. Every "cloud native" pattern increases your bus factor.

Simple systems scale. Complex systems break in new and exciting ways at 2 AM.

Your users don't care about your elegant microservice architecture. They care about fast page loads and features that work. A single optimized server delivers both better than a poorly managed cluster.

Start simple. Stay simple as long as possible. Scale when you have problems that require scaling, not problems that require customers.

The $40 server is waiting. Your future self will thank you.

Every REST API I've Seen in Production Violates REST. Nobody Cares.

Kirill Tolmachev — Mon, 23 Feb 2026 14:00:00 +0000

Roy Fielding must be spinning in his still-very-much-alive chair. The man who coined REST in his 2000 dissertation watches as an entire industry slaps "REST API" labels on endpoints that would make him weep into his coffee. And you know what? We're all better for it.

Every "RESTful" API I've audited in fifteen years of backend work commits the same sins. They return JSON instead of hypermedia. They stuff action verbs into URLs like /api/users/123/activate. They ignore HATEOAS completely. They treat HTTP status codes like suggestions rather than contracts.

But here's the uncomfortable truth: these "violations" make APIs faster to build, easier to consume, and simpler to maintain.

The Academic REST vs The Real World

True REST, as Fielding envisioned it, demands six constraints. Stateless communication, cacheable responses, uniform interface, layered system, code on demand, and the big one that trips everyone up: hypermedia as the engine of application state.

HATEOAS means your API responses should contain links telling clients what actions they can take next. Like a choose-your-own-adventure book for computers.

{
  "id": 123,
  "name": "John Doe",
  "status": "active",
  "_links": {
    "self": {"href": "/users/123"},
    "deactivate": {"href": "/users/123/deactivate", "method": "POST"},
    "edit": {"href": "/users/123", "method": "PUT"}
  }
}

Beautiful in theory. Absolute hell in practice.

Why Everyone Ignores HATEOAS

I worked on a project where the backend team spent three months implementing proper HATEOAS. The frontend developers revolted. Mobile developers threatened to quit. The API became a maze of link-following that turned simple operations into multi-round-trip nightmares.

Frontend frameworks expect predictable endpoints. Mobile apps need offline capabilities that break when every action depends on server-provided links. GraphQL exists partly because REST's hypermedia constraints feel like handcuffs when you're trying to ship features.

The industry collectively decided that having /users/123/activate is more valuable than maintaining Roy Fielding's architectural purity. And we're right.

The Status Code Theater

HTTP status codes tell another story of pragmatic rebellion. Academic REST demands precise status codes for every scenario.

201 for created resources
202 for accepted but not processed
204 for successful deletion
422 for validation errors

Real APIs? Most return 200 for everything that doesn't explode, stuff error details in the response body, and call it a day.

{
  "success": false,
  "error": "User not found",
  "code": "USER_NOT_FOUND"
}

This drives REST purists crazy. It also prevents client-side libraries from breaking when status codes change between API versions.

Resource URLs That Aren't Actually Resources

True REST treats everything as resources identified by URLs. Actions happen through HTTP verbs on those resources.

But what happens when you need to send a password reset email? Or trigger a complex workflow? Or batch process a thousand records?

You get endpoints like:

POST /send-password-reset
POST /workflows/inventory-sync/trigger
POST /batch/process-orders

These aren't resources. They're RPC calls wearing REST costumes. And that's perfectly fine because sometimes you need to tell a server to DO something, not just manipulate data.

JSON Killed the Hypermedia Star

The final nail in REST's coffin was JSON becoming the default response format. XML supported rich linking structures through standards like XLink. JSON turned APIs into simple data dumps.

Compare this XML response:

<user id="123" xmlns:xlink="http://www.w3.org/1999/xlink">
  <name>John Doe</name>
  <link rel="edit" xlink:href="/users/123" />
  <link rel="delete" xlink:href="/users/123" />
</user>

With the JSON equivalent developers actually want:

{
  "id": 123,
  "name": "John Doe"
}

The JSON version loses hypermedia capabilities but gains simplicity, performance, and developer happiness. We chose convenience over architectural correctness.

What We Actually Built Instead

Modern "REST" APIs are really just HTTP-based RPC with some conventions:

Use HTTP verbs when they make sense
Structure URLs in a hierarchy when possible
Return JSON because everyone expects it
Use status codes for major categories (success/client error/server error)
Ignore hypermedia unless you have infinite time and patience

This hybrid approach gives us 80% of REST's benefits with 20% of its complexity. That's an engineering win.

The Practical Takeaway

Stop feeling guilty about your "impure" REST APIs. Focus on what actually matters:

Consistency over compliance. Pick conventions and stick to them across your entire API surface.

Developer experience over dogma. Your API's job is to make other developers productive, not to satisfy academic requirements.

Pragmatic status codes. Use 200/400/401/403/404/500 for 95% of scenarios. Add others only when clients need to handle them differently.

Embrace RPC when needed. Some operations aren't resource manipulations. Don't force them into resource-based URLs just to satisfy REST purists.

The internet runs on APIs that violate REST principles. It works because we optimized for reality instead of theory. Roy Fielding gave us a foundation, but we built something more practical on top of it.

And that's exactly how software evolution should work.

Caching Is the Root of All Evil in Modern Backend Systems

Kirill Tolmachev — Sun, 22 Feb 2026 14:00:00 +0000

Caching Is the Root of All Evil in Modern Backend Systems

You think caching is your friend. You're wrong. That Redis instance humming away in your infrastructure? It's not solving your problems. It's creating new ones, hiding the real issues, and slowly strangling your system's ability to scale gracefully.

After building systems that handle millions of requests daily, I've watched teams chase cache hit ratios like they're chasing dragons. They optimize for metrics that don't matter while their actual problems fester underneath layers of complexity that caching introduced.

The Cache Invalidation Myth

"There are only two hard things in Computer Science: cache invalidation and naming things." Phil Karlton's famous quote has become gospel, but here's the uncomfortable truth: if cache invalidation is hard, you shouldn't be caching in the first place.

Cache invalidation isn't hard because it's inherently complex. It's hard because you're solving the wrong problem. When you cache data, you're essentially saying "this computation is too expensive, so let's store the result." But instead of making the computation cheaper, you've just added a distributed state management problem on top of your original expensive computation.

I worked on a project where we spent three months debugging inconsistent search results. Users would search for products, add them to cart, then search again and find different results. The culprit? A elaborate caching system with seven different invalidation strategies across four cache layers. We had cache warming, cache aside patterns, write-through caches, and cache hierarchies.

The fix wasn't better cache invalidation. We deleted 80% of the caching logic and optimized the underlying queries. Search response time dropped from 200ms to 50ms, consistency issues vanished, and our deployment complexity halved.

Caching Hides Performance Problems

Caches are performance band-aids. They mask symptoms while the underlying disease spreads.

Your API endpoint takes 2 seconds to respond, so you cache the response. Problem solved, right? Wrong. You've just hidden the fact that your API endpoint is fundamentally broken. That 2-second response time is telling you something important: your data model is wrong, your query is inefficient, or your architecture is flawed.

Caching transforms observable problems into invisible ones. When your cache hit ratio is 99%, nobody investigates why the 1% of cache misses are so slow. But that 1% represents your real performance characteristics. Everything else is an illusion.

The Complexity Explosion

Every cache layer doubles your system's complexity. You now have:

Cache warming strategies
Invalidation patterns
TTL management
Cache stampede protection
Monitoring and alerting for cache health
Backup plans for cache failures
Data consistency guarantees (or lack thereof)

I've seen teams with more cache-related code than business logic. Their systems became archaeology projects where nobody understood which cache invalidated which other cache, and when.

One team I consulted for had a cache dependency graph that looked like a spider web designed by someone on hallucinogens. A single user update triggered invalidation cascades across seventeen different cache keys. Their deployment process included a 40-step cache warming procedure that took three hours.

Cache Stampedes and Thundering Herds

Caches create new failure modes that didn't exist before. Cache stampedes happen when a popular cache key expires and multiple threads simultaneously try to regenerate it. Your database gets hammered by the very traffic the cache was supposed to protect it from.

The solutions? More complexity. Cache locking, probabilistic expiration, background refresh patterns. You're now running a distributed computing research project instead of a web application.

False Economies

Caching feels economical because it reduces database load. But you're trading predictable database costs for unpredictable cache complexity costs.

Database scaling is a solved problem. You can buy more IOPS, add read replicas, or switch to a faster database. The cost is linear and predictable.

Cache scaling is chaos. Redis clustering, data distribution, failover scenarios, cross-region replication. You're building a distributed system that's harder to operate than your original database.

The Alternative: Fix Your Data Layer

Instead of caching, fix the underlying problems:

Optimize your queries. Most slow queries can be fixed with better indexes, query restructuring, or data denormalization. A well-optimized PostgreSQL query can outperform a cache lookup when you factor in serialization overhead.

Design better data models. If you're constantly joining across eight tables, your schema is wrong. Denormalize strategically. Store computed values. Use materialized views.

Use faster databases. Modern databases are incredibly fast. A properly configured PostgreSQL instance can handle 100,000+ queries per second on commodity hardware.

Scale your database properly. Read replicas, connection pooling, and vertical scaling solve most performance problems without introducing cache complexity.

When Caching Makes Sense

I'm not completely anti-cache. Caching works when:

You're caching expensive computations, not database queries
The cached data has clear, predictable invalidation patterns
Cache misses are acceptable (the system works fine without the cache)
You're caching at the edge (CDNs, browser caches)

But in-application caching? The kind where you sprinkle Redis throughout your backend? That's usually a mistake.

The Path Forward

Next time someone suggests adding caching to solve a performance problem, ask these questions instead:

Can we optimize the underlying query? Can we denormalize this data? Can we use a faster database? Can we scale our existing database?

Only after exhausting those options should you consider caching. And if you do cache, keep it simple. No cache hierarchies, no complex invalidation strategies, no distributed cache coordination.

Your future self will thank you when you're not debugging cache consistency issues at 3 AM.

The best cache is the one you don't need.

Your Architecture Diagram Is a Lie and Everyone in the Meeting Knows It

Kirill Tolmachev — Sat, 21 Feb 2026 14:00:00 +0000

Your Architecture Diagram Is a Lie and Everyone in the Meeting Knows It

That pristine diagram on your screen right now? The one with perfectly aligned boxes, clean arrows, and color-coded components that flow like a symphony? It's fiction. Pure, beautiful fiction that everyone in the meeting room is politely pretending represents reality.

I've sat through hundreds of architecture reviews where teams present these masterpieces of wishful thinking. The database always has perfect uptime. The API responses are consistently under 200ms. The error handling is "robust." The security boundaries are clearly defined. Meanwhile, production is on fire, alerts are screaming, and nobody wants to admit that the actual system looks nothing like the art project on the wall.

The Diagram Delusion

Architecture diagrams have become corporate mythology. We create them not to document reality, but to imagine what we wish reality looked like. They're Instagram filters for software systems.

Consider the last system diagram you reviewed. Did it show:

The legacy database that still runs on Oracle 11g because migration is "planned for next quarter"?
The microservice that's actually three services duct-taped together because of that urgent deadline six months ago?
The "temporary" Redis cache that's now critical to system function and nobody knows how to safely remove?
The authentication service that works completely differently in staging than production?

Of course not. Those details are "implementation specifics."

The Real Architecture Lives in Production Logs

Want to see your actual architecture? Don't look at Visio. Look at your error logs.

Your system's true design emerges from the patterns of failure, the bottlenecks that actually matter, and the dependencies that break everything when they hiccup. The database connection pool that maxes out every Tuesday at 2 PM tells you more about your architecture than any diagram ever will.

I worked on a project where our beautiful service mesh diagram showed clean, independent services. Reality? Service A couldn't function without Service B, which was secretly dependent on a shared file system that wasn't documented anywhere. When that file system filled up, half our "microservices" died together like a house of cards.

Why We Keep Drawing Lies

It's not malicious. These diagrams serve a purpose, just not the one we claim.

Architecture diagrams are aspiration documents. They represent the system we're trying to build, or the system we think we're building. They're useful for onboarding new team members who need a mental model to start with. They help us communicate with stakeholders who don't need to know about the Oracle 11g problem.

But we've confused the map with the territory.

The Meeting Room Theater

Here's the script that plays out in every architecture review:

Presenter: "So here's our high-availability setup with automatic failover..."

Everyone else: Thinking about that time the "automatic failover" required manual intervention for four hours

Someone brave: "What about that issue we had last month with the payment service?"

Presenter: "Oh, that's been addressed. Next slide."

Everyone else: Knows it's still an open ticket

This isn't productive. It's theater. We're all pretending the diagram is accurate because calling it out would mean admitting we don't have our act together.

A Better Way Forward

Stop treating architecture diagrams as documentation. Start treating them as design tools.

Here's what actually works:

Before building anything new: Create a diagram that shows your ideal state. Use it to identify potential problems, discuss trade-offs, and align on goals. Then put it away.

For existing systems: Create "as-is" diagrams that show the ugly truth. Include the technical debt, the workarounds, and the actual data flows. Update them when things change, not when things were supposed to change.

For stakeholders: Create simplified views that focus on business capabilities, not technical implementation. They don't need to know about your twelve microservices. They need to know that orders get processed and customers get charged.

For new team members: Give them the aspirational diagram first, then the real one after they've been there two weeks. Context matters.

The Uncomfortable Truth

Your production system is messier, more complex, and more interdependent than any diagram can capture. That's not a failure—that's software development.

The best architects I know don't hide from this complexity. They document it, measure it, and gradually improve it. They create diagrams that serve specific purposes for specific audiences, not universal truth documents that please nobody.

Next time you're in an architecture review, try this: ask how the diagram would change if you included every actual dependency, every shared resource, and every piece of technical debt. Watch the room get uncomfortable.

Then start a real conversation about what you're actually building.

Your Action Items

Tomorrow, do this: take your current architecture diagram and mark every component that doesn't match production reality in red. Everything that's partially accurate gets yellow. Only the truly accurate pieces stay green.

If your diagram is mostly red and yellow, congratulations. You're being honest for the first time in months.

Now you can start building something better.

Senior Developers Don't Write Better Code. They Delete More of It.

Kirill Tolmachev — Fri, 20 Feb 2026 14:00:00 +0000

You think senior developers got where they are by writing elegant algorithms and architecting beautiful systems? Wrong. They got there by becoming ruthless deleters of code. While junior developers are busy adding features and showing off their latest framework knowledge, senior developers are quietly removing thousands of lines that never should have existed in the first place.

I've watched this pattern for over a decade across multiple teams and projects. The developer who gets promoted isn't the one who shipped the most features. It's the one who made the codebase smaller, faster, and more maintainable by systematically eliminating complexity.

The Deletion Paradox

Here's what nobody tells you about career progression: your value as a developer becomes inversely proportional to the amount of code you write.

A junior developer joins the team and immediately starts contributing. They implement new APIs, add validation layers, create utility functions, and build comprehensive test suites. In their first year, they might add 50,000 lines of code to the project. Everyone's impressed.

A senior developer joins the same team. In their first month, they delete 15,000 lines of code. They remove three entire microservices, eliminate two dependency libraries, and consolidate four similar functions into one. The junior developer's code contribution graph shows mountain peaks. The senior's looks like a valley.

Guess which one the company values more?

Why Deletion Beats Creation

Less Code = Fewer Problems

Every line of code is a liability. It can break, needs maintenance, creates dependencies, and must be understood by future developers. I once worked on a project where we reduced a 3,000-line configuration system down to 200 lines. Bug reports dropped by 80%. Performance improved by 40%. The junior developer who originally built it was offended. The users were ecstatic.

Maintenance Costs Are Real

That clever abstraction you built? Someone will spend three days trying to understand it next year. Those eight similar-but-slightly-different functions? Each one is a potential bug waiting to happen when requirements change. The comprehensive error handling that covers every edge case? Most of those cases will never occur, but the code complexity they add will slow down every future developer.

Cognitive Load Is The Real Enemy

Human brains can hold about seven pieces of information in working memory. Your codebase probably has 700,000 pieces of information. Every unnecessary function, every redundant parameter, every "just in case" feature adds cognitive load. Senior developers understand that reducing cognitive load is more valuable than adding functionality.

The Art of Strategic Deletion

Delete Redundant Code First

Look for patterns where the same logic appears multiple times with slight variations. I recently combined twelve different "send notification" functions into one configurable function. Deleted 400 lines, reduced bugs, simplified testing.

Remove Unused Features

That analytics dashboard nobody looks at? Delete it. The API endpoint that only the QA team uses for testing? Delete it. The feature flag that's been enabled for two years? Delete the flag and make the behavior permanent. Unused code isn't just neutral - it's actively harmful because it creates false complexity.

Eliminate Premature Optimizations

Junior developers love to optimize for performance scenarios that never happen. I've seen caching layers for data that changes once per month, complex algorithms to handle loads that peak at 10 requests per minute, and elaborate failover systems for services with 99.99% uptime requirements. Delete the optimization and see if anyone notices. Spoiler: they won't.

Kill Your Darlings (And Your Dependencies)

That elegant helper library you wrote? If it's used in three places, maybe just copy the 20 lines of code instead of maintaining a whole module. That popular npm package that does exactly what you need? If you're only using 5% of its functionality, consider implementing those features directly and dropping the dependency.

Developing Your Deletion Instincts

Start measuring the right metrics. Instead of tracking lines of code written, track lines of code removed. Instead of celebrating new features shipped, celebrate features retired. Instead of asking "how can we add this functionality," ask "how can we avoid adding this functionality."

Practice the 10x rule: every line of code you write will be read 10 times, modified 3 times, and debugged twice. Make sure it's worth it.

Before writing anything new, spend 30 minutes looking for existing code you can delete instead. You'll be surprised how often you can solve the "new" problem by removing old problems.

The Counter-Intuitive Truth

The most productive thing you can do as a developer isn't writing more code. It's writing less code that does more. The fastest way to ship features isn't adding functionality. It's removing the barriers that slow down feature development.

Senior developers understand this instinctively. They've been burned by their own clever code enough times to know that simplicity beats sophistication. They've maintained enough legacy systems to know that every line of code is a commitment to future maintenance.

Next time you're about to implement a new feature, ask yourself: what can I delete instead? Your future self will thank you. Your teammates will thank you. Your users will thank you, even if they never realize why the application suddenly feels faster and more reliable.

The best code is the code that doesn't exist. The best developers are the ones who keep it that way.

99% of Backend Developers Can't Design a System That Handles 1,000 Concurrent Users

Kirill Tolmachev — Thu, 19 Feb 2026 14:00:00 +0000

You think 1,000 concurrent users is easy? Most senior developers I've worked with would fail this challenge spectacularly. They'd reach for microservices, throw Redis at everything, and wonder why their beautifully architected system crumbles under load that a simple PHP script could handle.

The problem isn't lack of knowledge about distributed systems or fancy tools. It's that developers optimize for the wrong metrics and misunderstand what "concurrent" actually means.

The Math They Don't Want You to Know

Here's what kills me: developers obsess over theoretical throughput while ignoring the brutal reality of connection management. A single server can theoretically handle millions of requests per second, but most can't even maintain 1,000 persistent connections without choking.

Why? Because they never learned the difference between concurrent requests and concurrent connections. A user hitting your API doesn't just send one request and disappear. They establish a connection, maybe keep it alive, send multiple requests, wait for responses, handle timeouts.

Real concurrency means 1,000 users all doing this simultaneously. Your server needs to juggle 1,000+ file descriptors, maintain session state, handle network buffers, and still process business logic fast enough that nobody times out.

The Connection Pool Disaster

I've seen developers spend weeks optimizing database queries that run in 2ms, then deploy to production where the connection pool has 10 connections for 1,000 users.

Every user waits in line for database access like it's Black Friday at Best Buy.

Connection pooling isn't just a database concern. Your HTTP client libraries, message queues, cache connections, external API calls - they all need pools sized for your actual concurrency, not your theoretical QPS.

Here's the calculation nobody does:

1,000 concurrent users
Average request takes 200ms end-to-end
Each user makes a request every 2 seconds
You need at least 100 database connections, not 10

Memory: The Silent Killer

Python developers are the worst offenders here, but everyone's guilty. They load entire user objects into memory "for performance," then wonder why their 8GB server dies at 500 concurrent users.

Each connection consumes memory. TCP buffers, application state, framework overhead, garbage collection pressure. A Rails app might use 50MB per worker process. That's 200 concurrent users max before you're swapping to disk.

JavaScript developers aren't innocent either. Node.js handles concurrency beautifully until you start storing user sessions in memory objects. Suddenly your event loop is spending all its time in garbage collection instead of processing requests.

The Monitoring Blind Spot

Most developers monitor the wrong metrics. They watch CPU usage and database query times while their users are timing out due to TCP queue saturation.

The metrics that actually matter for 1,000 concurrent users:

Active connections (not just QPS)
Connection establishment time
Memory per connection
File descriptor usage
Network buffer utilization
Time spent waiting for connections vs processing

I worked on a project where we had sub-10ms API response times but users were still complaining about slowness. The problem? Our load balancer was only opening 100 connections to each backend server. Users were waiting 5 seconds just to get connected.

The Microservices Trap

Junior developers think scaling means splitting everything into microservices. Senior developers should know better, but most don't.

Microservices multiply your concurrent connection problems. Now instead of handling 1,000 user connections, each service needs to handle connections from other services plus users. Your user service talks to auth service, which talks to profile service, which queries the database. One user request becomes 4-6 internal service calls.

Each hop introduces latency, connection overhead, and failure points. Your 1,000 concurrent users become 6,000 concurrent service-to-service connections. Good luck debugging that when it breaks.

What Actually Works

Stop overthinking it. A well-configured monolith on a modern server can handle thousands of concurrent users without breaking a sweat.

Use connection pooling everywhere. Not just databases - HTTP clients, Redis, message queues, everything that opens sockets.

Measure memory per user, not per request. If you can't support 1,000 users on a single server due to memory constraints, fix that before you scale out.

Optimize connection handling, not business logic. Use async I/O frameworks, configure proper timeouts, tune your TCP stack. A slow algorithm running on 1,000 connections beats a fast algorithm that can only handle 100.

Load test with realistic user behavior. Don't just hammer endpoints with curl. Simulate actual user sessions, connection lifecycle, typical request patterns.

The Reality Check

Most "scalable" systems I've audited couldn't handle 100 real concurrent users, let alone 1,000. They're optimized for demo traffic, not production load.

If you can't run ab -n 10000 -c 1000 against your system without errors, you're not ready for production. Fix the fundamentals before you architect for millions of users.

The irony? Once you can handle 1,000 concurrent users properly, scaling to 10,000 or 100,000 becomes straightforward. You just add more servers behind a load balancer.

But until you understand connection management, memory allocation, and realistic concurrency testing, you're just building distributed systems that fail faster.

Docker Is the New jQuery: Everyone Uses It, Nobody Understands It

Kirill Tolmachev — Wed, 18 Feb 2026 14:00:00 +0000

Docker Is the New jQuery: Everyone Uses It, Nobody Understands It

Remember when jQuery was everywhere? Every website, every tutorial, every bootcamp graduate's first instinct was to $() their way through problems. Half the developers using it couldn't explain what the DOM was, but they sure knew how to copy-paste that CDN link. Today, Docker has achieved the same dubious honor.

I've watched teams Dockerize their Hello World applications while running monolithic databases on bare metal. I've seen developers spend three days debugging container networking for a project that could run perfectly fine as a systemd service. We've created a generation of developers who know more about Dockerfile syntax than they do about process management.

The Cargo Cult Problem

Docker isn't inherently bad. Neither was jQuery. Both solved real problems and democratized complex concepts. jQuery made DOM manipulation accessible when browsers were inconsistent nightmares. Docker made deployment consistent when servers were snowflake disasters.

But somewhere along the way, we stopped asking "why" and started assuming "must."

I worked on a project where the team Dockerized a static file server. Not a complex application. Not even a dynamic site. Static HTML files served by nginx. When I asked why we needed containers for this, the response was genuinely puzzled: "How else would you deploy it?"

This is cargo cult programming. Going through the motions without understanding the principles.

When Docker Makes Sense (And When It Doesn't)

Here's what Docker actually solves:

Environment consistency: Your application runs the same way across development, testing, and production. This matters when you have complex dependencies or need specific system libraries.

Resource isolation: Multiple applications can share the same host without stepping on each other. Critical for multi-tenant environments or when you're running untrusted code.

Scaling orchestration: Kubernetes and similar platforms need standardized deployment units. Containers provide that abstraction.

Dependency management: Complex applications with conflicting system requirements become manageable.

Now here's when Docker is overkill:

Single-purpose VMs where you control the entire stack
Applications with simple, standard dependencies
Development environments where you're the only user
Stateful services that need persistent storage and don't benefit from horizontal scaling

The Hidden Costs Nobody Talks About

Every abstraction has overhead. Docker's costs aren't just computational (though that extra layer does impact performance). The real costs are cognitive and operational.

Debugging becomes harder. Your application is now wrapped in multiple layers. Network issues become container networking issues. File system problems become volume mounting problems. Memory leaks become container memory limit problems.

Local development gets complex. Simple port conflicts become Docker port mapping configuration. Environment variables become docker-compose.yml files. Quick code changes become image rebuilds.

Security surface area expands. Now you're responsible for base image vulnerabilities, container runtime security, and registry access controls on top of your application security.

I've seen teams spend more time managing their Docker setup than building features.

What Good Docker Usage Looks Like

The teams that use Docker well share common patterns:

They understand the alternatives. Before containerizing, they can articulate why traditional deployment won't work. They've tried systemd services, configuration management, or platform-specific deployment tools.

They optimize for their actual problems. If they need environment consistency, they focus on that. If they need scaling, they design for horizontal scaling from day one.

They keep it simple. Multi-stage builds are common. Alpine base images unless they need specific libraries. Minimal layers. No installing debugging tools in production images.

They automate ruthlessly. If you're manually running docker commands in production, you're doing it wrong. Everything goes through CI/CD pipelines with proper testing at each stage.

The Path Forward

Here's how to escape the Docker cargo cult:

Start with the problem, not the solution. Before adding Docker to any project, write down the specific problem you're solving. "Everyone uses Docker" isn't a problem statement.

Learn the fundamentals. Understand what containers actually are. Learn about namespaces, cgroups, and union filesystems. Spend time with docker inspect and docker exec to see what's really happening.

Practice alternatives. Try deploying the same application multiple ways. Use systemd services, configuration management tools, or platform-specific deployment. Compare the complexity and maintenance overhead.

Measure everything. Track build times, deployment times, resource usage, and debugging time. Make decisions based on data, not assumptions.

Docker isn't going anywhere. But neither is the need for developers who understand when and why to use it. The industry needs fewer Docker users and more Docker understanders.

Stop copying configuration from Stack Overflow and start understanding what those configurations actually do. Your future self (and your production environment) will thank you.

The next time someone asks why you're using Docker, you should have a better answer than "that's how everyone does it."

The Worst Technical Decision I've Seen Cost $2M. It Started with 'Let's Rewrite It in...'

Kirill Tolmachev — Tue, 17 Feb 2026 14:00:00 +0000

You know that feeling when someone in a meeting says "What if we just rewrote the whole thing?" and everyone nods like it's brilliant? I watched that exact moment destroy a perfectly good business. The system was making money. The customers were happy. Revenue was growing 40% year over year.

Then someone said the magic words: "Let's rewrite it in Go."

Two years and $2.3 million later, they had nothing to show for it except a half-built system, three burned-out teams, and a competitor who ate their lunch while they were busy solving problems that didn't exist.

The Rewrite Disease

Here's what nobody tells you about rewrites: they're almost never about technology. They're about ego.

I worked on a project where the existing Python API handled 50,000 requests per second without breaking a sweat. Sure, the code wasn't pretty. Yes, there were some gnarly bits that made new developers cry. But it worked. It made money. It had been battle-tested by real users doing real things.

The engineering team had different ideas. They wanted to use the hot new language. They wanted clean architecture. They wanted to feel smart again.

How $2M Disappeared

The numbers are brutal when you break them down:

Month 1-3: Planning and "research" (3 senior engineers × $150k salary = $112k)
Month 4-12: Development sprint one, building the "core" (6 engineers × $130k average = $585k)
Month 13-18: Development sprint two, "fixing architecture issues" (8 engineers × $140k average = $630k)
Month 19-24: Panic mode, bringing in consultants (4 consultants × $200/hour × 40 hours/week × 24 weeks = $768k)
Infrastructure costs: New staging environments, monitoring, deployment pipelines ($180k)
Opportunity cost: Features not built on the working system (immeasurable)

The kicker? They never shipped. The rewrite got cancelled when the company ran out of runway.

The Real Problem Wasn't Technical

Every rewrite I've seen fail had the same pattern. Engineers convinced themselves they were solving technical problems, but they were really solving emotional ones.

"The old codebase is messy." Translation: I didn't write it, so I don't understand it.

"We need better performance." Translation: I want to work with shiny tools.

"The architecture is all wrong." Translation: I have opinions about how things should be done.

Here's the uncomfortable truth: your users don't care about your code quality. They care about your features working. They care about bugs getting fixed. They care about new functionality that solves their problems.

When Rewrites Actually Make Sense

I'm not anti-rewrite. I've seen them work. But they work under very specific conditions:

The existing system is genuinely blocking business growth. Not "it's hard to add features" but "we literally cannot serve more customers."

You have a clear migration path with measurable milestones. If you can't break your rewrite into deliverable chunks that provide value, you're building a death star.

The business can afford to get zero new features for 12-18 months minimum. And yes, it will take longer than you think.

You have senior engineers who've done large rewrites before and lived to tell about it.

What To Do Instead

Stop thinking about rewrites. Start thinking about incremental improvements.

I worked with a team that had a "legacy" PHP application serving 100 million page views per month. Instead of rewriting it, they slowly extracted services. They replaced the nastiest parts first. They added proper monitoring. They wrote tests for the scary functions.

Three years later, 60% of the system was new code running on modern infrastructure. The other 40% was the old stuff that just worked and didn't need fixing. Total cost: $400k spread over three years. Zero downtime. Zero missed deadlines. Zero customer complaints.

The Migration Playbook That Actually Works

Start with monitoring. You can't improve what you can't measure.

Identify the true bottlenecks. Not the code that makes you uncomfortable, but the actual problems users experience.

Extract the easiest wins first. Build confidence with small successes.

Celebrate boring improvements. A 50% reduction in database queries beats a complete architecture overhaul.

Keep shipping features on the old system while you improve it. Your competitors won't wait for your rewrite to finish.

The Uncomfortable Reality

Most rewrite decisions happen because engineers are bored. They want to work on greenfield projects. They want to use new technologies. They want to build something they can put on their resume.

These are valid human needs. But they're not business needs.

If you want to experiment with new technologies, build side projects. Create internal tools. Contribute to open source. Don't bet the company's future on your learning journey.

Your Action Plan

Next time someone suggests a rewrite, ask these questions:

What specific business problem are we solving? "Code quality" is not a business problem.

How will we measure success? If you can't quantify the benefit, you shouldn't do the work.

What's our rollback plan? If things go sideways, how do we get back to serving customers?

Can we solve this problem incrementally? Usually the answer is yes, but it requires more discipline than starting over.

Who's going to maintain the old system while we build the new one? Spoiler alert: the same people building the new system.

The most expensive technical decision isn't the wrong technology choice. It's the decision to throw away working code and start over. Save your company the $2 million lesson. Fix what you have. Your future self (and your bank account) will thank you.

AI Already Won. Programmers Still Have Jobs. Nobody Can Explain Why.

Kirill Tolmachev — Mon, 16 Feb 2026 14:00:00 +0000

The tech world has made up its mind: AI will replace programmers. And you know what? They're mostly right. The traditional programmer — the person whose job is to translate business requirements into code — is genuinely at risk.

But here's the plot twist nobody's talking about: the software industry itself has never been safer. Not because AI can't build software. But because the people who need software are too lazy to use AI to build it themselves.

Yes, Programmers Are in Danger. Let's Not Pretend Otherwise.

Let's not sugarcoat this: AI is coming for a significant chunk of programming jobs. The junior developer who writes CRUD endpoints? AI does that faster and cheaper. The mid-level dev who implements well-defined features from Jira tickets? AI is getting dangerously close.

The writing is on the wall, and the developers who refuse to read it will be the first casualties.

But there's a critical distinction the doomsayers miss: AI replacing programmers is not the same as AI replacing the need for software services. These are two entirely different claims, and conflating them is where the narrative goes off the rails.

The $10 Problem

Here's a thought experiment. You're a small business owner. You need a landing page. Nothing fancy — a hero section, a signup form, maybe some testimonials. In 2026, you have two options:

Option A: Open Claude/GPT/Cursor, describe what you want, iterate on the output, validate the HTML, check responsiveness, fix the three things it got wrong, figure out hosting, deploy it yourself.

Option B: Go to Fiverr, pay someone $10-50, get it back tomorrow, done.

Most people pick Option B. Not because they're stupid. Not because they can't use AI. But because Option B requires zero cognitive effort after the initial click.

This is the uncomfortable truth the "AI democratizes everything" crowd doesn't want to hear. The bottleneck was never access to tools. It was always willingness to use them.

The Cognitive Tax of "Free"

There's a hidden assumption in every "AI will let everyone build software" argument: that people want to build software themselves. They don't. They never did.

WordPress "democratized" web development in 2004. Twenty-two years later, there are more web developers than ever, and most small businesses still pay someone to set up their WordPress site. Squarespace, Wix, and every no-code tool in existence proved the same thing: lowering the barrier to entry doesn't eliminate demand for professionals. It creates a new category of people who know the barrier is low and still don't want to cross it.

AI is the same story with better marketing.

Using AI effectively requires:

Knowing what to ask for — You need a mental model of the solution before you can prompt for it
Evaluating the output — Can you tell if the generated code has a security vulnerability? A performance bottleneck? A subtle logic error?
Iterating intelligently — When the first result isn't right, you need to know what's wrong and how to fix it
Integration and deployment — The AI gives you code. You still need to put it somewhere, connect it to your systems, and maintain it

Each of these steps is a tax on your attention. And attention is the scarcest resource in 2026 — not compute, not API credits, not talent. Attention.

The Paradox of Capability

As AI tools become more capable, the gap between "possible" and "actually happens" widens, not narrows.

2020: "Can AI write code?" → Barely
2023: "Can AI write code?" → Yes, simple things
2025: "Can AI write code?" → Yes, even complex things
2026: "Does everyone build their own software now?" → No. Absolutely not.

Why? Because capability was never the bottleneck. Willingness was.

Think about cooking. YouTube has millions of free tutorials. Gordon Ramsay will teach you beef Wellington for free. The ingredients are at your local grocery store. Yet the restaurant industry is worth $1 trillion. UberEats, DoorDash, and Glovo aren't thriving because people can't cook. They're thriving because people won't cook.

Cooking	AI-Assisted Dev
Watch tutorial	Write prompt
Buy ingredients	Set up environment
Follow recipe	Iterate on output
Taste and adjust	Test and debug
Clean up	Deploy and maintain

Each step is individually easy. Together, they represent a commitment most people would rather outsource.

Two Things Can Be True at Once

Most takes on this topic pick a side. Either "AI will replace all programmers" or "programmers are safe." The reality is messier and more interesting:

1. AI will absolutely displace many programmers. The ones writing boilerplate, implementing standard patterns, doing predictable work. This is already happening.

2. The demand for software products and services will not decrease. If anything, it will increase. As AI makes development cheaper, more people and businesses will want custom software. But they still won't want to build it themselves.

The result? The industry transforms, but doesn't shrink. The nature of the work changes. The people doing it might look different. But someone is still getting paid to turn "I need a thing" into a working product.

The Laziness Economy

"Laziness" isn't a moral judgment here. It's an economic force. Perhaps the most powerful one.

Every successful consumer product in history has been a laziness product:

Cars: Walking is free, but...
Washing machines: You could wash by hand, but...
Calculators: You could do math on paper, but...
Uber: You could drive yourself, but...
DoorDash: You could cook, but...
AI coding tools: You could build it yourself, but...

Each technology did displace workers. Cars displaced carriage drivers. Washing machines displaced washerwomen. But they also created entirely new service economies. Mechanics. Delivery drivers.

AI will do the same. The question isn't "will programmers survive?" — many won't, at least not in their current form. The question is: "What new service economy will emerge around the people who are too lazy to use AI themselves?"

And the answer is already forming: a massive market of people who operate AI on your behalf, validate the results for you, handle the deployment, and charge you a reasonable fee for the privilege of not having to think about it.

Who Actually Wins?

Winner #1: Senior developers who become AI-amplified. A senior dev with Cursor isn't being replaced — they're doing 5x the work. They handle the architecture, the edge cases, the things AI still gets wrong. They're more valuable than ever.

Winner #2: "AI-native" service providers. A new class of professional: people who are excellent at prompting, validating, and deploying AI-generated solutions. Not traditional developers, not "prompt engineers" — translators between human intent and machine output.

Winner #3: Platform builders. The real money isn't in generating code — it's in wrapping AI in products that eliminate cognitive load. Vercel's v0, Bolt, Lovable — these aren't AI tools. They're convenience products. The user never writes a prompt. They click buttons.

The losers? Junior and mid-level developers who don't adapt. And, ironically, the "everyone can code now" narrative — which promised democratization but delivered a new layer of abstraction most people are happy to pay someone else to navigate.

What This Means for Developers

Don't be complacent. The "they can't replace me" attitude is dangerous. They can replace parts of what you do, and that's enough to restructure the industry.
Move up the stack. The surviving roles are the ones AI can't easily replicate: system design, complex debugging, understanding business context, managing ambiguity.
Learn to wield AI, not compete with it. The developers who thrive will use AI for the boring parts while they focus on the genuinely hard problems.
Consider the service layer. There's a growing market for "I'll handle the AI part for you." It's not glamorous, but it's recession-proof.

The Bottom Line

AI will transform software development. It already has. Many programming jobs will disappear. This is real, and pretending otherwise is irresponsible.

But the demand for software? The need for someone to turn vague ideas into working products? The willingness of people to pay $10, $100, or $10,000 rather than figure it out themselves?

That's eternal.

Because the most human-proof force in existence isn't artificial intelligence. It's the deeply human tendency to pay for convenience even when the DIY option is trivially easy.

Programmers might be in danger. The software industry isn't. And the gap between those two statements is where the next trillion-dollar economy lives.

Database Indexes Explained Like You're 5

Kirill Tolmachev — Sat, 14 Feb 2026 14:00:00 +0000

Imagine you walk into a library with ten thousand books, and you need to find one specific title. You have two options: start at the first shelf and check every single spine until you find it, or walk over to the catalog system, look up the title, and get the exact shelf and position in seconds.

A database index works exactly like that catalog. It's a separate data structure that helps your database find rows without scanning the entire table. And once you understand how indexes work, you'll know why some queries take 2 milliseconds and others take 20 seconds — even on the same table.

The SQL examples in this article use PostgreSQL, but the concepts apply equally to MySQL, SQL Server, SQLite, and pretty much any relational database you'll encounter.

The phone book you never asked for

Here's another way to think about it. A phone book is sorted alphabetically by last name. If you need to find "Martinez," you can flip to the M section and get there quickly. That's an index at work — the data is organized in a way that makes lookup fast.

But what if someone asks you to find everyone in the phone book with the phone number 555-0142? Now you're stuck reading every single entry, because the book isn't sorted by phone number. There's no shortcut.

That's what happens inside your database when you run a query against a column that has no index.

What happens without an index: the sequential scan

Let's say you have a users table with a million rows, and you run this:

SELECT * FROM users WHERE email = 'ada@example.com';

Without an index on the email column, PostgreSQL has to perform a sequential scan — it reads every row in the table, checks whether email matches, and moves on. For a million rows, that's a million comparisons. You can see this happening with EXPLAIN:

EXPLAIN SELECT * FROM users WHERE email = 'ada@example.com';

Seq Scan on users  (cost=0.00..20834.00 rows=1 width=72)
  Filter: (email = 'ada@example.com'::text)

That Seq Scan label is telling you the database is walking through the entire table. For small tables this is fine — maybe even faster than using an index. But once your table grows, sequential scans become a real bottleneck.

B-tree indexes: the workhorse

When you create an index in most databases, you're getting a B-tree index by default. B-tree stands for "balanced tree," and you can picture it like a decision tree that narrows down where your data lives.

Think of it this way: imagine a dictionary. You don't start at page one and read every word. You know that "M" words are roughly in the middle, so you open there. Then you narrow it down — "Ma" words, then "Mar," then "Martinez." Each step cuts out a huge chunk of the remaining pages.

A B-tree works similarly. It organizes values in a sorted, tree-like structure where each level of the tree narrows the search space dramatically. Finding a value in a million-row table might only require checking 20 or so nodes in the tree, instead of scanning all million rows.

Creating one is straightforward:

CREATE INDEX idx_users_email ON users (email);

Now run that same query again:

EXPLAIN SELECT * FROM users WHERE email = 'ada@example.com';

Index Scan using idx_users_email on users  (cost=0.42..8.44 rows=1 width=72)
  Index Cond: (email = 'ada@example.com'::text)

The cost dropped from ~20,834 to ~8. Instead of scanning the whole table, PostgreSQL jumped straight to the right spot via the index. That's the kind of difference that turns a 3-second API response into a 10-millisecond one.

Composite indexes: column order matters more than you think

Sometimes your queries filter on more than one column. Say you're looking up orders by customer and status:

SELECT * FROM orders
WHERE customer_id = 42 AND status = 'shipped';

You could create two separate indexes — one on customer_id and one on status — but a composite index covering both columns is usually more efficient:

CREATE INDEX idx_orders_customer_status ON orders (customer_id, status);

Here's the thing that trips people up: the order of columns in a composite index matters a lot. Think of it like a phone book sorted by last name, then first name. You can quickly look up everyone named "Martinez," and within those, you can find "Sofia Martinez" easily. But you can't efficiently search for everyone named "Sofia" regardless of last name — the book isn't organized that way.

The same logic applies to composite indexes. The index above works great for:

WHERE customer_id = 42 (uses the index — it's the leading column)
WHERE customer_id = 42 AND status = 'shipped' (uses both columns)

But it won't help much with:

WHERE status = 'shipped' (the leading column is customer_id, so the index can't narrow things down)

The rule of thumb is: put the column you filter on most often (or the most selective one) first.

When indexes hurt instead of help

Indexes aren't free. Every index you add comes with trade-offs, and understanding them keeps you from making your database slower while trying to make it faster.

Write overhead is the big one. Every time you INSERT, UPDATE, or DELETE a row, the database has to update not just the table but every index on that table too. If you have ten indexes on a table that gets thousands of writes per second, those index updates add up fast. Your reads get quicker, but your writes get slower.

Storage is the other cost. An index is a real data structure sitting on disk, and for large tables, indexes can take up significant space — sometimes as much as the table itself.

So indexes are a trade-off: faster reads in exchange for slower writes and more disk usage. For a table that gets read a thousand times for every write, indexes are almost always worth it. For a high-write logging table that rarely gets queried, you might want to keep indexes minimal.

Covering indexes: skipping the table entirely

Normally, when PostgreSQL uses an index to find matching rows, it still has to go back to the actual table to fetch the full row data. The index told it where the row is, but it still needs to read the row itself. This is sometimes called a "table lookup" or "heap fetch."

A covering index is one that contains all the columns your query needs, so the database never has to visit the table at all. It gets everything it needs directly from the index.

For example, suppose you frequently run this:

SELECT email, created_at FROM users WHERE email = 'ada@example.com';

If you create an index that includes both columns:

CREATE INDEX idx_users_email_created ON users (email, created_at);

PostgreSQL can answer the query entirely from the index — it finds the email in the B-tree and the created_at value is right there alongside it. You'll see this show up as an "Index Only Scan" in EXPLAIN:

Index Only Scan using idx_users_email_created on users  (cost=0.42..4.44 rows=1 width=40)
  Index Cond: (email = 'ada@example.com'::text)

That "Index Only Scan" means zero table lookups, which is about as fast as it gets. This technique is particularly useful for queries that run thousands of times per minute, where shaving off even a small amount of I/O adds up.

Common mistakes (and how to avoid them)

Indexing every column. More indexes doesn't mean faster. Each one costs write performance and storage. Be intentional — index columns that actually appear in your WHERE clauses, JOIN conditions, and ORDER BY clauses.

Forgetting to index columns you filter and join on. This is the flip side. If you have a query that joins orders to customers on customer_id, and there's no index on orders.customer_id, that join is doing a sequential scan every time. Check your slow queries and see what columns they're filtering on.

Wrong column order in composite indexes. As we covered above, an index on (status, customer_id) won't help a query that only filters on customer_id. Think about which queries will actually use the index, and put the most commonly filtered or most selective column first.

Never looking at EXPLAIN. You don't have to guess whether an index is being used — the database will tell you. Get comfortable running EXPLAIN (or EXPLAIN ANALYZE for actual execution times) on your slow queries. It takes ten seconds and saves hours of guessing.

EXPLAIN ANALYZE
SELECT * FROM orders WHERE customer_id = 42 AND status = 'shipped';

This gives you the query plan and the actual execution time, so you can see exactly what changed after adding an index.

Rules of thumb

When you're deciding whether to add an index, these guidelines will serve you well in the vast majority of cases:

Always index foreign keys. If a column is used in JOIN conditions, it should probably have an index. Some databases do this automatically; PostgreSQL does not.
Index columns in your WHERE clause — especially on large tables where you're selecting a small percentage of rows.
Think about selectivity. An index on a boolean column with two possible values rarely helps, because the database still has to read half the table. An index on email (where every value is unique) is extremely effective.
Fewer, smarter indexes beat more indexes. One well-designed composite index can serve multiple queries. Three separate single-column indexes often can't.
Monitor before and after. Use EXPLAIN ANALYZE to verify that your new index actually improves the query. Sometimes the optimizer ignores it, and you've added write overhead for nothing.
Don't forget partial indexes. In PostgreSQL, you can index only a subset of rows: CREATE INDEX idx_active_users ON users (email) WHERE active = true; — smaller index, faster lookups, lower overhead.

Where to go from here

If you've been writing queries without thinking about indexes, now's a great time to open up your slowest endpoint, run EXPLAIN ANALYZE on its main query, and see what the database is actually doing. You might find a sequential scan on a table with millions of rows, and a single CREATE INDEX statement could cut your response time by 99%.

Indexes are one of those concepts where a little knowledge goes a long way. You don't need to be a DBA to get this right — you just need to understand the trade-offs and pay attention to your query plans. Start with your slowest queries, add indexes where they make sense, and measure the difference.

Got a query that's been bugging you? Drop it in the comments — let's figure out if an index can fix it.