[{"data":1,"prerenderedAt":349},["ShallowReactive",2],{"navigation":3,"/blog/experience-is-earned-not-downloaded":141,"/blog/experience-is-earned-not-downloaded-surround":338},[4,36,55,80,101,116,128],{"title":5,"path":6,"stem":7,"children":8,"icon":35},"ASP.NET Core","/aspnet-core","1.aspnet-core/1.index",[9,11,15,19,23,27,31],{"title":10,"path":6,"stem":7},"Cursor Pagination",{"title":12,"path":13,"stem":14},"Dapper - Micro ORM","/aspnet-core/dapper","1.aspnet-core/2.dapper",{"title":16,"path":17,"stem":18},"DbUp - Database Migrations","/aspnet-core/dbup","1.aspnet-core/3.dbup",{"title":20,"path":21,"stem":22},"Serilog - Structured Logging for .NET","/aspnet-core/serilog","1.aspnet-core/4.serilog",{"title":24,"path":25,"stem":26},"Class Inheritance in C#","/aspnet-core/inheritance","1.aspnet-core/5.inheritance",{"title":28,"path":29,"stem":30},"C# Collections","/aspnet-core/collections","1.aspnet-core/6.collections",{"title":32,"path":33,"stem":34},".NET gitignore Command","/aspnet-core/gitignore","1.aspnet-core/7.gitignore",false,{"title":37,"path":38,"stem":39,"children":40,"icon":35},"Oauth2.0 and OpenIdConnect","/oauth2andopenidconnect","10.oauth2andopenidconnect/1.index",[41,43,47,51],{"title":42,"path":38,"stem":39},"RFC 6749 - OAuth 2.0 Authorization Framework",{"title":44,"path":45,"stem":46},"Authentication (AuthN) vs Authorization (AuthZ)","/oauth2andopenidconnect/authnandauthz","10.oauth2andopenidconnect/2.authnandauthz",{"title":48,"path":49,"stem":50},"TOTP Authentication","/oauth2andopenidconnect/totp","10.oauth2andopenidconnect/3.totp",{"title":52,"path":53,"stem":54},"OAuth 2.0 Resource Indicators - RFC 8707","/oauth2andopenidconnect/oauth2resourceindicators","10.oauth2andopenidconnect/4.OAuth2ResourceIndicators",{"title":56,"path":57,"stem":58,"children":59,"page":35},"Azure","/azure","2.azure",[60,64,68,72,76],{"title":61,"path":62,"stem":63},"Azure Cost Management","/azure/azuremanagementandgovernance","2.azure/1.Azuremanagementandgovernance",{"title":65,"path":66,"stem":67},"Azure Policy","/azure/azurepolicy","2.azure/2.azurepolicy",{"title":69,"path":70,"stem":71},"Code Blocks","/azure/code-blocks","2.azure/3.code-blocks",{"title":73,"path":74,"stem":75},"Prose Components","/azure/prose-components","2.azure/4.prose-components",{"title":77,"path":78,"stem":79},"Images and Embeds","/azure/images-embeds","2.azure/5.images-embeds",{"title":81,"path":82,"stem":83,"children":84,"page":35},"Git","/git","3.git",[85,89,93,97],{"title":86,"path":87,"stem":88},"Git Rebase","/git/git-rebase","3.git/1.git-rebase",{"title":90,"path":91,"stem":92},"Git Stash","/git/git-stash","3.git/2.git-stash",{"title":94,"path":95,"stem":96},"SemVer","/git/semver","3.git/3.semver",{"title":98,"path":99,"stem":100},"Conventional Commits","/git/conventional-commits","3.git/4.conventional-commits",{"title":102,"path":103,"stem":104,"children":105,"icon":35},"Design Patterns","/design-patterns","7.design-patterns/1.index",[106,108,112],{"title":107,"path":103,"stem":104},"Introduction",{"title":109,"path":110,"stem":111},"Installation","/design-patterns/installation","7.design-patterns/2.installation",{"title":113,"path":114,"stem":115},"Usage","/design-patterns/usage","7.design-patterns/3.usage",{"title":117,"path":118,"stem":119,"children":120,"icon":35},"Software Principles","/principles","8.principles/1.index",[121,122,125],{"title":107,"path":118,"stem":119},{"title":109,"path":123,"stem":124},"/principles/installation","8.principles/2.installation",{"title":113,"path":126,"stem":127},"/principles/usage","8.principles/3.usage",{"title":129,"path":130,"stem":131,"children":132,"icon":35},"Software Architecture","/architecture","9.architecture/1.index",[133,135,138],{"title":134,"path":130,"stem":131},"CQRS Pattern",{"title":109,"path":136,"stem":137},"/architecture/installation","9.architecture/2.installation",{"title":113,"path":139,"stem":140},"/architecture/usage","9.architecture/3.usage",{"id":142,"title":143,"body":144,"date":328,"description":329,"extension":330,"featured":35,"meta":331,"navigation":332,"path":333,"readTime":334,"seo":335,"stem":336,"tag":117,"__hash__":337},"blog/blog/12.experience-is-earned-not-downloaded.md","Experience Is Earned, Not Downloaded",{"type":145,"value":146,"toc":315},"minimark",[147,156,161,172,176,179,192,196,205,209,230,234,237,241,244,248,251,254,258],[148,149,150,151,155],"p",{},"Credentials, tutorials, bootcamps, and even AI are accelerators for learning — they compress the time it takes to encounter an idea, and that's genuinely valuable. What none of them are is a substitute for hands-on experience operating real systems under real constraints. That distinction sounds obvious stated plainly. It gets lost constantly in practice, because consuming enough content about a topic ",[152,153,154],"em",{},"feels"," a lot like acquiring the judgment that topic actually requires, right up until reality tests the difference.",[157,158,160],"h2",{"id":159},"knowledge-is-not-experience","Knowledge Is Not Experience",[148,162,163,164,171],{},"Courses, bootcamps, documentation, conference talks, AI-assisted learning — all of it has real value, and none of it can replicate what gets learned from operating a system real people actually depend on. Reading about distributed systems and operating one under load are different activities that happen to share vocabulary. Understanding the OAuth spec and being the person responsible when authentication starts failing for a fraction of live traffic are different skills wearing the same name. The lessons that come from production failures, debugging under real pressure, and living with the operational cost of an architectural decision made two years ago aren't lessons a document can fully transmit, because they're not primarily propositional knowledge — they're closer to what philosopher Michael Polanyi called ",[165,166,170],"a",{"href":167,"rel":168},"https://plato.stanford.edu/entries/tacit-knowledge/",[169],"nofollow","tacit knowledge",": the kind of understanding that's genuinely hard to make fully explicit, built through doing rather than through being told.",[157,173,175],{"id":174},"writing-software-is-easy-owning-software-is-hard","Writing Software Is Easy. Owning Software Is Hard.",[148,177,178],{},"Plenty of developers have integrated an API, built a CRUD app, deployed a website, wrapped a third-party SDK. Those are real, useful skills — and they're also a small slice of what engineering actually involves. The harder questions start after deployment: how does this behave under load nobody tested for, how does it recover from a partial failure, how do you migrate millions of live records without downtime, how do you rotate a secret without breaking every service depending on the old one, how does someone three years from now — who wasn't in the room for any of these decisions — support what got built. Software isn't finished when it works. It's finished when it keeps working, under conditions its author never got to choose.",[148,180,181,182,187,188,191],{},"This is also where the difference between stages of expertise becomes visible in a very concrete way. The ",[165,183,186],{"href":184,"rel":185},"https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition",[169],"Dreyfus Model of Skill Acquisition"," — developed by Stuart and Hubert Dreyfus and later expanded in their book ",[152,189,190],{},"Mind Over Machine"," — describes skill development as a progression through distinct stages, from novices who need explicit rules to follow, through competence, to experts whose decisions increasingly come from pattern recognition and situational judgment rather than conscious rule-application. A novice engineer asks \"how do I build this.\" An expert asks \"what happens when this fails\" or \"who maintains this after I'm gone\" — not because they're smarter, but because they've accumulated enough situations where the first question turned out to be the wrong one to be asking alone.",[157,193,195],{"id":194},"integrating-an-api-is-not-the-same-as-building-a-platform","Integrating an API Is Not the Same as Building a Platform",[148,197,198,199,204],{},"Calling a third-party API is the easy part. A payment integration, to take a concrete example, is not really about the HTTP request — it's about retries that don't double-charge a customer (a problem real payment APIs solve with ",[165,200,203],{"href":201,"rel":202},"https://docs.stripe.com/api/idempotent_requests",[169],"idempotency keys"," precisely because \"just retry on failure\" isn't safe by default), reconciliation when two systems' records disagree, fraud signals, observability into failures that happen downstream of your own code, and the operational support structure for when something breaks at 2 a.m. The wrapper around the API is often the least interesting part of the system. Everything experience actually teaches lives in the parts around it.",[157,206,208],{"id":207},"every-production-incident-is-a-teacher-if-the-culture-lets-it-be","Every Production Incident Is a Teacher, If the Culture Lets It Be",[148,210,211,212,217,218,223,224,229],{},"This is where experience actually gets encoded into an organization rather than just an individual's memory, and it's worth being specific about how, because \"years on the job\" and \"expertise\" aren't automatically the same thing. Psychologist K. Anders Ericsson's research on ",[165,213,216],{"href":214,"rel":215},"https://psycnet.apa.org/record/1993-40718-001",[169],"deliberate practice"," found that raw years of repetition don't reliably build expertise on their own — what does is practice with clear feedback on what went wrong and a real chance to correct it next time. A production incident is exactly that kind of feedback, if the organization's culture actually lets the lesson land. In 2012, then-Etsy CTO John Allspaw published ",[165,219,222],{"href":220,"rel":221},"https://www.sherlocks.ai/blog/blameless-postmortems-explained-lessons-from-real-outages",[169],"\"Blameless PostMortems and a Just Culture,\""," arguing — building on aviation and safety research by Sidney Dekker — that when organizations respond to failure by looking for someone to blame, they get less information out of the incident, not more, because the engineers closest to what happened have every incentive to minimize their own account of it. Google's ",[165,225,228],{"href":226,"rel":227},"https://sre.google/books/",[169],"Site Reliability Engineering"," practice later formalized the same idea as a core part of its incident process, not an optional cultural nicety layered on top of the \"real\" engineering work. The mechanism matters as much as the sentiment: a postmortem culture that actually extracts the lesson from a failure requires engineers to describe, in full and afraid of nothing, exactly what they saw, assumed, and did — and that's not achievable through reading about the incident afterward. It requires having been the person making decisions in real time, with incomplete information, while the system was actively breaking. That's precisely the kind of judgment no course simulates, because a course, by design, doesn't have real consequences attached to being wrong.",[157,231,233],{"id":232},"titles-and-experience-are-different-things","Titles and Experience Are Different Things",[148,235,236],{},"Degrees and certifications open doors and demonstrate commitment — there's nothing wrong with either. But they're not evidence of the same thing engineering experience is evidence of. Organizations routinely buy software from vendors whose teams spent years solving deeply specialized problems, and those products weren't built because someone in the room had the strongest academic credential. They were built through iteration: design, implementation, production support, and the accumulated scar tissue of things that didn't work the first time. Academic environments optimize for theory, correctness, and formal reasoning; industry optimizes for reliability, delivery, and what happens when a customer is affected by a decision made under deadline pressure. Both perspectives are genuinely valuable. Neither substitutes for the other, and the strongest engineers tend to keep drawing on both rather than treating one as having superseded the need for the other.",[157,238,240],{"id":239},"ai-shortens-the-path-to-knowledge-it-doesnt-shorten-the-path-to-wisdom","AI Shortens the Path to Knowledge. It Doesn't Shorten the Path to Wisdom.",[148,242,243],{},"AI can explain a concept, generate code, and review an implementation faster than almost any other tool available today, and that's a real, meaningful acceleration of the learning curve. What it can't do is transfer the specific memory of diagnosing an outage that was actually affecting real customers while the clock was running — the instinct that comes from having seen a version of this exact failure mode before and knowing, viscerally rather than theoretically, where to look first. The gap here isn't a knowledge gap AI will eventually close by getting better. It's a category difference: AI compresses the time it takes to encounter an idea. It has no mechanism for compressing the years it takes to develop judgment about which ideas actually hold up once reality gets involved.",[157,245,247],{"id":246},"the-takeaway","The Takeaway",[148,249,250],{},"Education gives engineers vocabulary. Experience gives engineers judgment. Neither one, on its own, is the whole discipline. The goal was never to dismiss academic study or to romanticize experience as though credentials don't matter at all — it's to recognize that the engineers who actually get trusted with ambiguous, high-stakes problems are the ones who've studied, built, broken things, and had to live with the consequences long enough that the next production incident teaches them something a book never could have. That process doesn't have a shortcut. It just has accelerators — and an accelerator is only useful once there's an actual journey underneath it to speed up.",[252,253],"hr",{},[157,255,257],{"id":256},"references-and-further-reading","References and Further Reading",[259,260,261,270,277,285,295,307],"ul",{},[262,263,264,265,269],"li",{},"Stanford Encyclopedia of Philosophy, ",[165,266,268],{"href":167,"rel":267},[169],"\"Tacit Knowledge\""," — on Michael Polanyi's concept of knowledge that resists full explicit articulation and is built through doing.",[262,271,272,273,276],{},"Wikipedia, ",[165,274,186],{"href":184,"rel":275},[169]," — the five-stage framework describing how expertise develops from rule-following toward situational, pattern-based judgment.",[262,278,279,280,284],{},"Sherlocks.ai, ",[165,281,283],{"href":220,"rel":282},[169],"\"Blameless Postmortems Explained: Lessons From Real Outages\""," — the history and mechanics of John Allspaw's blameless postmortem practice, originating at Etsy and later adopted industry-wide.",[262,286,287,288,294],{},"Google, ",[165,289,291],{"href":226,"rel":290},[169],[152,292,293],{},"Site Reliability Engineering: How Google Runs Production Systems"," — the book formalizing blameless postmortems and other operational practices as core engineering discipline, not just an operations afterthought.",[262,296,297,298,302,303,306],{},"K. Anders Ericsson, Ralf Th. Krampe, and Clemens Tesch-Römer, ",[165,299,301],{"href":214,"rel":300},[169],"\"The Role of Deliberate Practice in the Acquisition of Expert Performance\""," (",[152,304,305],{},"Psychological Review",", 1993) — the foundational research distinguishing mere years of repetition from the kind of deliberate, feedback-driven practice that actually builds expertise.",[262,308,309,310,314],{},"Stripe, ",[165,311,313],{"href":201,"rel":312},[169],"\"Idempotent Requests\""," — a concrete, widely referenced example of the operational complexity — retries without double-processing — that sits behind a \"simple\" payment API call.",{"title":316,"searchDepth":317,"depth":318,"links":319},"",1,2,[320,321,322,323,324,325,326,327],{"id":159,"depth":318,"text":160},{"id":174,"depth":318,"text":175},{"id":194,"depth":318,"text":195},{"id":207,"depth":318,"text":208},{"id":232,"depth":318,"text":233},{"id":239,"depth":318,"text":240},{"id":246,"depth":318,"text":247},{"id":256,"depth":318,"text":257},"2026-08-05","Credentials, tutorials, and AI compress the time it takes to encounter an idea. None of them shorten the years it takes to develop judgment about which ideas actually hold up once reality gets involved.","md",{},true,"/blog/experience-is-earned-not-downloaded","8 min",{"title":143,"description":329},"blog/12.experience-is-earned-not-downloaded","IsHONLsk9y55YskZ2-aif5tlZ1OLpCU_Ew_yPsG2BmI",[339,344],{"title":340,"path":341,"stem":342,"description":343,"children":-1},"There Is No SI Unit for Software Engineering","/blog/no-si-unit-for-software-engineering","blog/11.no-si-unit-for-software-engineering","No formula outputs the correct architecture, and no checklist guarantees good software. What exists instead is a long list of trade-offs made under constraints nobody judging the decision later can fully see.",{"title":345,"path":346,"stem":347,"description":348,"children":-1},"Why Writing Engineering Blogs Is Hard","/blog/why-writing-engineering-blogs-is-hard","blog/13.why-writing-engineering-blogs-is-hard","Everything here is a report from where I'm standing, not an argument built to relocate you there. If you land somewhere different after actually thinking it through, that's not a miss — that's the point.",1785744836529]