Hacker and Physicist - A Tale of "Common Sense"

I'm what you might call a "Stone Age" programmer. Not because I code with rocks and sticks, but because my toolkit is filled with ancient relics like LISP and OCaml - functional programming languages that are about as popular in today's enterprise world as flip phones at a tech conference.

I spent three glorious years in the industry writing functional code, and let me tell you, it was like being a minimalist artist in a world of reality TV. Those languages taught me to appreciate the elegance of software craftsmanship, much like Paul Graham describes in "Hackers and Painters." Graham's comparison between hackers and painters - both creating something from nothing, both obsessing over beauty that most people will never notice - still resonates with me today.

But here's the plot twist: my day job isn't painting digital masterpieces in LISP. I've been working in InfoSec since 2007, and for the past two years, I've been a security architect at a multinational company, dealing with compliance and security architecture. In the China market, this is basically a luxury job - like being a food critic in a town that only has fast food. Most local companies would rather spend money on anything else before investing in proper security compliance.

This job has given me a front-row seat to the cutting edge of enterprise security, which I'm grateful for. But it's also created a weird kind of cognitive dissonance that reminds me of my college dreams of becoming the next Einstein.

You see, my first degree was in Optical Information Science and Technology - basically, I wanted to be a physicist. My second degree was Computer Science. Physics seeks the fundamental laws of the universe. Information security, it turns out, deals with the fundamental laws of the digital world - and the uncomfortable reality that most people prefer to pretend these laws don't exist.

The Great Certificate Mystery

Let me tell you about the moment that perfectly captured this absurdity.

I'm sitting in a routine security review meeting, watching my colleague ask what seemed like the most basic question in the world: "Are the certificates on these IoT devices centrally managed?"

The Technical Project Manager (TPM) looked confused. He turned to the device vendor for answers.

The response that came back was so pure, so innocent, it almost broke my brain: "We've never heard of certificates. What's a certificate?"

Now, if you work in security, this is like asking a physicist "What's gravity?" But the TPM found me afterward, genuinely seeking help, and we had this conversation:

Me: "Your IoT devices don't have any certificates?"

TPM: "What are certificates? They say no."

Me: "Okay... How do the Android clients authenticate with your backend servers?"

TPM: "They use tokens."

Me: "What protocol? HTTP?"

TPM: "No, HTTPS. The domain is some-internal-domain-name."

And there it was - like spotting a conservation law in chaotic data.

Me: "That IS centrally managed certificates! If your devices don't trust any root certificates, how could they possibly establish HTTPS connections? The first step of HTTPS handshake is verifying the server certificate's validity!"

TPM: "How should I know?"

That last line? Chef's kiss. Pure poetry.

I ended up spending the next hour explaining everything from Public Key Infrastructure (PKI) to Elliptic Curve Cryptography (ECC), from symmetric encryption to AES-256-GCM. I felt less like a security architect and more like a missionary spreading the gospel of digital hygiene.

The Pattern of Abstraction Amnesia

You might think this was a one-off, but friend, this is my daily life. Here are some greatest hits:

Encryption at Rest and in Transist: Developers think HTTPS solves everything, completely forgetting that highly sensitive data needs protection when it's sitting on disk. And on the other hand, I've actually had vendors suggest using AES256 to encrypt request packets sent over plain HTTP as their "encryption in transist solution." I didn't know whether to laugh or cry.

mTLS (Mutual TLS): Everyone's heard of TLS, but mention mTLS and you get blank stares. In a zero-trust world, services need to verify each other's identity, not just clients trusting servers. It's like having a bouncer who checks your ID but never asks what you're doing there.

OAuth Flows: Plenty of developers can configure OAuth, but ask them to explain the difference between Authorization Code Flow and Implicit Flow, or why one is more secure than the other? Crickets.

Key Management Systems (KMS): They know to put secrets in KMS, but envelope encryption? Key rotation? Why we don't just hardcode passwords in config files? I've seen more hardcoded passwords in production than I care to remember.

These concepts are like Newton's Laws of the digital world - fundamental principles that everything else builds upon. But to your average Spring Boot developer, they might as well be rocket science.

The Physicist's Dilemma

Here's how I explain this to fellow security professionals: Imagine you're a physics student, and someone asks you:

"Why do GPS satellites need relativistic corrections to keep accurate time?"

Any physics student knows the answer: According to General Relativity, time moves faster in weaker gravitational fields (satellites are farther from Earth's gravity). According to Special Relativity, time moves slower for objects moving at high speeds (satellites orbit fast). Combined, satellite clocks run about 38 microseconds fast per day. Without corrections, GPS accuracy would drift by 11 kilometers daily, making the system useless.

This is basic physics. GPS literally wouldn't work without Einstein's theories.

But ask a random person on the street, and you'll get: "I'm just trying to get to Starbucks by Google map, why do I need to know rocket science?"

Sound familiar?

When I tell developers that HTTPS requires certificates, that data needs encryption at rest, that services should use mutual authentication - I get the same response: "I'm just a code monkey moving business logic around. Why do I need to know this security stuff?"

The Abstraction Trap

Now, I'm not blaming developers. Modern software engineering is built on abstraction layers, and that's actually amazing! We've gone from assembly language to high-level frameworks, from bare metal to cloud-native platforms. A developer can slap a @RestController annotation on a Java class and magically have an HTTPS endpoint without knowing anything about TLS handshakes or certificate chains.

This is progress! We've trained thousands of developers to build impressive applications quickly. But we've also created a generation of architects who can build beautiful buildings without knowing how foundations work.

It's the blessing and curse of specialization. We've optimized for speed and efficiency, but sometimes lost sight of the fundamentals that make everything possible.

So What Do We Do?

For Security Professionals (us): Stop being gatekeepers and start being enablers. Put down the "How do you not know this?" attitude and pick up the "Let me explain why this matters" approach. Our job isn't just finding problems - it's reducing the security entropy of our entire organization. Think of yourself as a physics teacher, not a physics textbook.

For Developers and TPMs: Stay curious! The world of code extends far beyond CRUD operations. Understanding the principles behind your tools is like a painter understanding color theory - it makes you better at your craft. Security isn't "someone else's problem" - it's part of building quality software.

For Leaders: Invest in education and culture. Create environments where people can ask "stupid" questions safely. Recognize that compliance isn't about checking boxes - it's about understanding risks and building defensive thinking into your team's DNA.

Looking Up at the Digital Stars

From the elegant recursion of LISP to the profound insights of physics, to the rigorous discipline of information security - I believe the most powerful systems come from deep understanding of fundamental principles.

Maybe we should all occasionally pause our daily code-shipping routines and look up at the "digital stars" that make our connected world possible. After all, whether you're calculating the orbit of a satellite or securing an API endpoint, you're working with the same fundamental forces that govern our universe.

The laws of physics don't care if you understand them - GPS works because engineers do. Similarly, the laws of information security don't care if you understand them - but your applications will be much safer if you do.

And who knows? You might even find it as beautiful as I find a perfectly crafted function in LISP - elegant, essential, and surprisingly profound.

P.S. - Yes, I really did have a vendor suggest AES256-over-HTTP as a "security solution." No, I'm not making this up. Yes, I still have nightmares about it.