the api does not care about your phd

one of the more depressing things i’ve learned from working in security is that being right is sometimes the least important part of being right.

computers are simple in that sense. if something is vulnerable, you reproduce it. show me the poc. show me the curl. show me the packet. if i can hit the endpoint and make the system do something it was never supposed to do, the argument is basically over.

institutions are not like that.

i joke about boomers a lot, but age itself isn’t really the problem. i’ve met older engineers with terrifying amounts of practical knowledge and young people who are basically walking certification dumps. the problem is what happens when seniority, hierarchy and ego start substituting for actual technical capability.

in india we have a pretty good word for this culture: babudom. originally it describes the bureaucratic obsession with hierarchy, files, permissions, titles and procedure. put that inside a technical institution and you get something worse: designation starts carrying more weight than evidence.

i’ve felt this directly.

sometimes you walk into a room thinking you’re going to discuss a vulnerability and slowly realise the vulnerability isn’t what people are upset about.

they’re upset that some 19 year old discord boypup without a phd found it in a system administered by people with decades of seniority.

someone around me once summarized it almost perfectly: people are egoistic. they think, how can an eighteen or nineteen year old be giving us gyan?

that explains an uncomfortable amount.

because suddenly nobody wants to talk about whether the authentication is broken. now we’re discussing who found it, who authorized what, whose department owns the server, who should have been informed first, whether somebody senior feels disrespected and whether the person holding the proof has accumulated enough years of institutional status to be allowed to have discovered it.

the curl still works.

the exploit still works.

the data is still accessible.

none of the politics changed the fucking system.

security makes this kind of ego especially embarrassing because software does not care who you are. the api does not know you’re a professor. the authorization middleware does not check your h-index. a broken access-control check does not become secure because somebody with a phd says the architecture is sound.

reality is extremely rude like that.

if your model says something is impossible and my poc does it anyway, your model is wrong.

and this is where theoretical knowledge can become a trap when people stop touching real systems.

someone can know computer science deeply and still have no practical intuition for modern oauth flows, cloud permissions, javascript-heavy applications, weird framework defaults, mobile backends or the thousand implementation mistakes where security actually falls apart.

that’s fine. nobody knows everything.

what isn’t fine is turning “i don’t know this” into “you cannot possibly know this.”

theory matters enormously. i read papers, specifications and documentation constantly. but theory without contact with reality calcifies fast. security moves too quickly for somebody to stop touching systems for ten years and assume their seniority will keep their understanding current.

years passing is not years learning.

nikhil mason has a post called close your eyes to solve bugs¹ that gets at something i really like about practical engineering. after enough time actually building and breaking things, you carry mental models of systems around in your head. one tiny inconsistency starts bothering you before you can completely explain why. you follow it. three hours later you understand the entire trust boundary and where it fails.

you don’t get that from memorizing terminology.

you get it from touching the thing until it becomes instinct.

research on expertise says a much more polite version of this too. organizations routinely use years of experience as a proxy for expertise even though actual expertise depends much more on continued practice, feedback and learning². organizational research also shows that hierarchy affects whose knowledge is treated as legitimate in the first place³.

that’s basically babudom’s worst contribution to technical work.

it turns “who understands the system?” into “who is allowed to be right?”

the senior people i actually respect don’t behave like this. if you show them something weird, they become curious. they ask you to reproduce it. they attack the evidence instead of attacking the person presenting it.

if you’re wrong, they’ll tear the poc apart and explain exactly why.

good.

if you’re right, they update.

also good.

that’s what actual technical confidence looks like.

security cannot work in a culture where finding a vulnerability is treated as humiliating the person responsible for the system. if every critical bug turns into an ego crisis, researchers eventually learn not to report things. if disagreement with somebody senior becomes “disrespect”, younger engineers learn to shut the fuck up and nod⁴.

then everyone gets to preserve their hierarchy until an attacker who does not care about any of it finds the same bug.

i’ve found that part genuinely exhausting because i actually love this work. i like understanding systems. i like breaking assumptions. i like finding some tiny thing everybody ignored and following it until the entire system starts making sense.

i did not get into security because i wanted to participate in somebody else’s status game after proving their system was vulnerable.

maybe learning to deal with people like that is part of becoming better professionally. fine.

but i hope i never become senior enough that somebody younger finding something i missed feels like an insult.

if some 19 year old discord boypup without a phd breaks something i administer, i don’t want to hear his designation.

show me the poc.

if the curl works, we have a fucking bug to fix.

Footnotes

1. nikhil mason, close your eyes to solve bugs. ↩

2. denise m. rousseau & jeroen stouten, experts and expertise in organizations: an integrative review on individual expertise, annual review of organizational psychology and organizational behavior, 2025. ↩

3. pedro monteiro, generating, grading, and ghosting: how organizing experts shapes expertise, journal of management studies, 2025. ↩

4. amy c. edmondson, psychological safety and learning behavior in work teams, administrative science quarterly, 1999. ↩