Experienced developers are expensive, while green ones are cheap, at least in comparison. So what exactly are you paying for when you hire someone with several years under their belt? Experience takes a lot of forms, but here I’ll cover one specific case: Optimism vs Realism. Green developers tend to be too optimistic, and only with sufficient experience do they move into a more pragmatic, realistic worldview.
For example, take the seemingly easy task of keeping two systems in sync. This is a common thing that comes up, like if you want to run an e-commerce system where the credit card charging uses an external service (ie. Stripe) but you want to keep a record in your main system of each transaction. Now you’re faced with the problem of reconciling the two systems.
At first glance, it’s a pretty simple problem with a simple solution. When a sale occurs, Stripe sends a webhook to your service, you catch it, and save a record of it. Total transaction value is a sum of all these transactions. It will match exactly with Stripe’s total transaction value. An inexperienced developer would say, “We can have it done in 2 days.” They’re approaching things with the optimistic, best-case view of how the system will function.
An experienced developer might ask, “So, how bad is it if the numbers are different?” This developer knows that the problem isn’t nearly as easy as it sounds. Keeping two systems in sync over the long term is not simple at all. Isn’t it easy to just catch and record a number? True, but in the long run, things always go wrong. Here’s a quick list of events that could push the two systems out of sync:
- Someone does a refund in the Stripe dashboard, and the system is not designed to expect refunds from there.
- A developer deploys a bug with the webhooks so they are received but not saved correctly. It takes a day to track it down, and all those orders in the meantime have been incorrectly saved.
- A customer disputes a charge, and Stripe pulls that money back and assesses a fee (called a “chargeback“). Even when systems handle refunds correctly, they often forget about chargebacks.
Once the systems are out of sync, they stay that way without intervention. Maybe you manually reconcile them somehow. Maybe you write a script to update all the existing orders. Maybe you update the code to handle chargebacks correctly. My point is that keeping two systems exactly in sync takes a lot of work and is an ongoing process. It seems like it should be easy, but after years of experience I’ve learned that it’s quite tough.
The key is that the inexperienced developer sees it as an easy problem and approaches it optimistically. Inexperienced developers as a group live in an optimistic world where there are no partial refunds, chargebacks never occur, and every webhook is caught and handled correctly. They build systems that are too naive, too optimistic, and these systems fall apart when they live in the real world for any length of time.
Optimism has its place, but it’s not always a positive thing. In the hands of an inexperienced developer, optimism will lead to a system that runs for a while, then falls over at the first hint of a breeze. A healthy dose of realism leads to a robust system able to withstand the hurricane winds of the real world. That level of realism only comes with experience, and that experience comes with a higher price tag.
