new sub page paradigm
This commit is contained in:
samantha42
@@ -0,0 +1,197 @@
|
||||
<!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="/static/style/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:me@samantha42.xyz"
|
||||
>me@samantha42.xyz</a
|
||||
>
|
||||
<p class="footer-copy">© 2026 — All rights reserved</p>
|
||||
</footer>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
Reference in New Issue
Block a user