The Software Engineer Manifesto

My Domain

I have been a software engineer for 15 years, nearly all of them in live streaming. Ive helped the industry grow from raw UDO/IP streams to RealMedia, RTMP, HLS, Dash, and beyond. I've built custom pipelines faster than LL-HLS or WebRTC. I can debug broken GOPs and b-frames, provide a writeup on the trade-off between UDP vs. SRT, and gives you a rundown of the quirks of aging encoders.

This is my specialization. This is my domain.

The Expectation

And yet, I'm, not just asked to build live streaming software. I am asked to write front-ends, back-ends, subtitle parsers, bizarre captions transformers, media transcoders - and to do it in outdated languages written by the ghosts of 2006.

Worse: I'm expected to explain how copper vs. fiber causes packet loss on a client's internal network that I don't even have access to.

It doesn't stop there. I'm judged by my peers on how well I can explain operating system kernels, compiler theory, database internals, mutexes and LeetCode trick questions I'll never use in practice.

The expectation society has placed on me is clear:

I must know how to use my tools; I must know how to rebuild them from scratch.

The Double Standard

But compare this with any other field:

• A composer isn't expected to know how DACs reconstruct waveforms.
• A neurosurgeon isn't expected to know motor design specs for their drills.
• A painter isn't expected to know the molecular makeup of pigment.

Yet I am expected to build abstractions while simultaneously being able to team them down to the atoms.

This is ridiculous.

The Myth of Total Knowledge

This expectation comes form history. Early programmers had to understand the entire stack, from punch cards to printouts. The limitations of early computers made deep knowledge a survival skill. But that survival story has been mythologized into today's impossible standard.

The truth is: nobody knows it all anymore. We specialize. That's the point.

• A composer can be brilliant without Baroque counterpoint.
• A pop producer doesn't need djent polyrhythms,
• A jazz pianist doesn't need 12-tone serialization.

So why are software engineers expected to master Java Factories, void pointers, database index tuning, and CPU cache alignment - on top of everything else?

The Cost of Context Switching

The price of this expectation is context switching. One day I'm deep diving in an encoding pipeline, writing front-ends and back-ends to automate ingest and scrub processes. The next, I'm expected to drop everything and re-architect a NestJS back-end with zero documentation because I should "just read the code."

These are different worlds. Each complex enough to build a career on. Expecting one person to master them all isn't just unrealistic - it's toxic.

The Call

Our industry needs to stop worshiping the Myth of Total Knowledge.

We are not walking encyclopedias. We are not LeetCode machines. We are engineers who solve real-world problems, deliver business value, and scale systems that people actually use.

• We should celebrate our specializations, not dismiss them.
• We should value outcomes, not trivia.
• We should respect the layers of abstraction that make modern computing possible.

The Declaration

I am not a walking encyclopedia of the entire compute stack.

Nobody is.

I am an engineer. A software engineer.

I build things.

Specific things.

And that is enough.