ronutz

The Roles · Who makes it

Network software engineer

Written from published sources

The engineer who writes the operating system a network runs on. It is software engineering shaped by an unusual set of constraints: the code runs unattended for years on equipment nobody can reach, an upgrade is a maintenance window somebody negotiated weeks earlier, and a defect is discovered by a stranger at three in the morning. The architecture of the platform decides how much of that pressure reaches any individual change.

What the day looks like

  • Writing and reviewing code against a protocol specification that other implementations also read, and read differently.
  • Working within the platform's architecture, which sets the terms: a shared address space makes one defect everybody's outage, and a state store makes a process restartable.
  • Testing against hardware, against scale, and against the interoperability cases that only appear when another vendor is on the far end.
  • Taking a reproduced defect from third-line support and finding what in the code produced it.
  • Deciding which release carries a fix, which is a conversation about risk rather than about code.

What it answers for

  • Code that behaves correctly at scale and under the failure conditions the platform promises to survive.
  • Interoperability with implementations written by other people from the same specification.
  • The fix arriving in a release, on a schedule support and customers were told about.

What it is measured on

  • Defect escape rate, which is what customers experience as quality.
  • Delivery against the release train, which moves for the whole portfolio rather than for one feature.
  • Test coverage and the results of the regression suite.

Who it receives from

Third-line product support
Reproduced defects with the evidence attached, which is the difference between a fix and an investigation.
Product management
Requirements, priorities, and the customers behind them.
Standards bodies and specifications
The behaviour the code has to agree with.

Who it serves

Every engineer running the release
Software that behaves as documented, including when something fails.
Support, at every tier
Fixes, workarounds and the source-level explanation behind them.
The platform's own architecture
Changes that respect the constraints the design was built to give.

Who else has a stake

  • The customers whose networks carry the release, most of whom will never report anything.
  • Support organisations worldwide, whose case volume is downstream of this code.
  • Other vendors, whose implementations have to interoperate with this one.

What it takes

  • Systems programming, and the discipline that comes from code running where nobody can attach a debugger.
  • Reading specifications closely, since interoperability is agreement about ambiguity.
  • Comfort with a release cadence measured in months and a support lifetime measured in years.
  • The judgement to weigh a fix against the risk of shipping it, which is a decision about other people's networks.

What the job turns on

The architecture decides how expensive a mistake is, and the architecture was chosen long before the current engineer arrived. On a platform where every process shares one address space, a defect in one feature reaches everything, so caution is the only available safety mechanism. On a platform where a process can be restarted from a state store, the same defect is contained, and engineering effort moves from avoiding faults to recovering from them. Understanding which platform you are writing for is therefore the first thing to learn about the job.

The published sources

Where it leads

Roles that lead here

The work itself

The Practice covers how this work is done — triage, escalation, evidence, handover — across the whole corpus.

Read The Practice