198 lines
9.4 KiB
HTML
198 lines
9.4 KiB
HTML
<!doctype html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8" />
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
|
<title>Infrastructure — Samantha Vero Friis</title>
|
|
<link
|
|
href="https://fonts.googleapis.com/css2?family=DM+Mono:wght@300;400;500&family=Syne:wght@400;700;800&display=swap"
|
|
rel="stylesheet"
|
|
/>
|
|
<link rel="stylesheet" href="styles.css" />
|
|
</head>
|
|
<body>
|
|
<div class="container">
|
|
<header>
|
|
<a href="/" class="back">← back</a>
|
|
<p class="tag">// opinion</p>
|
|
<h1>Convenience<br />Is Making Us<br /><span>Worse</span></h1>
|
|
<div class="byline">
|
|
<span>Samantha Vero Friis</span>
|
|
<span>—</span>
|
|
<span>Computer Infrastructure</span>
|
|
</div>
|
|
</header>
|
|
|
|
<article>
|
|
<p class="lead">
|
|
The tools a company chooses to build on top of says a lot
|
|
about how serious it is about the craft. The industry-wide
|
|
drift toward Word, Teams, and Microsoft 365 is not a
|
|
productivity upgrade — it is a slow erosion of competence
|
|
dressed up as convenience.
|
|
</p>
|
|
|
|
<h2>The Convenience Trap</h2>
|
|
|
|
<p>
|
|
Every tool that hides complexity from you takes something
|
|
away. When a new hire can open a laptop running Windows,
|
|
install Office in ten minutes, and be "operational" by noon,
|
|
that feels like a win. But operational is not the same as
|
|
capable. What that person has actually learned is how to
|
|
navigate a UI. They have not learned how their machine
|
|
works, how their data flows, or how to adapt when the
|
|
abstraction breaks.
|
|
</p>
|
|
|
|
<p>
|
|
Large vendor ecosystems like Microsoft 365 are engineered
|
|
for the lowest common denominator. They are excellent at
|
|
onboarding someone with no background — and they stop there.
|
|
The ceiling is built in by design. You cannot meaningfully
|
|
extend Word. You cannot script Teams in any serious way. You
|
|
are a tenant inside someone else's system, paying monthly
|
|
for the privilege of not understanding what is happening
|
|
underneath you.
|
|
</p>
|
|
|
|
<blockquote>
|
|
Convenience optimizes for the speed of the
|
|
<span>newcomer</span>.<br />
|
|
It does not care about the ceiling of the
|
|
<span>expert</span>.
|
|
</blockquote>
|
|
|
|
<h2>What We Trade Away</h2>
|
|
|
|
<p>
|
|
The deeper issue is what gets lost over time. A team that
|
|
has never had to configure anything has never had to
|
|
understand anything. When your document pipeline is Word
|
|
plus SharePoint, you never learn what a proper typesetting
|
|
system looks like. When your servers are Azure with a
|
|
click-through UI, you never develop intuition for
|
|
networking, permissions, or failure modes. The knowledge
|
|
simply does not accumulate.
|
|
</p>
|
|
|
|
<p>
|
|
The companies most dependent on big vendor stacks also tend
|
|
to be the most fragile. A license change, a price increase,
|
|
a deprecated feature — and suddenly nobody knows what to do.
|
|
There is no internal knowledge to fall back on. The stack
|
|
was always a rented abstraction.
|
|
</p>
|
|
|
|
<div class="compare">
|
|
<div class="compare-col bad">
|
|
<h3>Vendor-Locked Stack</h3>
|
|
<ul>
|
|
<li>Fast to start, hard to master</li>
|
|
<li>Knowledge lives in the UI, not the team</li>
|
|
<li>Expensive at scale, locked by contracts</li>
|
|
<li>No meaningful customization</li>
|
|
<li>Fragile when the vendor changes terms</li>
|
|
<li>Homogeneous — everyone works the same way</li>
|
|
</ul>
|
|
</div>
|
|
<div class="compare-col good">
|
|
<h3>Custom Infrastructure</h3>
|
|
<ul>
|
|
<li>Slower to start, no ceiling</li>
|
|
<li>Knowledge compounds inside the team</li>
|
|
<li>Cheap at scale, you own what you build</li>
|
|
<li>Configured precisely for your workflow</li>
|
|
<li>Resilient — you understand every layer</li>
|
|
<li>Personal — the environment fits the person</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<h2>Linux as a Philosophy</h2>
|
|
|
|
<p>
|
|
A Linux desktop is not just a different operating system. It
|
|
is a different relationship with your machine. You configure
|
|
your window manager, your keybindings, your terminal, your
|
|
dotfiles. The environment becomes an extension of how you
|
|
think. Two engineers on the same team can have entirely
|
|
different setups that are both optimized for their own
|
|
cognitive style — and that is a feature, not a problem.
|
|
</p>
|
|
|
|
<p>
|
|
This is not about being difficult or contrarian. It is about
|
|
the fact that a person who has spent time configuring
|
|
<code>neovim</code>, managing a
|
|
<code>systemd</code> service, or writing their own shell
|
|
scripts has fundamentally more understanding of computation
|
|
than someone who has spent the same time clicking through
|
|
GUIs. That understanding compounds. It transfers across
|
|
every problem they touch.
|
|
</p>
|
|
|
|
<h2>Documents Should Be Code</h2>
|
|
|
|
<p>
|
|
The same logic applies to document production. Word
|
|
processing is a GUI wrapped around formatting decisions you
|
|
did not make. The output is inconsistent, the versioning is
|
|
painful, and the result is never quite right. A typesetting
|
|
system like <code>Typst</code> treats a document as source
|
|
code — deterministic, version-controlled, composable. You
|
|
write a template once and it is correct everywhere, forever.
|
|
The document becomes a reproducible artifact.
|
|
</p>
|
|
|
|
<p>
|
|
Custom pipelines like this require an upfront investment.
|
|
You have to learn the tool, build the template, establish
|
|
the workflow. But once built, the leverage is enormous.
|
|
Reports, invoices, analysis documents — all generated
|
|
cleanly from structured data, with zero manual formatting.
|
|
That is not possible in Word. It is not even imaginable in
|
|
Word.
|
|
</p>
|
|
|
|
<h2>Own Your Servers</h2>
|
|
|
|
<p>
|
|
Self-hosted infrastructure demands that someone in your
|
|
organization understands it. That is not a burden — it is
|
|
the point. When you run your own services, you know exactly
|
|
where your data lives, what it costs to run, and what
|
|
happens when something fails. You build operational
|
|
knowledge that no managed cloud service can give you.
|
|
</p>
|
|
|
|
<p>
|
|
This does not mean rejecting cloud entirely. It means being
|
|
intentional. Use the cloud where the economics clearly favor
|
|
it. Build and operate everything else yourself. The goal is
|
|
a team that could reconstruct its own stack from scratch if
|
|
it had to — because a team capable of that is a team that
|
|
actually understands what it has built.
|
|
</p>
|
|
|
|
<hr />
|
|
|
|
<p>
|
|
The best infrastructure is not the most convenient. It is
|
|
the most understood. Tools that demand something from you —
|
|
configuration, learning, patience — are the tools that make
|
|
you better over time. Convenience is a ceiling. Complexity,
|
|
embraced deliberately, is a floor that keeps getting higher.
|
|
</p>
|
|
</article>
|
|
|
|
<footer>
|
|
<a href="mailto:contact@samantha42.xyz"
|
|
>contact@samantha42.xyz</a
|
|
>
|
|
<p class="footer-copy">© 2026 — All rights reserved</p>
|
|
</footer>
|
|
</div>
|
|
</body>
|
|
</html>
|