The Dunning-Kruger effect,
at work.

scroll, or press space ↓

i. Context

Where this happened

I worked at Illumify for the past 9 months, a US company that builds ERP (Enterprise Resource Planning) software for cannabis businesses. Inventory, orders, production, accounting, all of it.

By a few months in, I'd shipped a handful of things. Tote container management. Buyer menus. Custom menu configuration. Unit tests across a handful of modules. All of them went well. I felt like I was getting a handle on the system.

Then I got handed the option of working on Production Orders and Tasks. Three connected things: a recipe, a production order, and the tasks generated from it. Looked like CRUD plus orchestration. A few weeks of work, I figured.

ii. The Failure

Where this went wrong

The estimate I gave for this was off by something like 3x. About a month of work turned into closer to three. The forecasting team, who needed my Production Order API ready before they could start their own work, ended up sitting on a dependency for way longer than I'd promised them.

Promised~4 weeks
Actual~12 weeks
BlockedForecasting team integration

I'd committed to that timeline before I'd done the work to know what I was committing to. Decided I could mostly figure it out alone, leaning on my colleagues as little as possible.

It got finished and handed off to QA. The forecasting team integrated and built on top of it. Just months later than I'd promised.

iii. What I Missed

What it actually touched

While I was feeling confident this would only take a few weeks, here's what production planning ended up touching once I started building.

Recipe versioningEffective-date windows, current version vs history
Persona proficiencySkill levels, efficiency multipliers
Machine capacityBay assignments, availability windows
SOPs & signingDocument versions, sign-off requirements
Work Center capabilitiesMapping personas + machines to WCs
Work Center calendarsDaily availability, holidays, shift coverage
Resource availability detectionMatching what's needed against what's free
Routing across Work CentersMulti-step operations flowing across WCs
Capacity planningRequired-vs-available minutes, overload detection
Finite schedulingDate-by-date load balancing of operations
CRP orchestrationThe whole Capacity Requirements Planning pipeline
Resource conflict resolutionDetection + reschedule options when things collide
Material requirements nettingRequired materials against on-hand inventory
BOM explosionRecursive sub-recipes, nested material needs
Lead time integrationVendor + internal lead times feeding planning
Time UoM handlingMinutes vs hours vs shifts across the system
TaskTemplate enrichmentPer-step instruction sheets, SKU fallback
Step-level cost trackingLabor, machine, material costs per step
Lab testing requirementsRequired tests, sample routing, results gating
Package generationOutputs becoming inventory packages
COGS routingCost-of-goods flowing through the order
METRC complianceState tracking, external audit syncs

None of this was in the brief. Each one was something I had to learn about, design around, or straight up build from scratch.

iv. The Pattern

What was actually happening

There's a well-known pattern for the way I was operating. It's called the Dunning-Kruger effect.

High Low Confidence Peak of "Mount Stupid" Valley of Despair Slope of Enlightenment Plateau of Sustainability

The earlier wins had pushed me up the confidence curve faster than my actual understanding of the system had grown. I was sitting at the peak of Mount Stupid, confident I had it, without seeing the drop coming.

v. The Lesson

What changed about how I work

For features in complex domains, I now do a lot more upfront before I write any code. I push back on the brief and ask the designer questions until I actually get the why, not just the what.

I look at how things are already being used in the real system. I sit with QA and ask what edge cases they normally run into. I lean on the people who've been there longest for every piece of context they're willing to share.

It takes time up front. But that time tends to be the cheapest part of the whole feature.

vi. The Confidence

Where this leaves me

I'd rather look uninformed for a few days than miss an estimate by months.