You've probably never thought about why every hospital, factory, and control room built between 1944 and 1980 looked the same. Beth Mathews' piece "Why So Many Control Rooms Were Seafoam Green" answers that question - and the answer has more to say about developer tooling than it might appear.
The short version: a self-taught color theorist named Faber Birren spent the 1930s selling corporations on the idea that color choices in the workplace had measurable effects on performance, fatigue, and accident rates. He eventually landed DuPont as a client. DuPont built the Manhattan Project facilities. The color coding system Birren developed with DuPont became mandatory US industrial standard in 1948 and is still internationally recognized.
The specific shade - light green on walls, something like #93B5A0 - wasn't aesthetic. It was functional. Birren's research identified it as the optimal background for reducing visual fatigue in high-attention environments where a mistake could be catastrophic.
Developers spend more continuous hours staring at screens than almost any other profession. The color and contrast choices in their tools - IDEs, terminals, monitoring dashboards, log viewers - have the same cognitive stakes Birren was solving for in 1944, just translated to screens instead of painted concrete. The "reduce eye strain" toggle in your editor settings isn't a modern UX consideration; it's the tail end of an 80-year-old empirical research program - and probably a pale imitation of what that research actually prescribed. Hospital green isn't cool, after all.
Mathews' article is aimed at designers, not developers, but the underlying framework - color as a functional system constraint, not decoration - is exactly the right way to think about any interface where people do sustained, high-concentration work.
Worth reading, and worth thinking about the next time you're picking a theme.