DEV Community: Simon Briggs

How Small Frictions Destroy Your Workday

Simon Briggs — Tue, 01 Sep 2026 06:13:58 +0000

You sit down with a clear plan. Fix the bug, ship the feature, review two pull requests. Six hours later, none of it is done. Nothing dramatic happened. No outage, no emergency meeting, no impossible ticket. Just a slow leak of minutes through a hundred small cracks.

This is the part of software engineering that rarely gets discussed. We talk about burnout, deadlines, and technical debt, but the real daily thief is smaller and quieter: friction. Not the big blockers you escalate in standup, but the tiny ones you don't even notice until the day is gone.

What Counts as a Small Friction

A small friction is any minor obstacle that interrupts your flow or adds unnecessary steps to a task that should be simple. Individually, each one costs seconds or a couple of minutes. The problem is volume, not size. A developer can hit dozens of these in a single day, and the cumulative cost is what actually wrecks productivity.

Here are the ones that show up most often.

1. Slow Build and Test Cycles

Waiting 90 seconds for a build to finish doesn't sound like much. But if you rebuild 40 times a day, that's an hour gone, and it's not idle time you can use productively because it's just long enough to break concentration and short enough to not start something else. You end up checking Slack, and now you're context-switched for the next fifteen minutes.

2. Environment Setup Drift

"Works on my machine" is a joke because it's true so often. A missing environment variable, a stale Docker image, a dependency that updated silently. These aren't hard problems, but they steal time you didn't budget for, and they show up at the worst moments, right before a demo or a release.

3. Notification Overload

Every Slack ping, every email, every calendar reminder asks for a decision: respond now or later. Each of these micro-decisions costs attention, and attention doesn't reset instantly. Research on task-switching consistently shows that returning to deep work after an interruption takes meaningfully longer than the interruption itself.

4. Unclear Tickets and Requirements

A ticket that says "fix the login bug" without steps to reproduce, without context, without acceptance criteria, forces you to become a detective before you can become a developer. The friction here isn't the coding, it's the archaeology.

5. Tab and Tool Sprawl

Twelve browser tabs, three terminal windows, a half-finished search in Stack Overflow, a Jira board you forgot to close. Every extra open surface is a small cognitive tax. Your brain tracks all of it even when you're not looking at it directly.

6. Meetings With No Clear Purpose

A 30-minute meeting that could have been a message doesn't just cost 30 minutes. It costs the ramp-down before it and the ramp-up after it, because deep technical work doesn't resume instantly after a context switch.

7. Manual, Repetitive Tasks

Copy-pasting the same commands, manually formatting code, renaming files one by one, checking the same dashboard every hour. None of these require skill, but they all require attention, and attention is the actual scarce resource in a developer's day, not time.

8. Poor Documentation

When the internal docs are outdated or missing, developers default to asking a teammate or digging through old commits. Multiply this across a team, and you get a constant low hum of interruptions going both directions.

Why These Add Up Faster Than You Think

The dangerous part of small friction is that it's individually forgivable. No single interruption feels worth fixing. But cognitive science backs up what most developers feel intuitively: task-switching has a real cost, often estimated in double digits of minutes to fully regain deep focus. If you're hit with fifteen small interruptions in a day, you may never actually reach deep focus at all. You spend the whole day in the shallow end.

This is why some developers report feeling exhausted despite writing very little code on a given day. The fatigue isn't from hard problems. It's from constant low-grade context switching that never lets the brain settle into a productive rhythm.

What Actually Helps

There's no single fix, because friction comes from many small sources. But a few habits consistently reduce the damage:

Batch your interruptions. Check Slack and email at set intervals instead of continuously. This alone can reclaim a significant chunk of the day.

Invest in your local dev environment. Faster builds, better linting, reliable containers. These feel like "nice to have" until you calculate how many times a day you hit them.

Push for clearer tickets. A five-minute conversation with a product manager to clarify a vague ticket saves far more than five minutes of confused debugging later.

Protect blocks of uninterrupted time. Even two hours of guaranteed focus time, communicated clearly to your team, changes what's possible in a day.

Automate the repetitive stuff. If you do something manually more than three times, it's probably worth a script, a snippet, or a tool.

Close what you don't need. Fewer open tabs and windows isn't about tidiness; it's about reducing the number of things your brain has to track.

The Bigger Point

None of these frictions are dramatic enough to complain about individually. That's exactly why they survive. Teams fix outages and missed deadlines because those are visible. Small friction stays invisible, which means it never gets fixed unless someone deliberately looks for it.

The best developer days aren't the ones with the fewest hard problems. They're the ones with the fewest interruptions. Removing friction isn't about working harder or longer, it's about protecting the conditions your brain actually needs to do good work.

Next time a day feels unproductive despite being busy, don't look for the one big blocker. Look for the twenty small ones.

The Tools We Use Every Day Without Thinking About Them

Simon Briggs — Mon, 31 Aug 2026 06:19:27 +0000

Every developer has a mental toolbox that runs quietly in the background of their workday. We open a terminal, switch branches, format a file, or convert a document without giving it a second thought. These small, repeated actions rarely make it into architecture discussions or conference talks, but they shape how productive a day actually feels.

This post is a look at the tools that fall into that category: the ones we rely on so often that we forget they are tools at all. Along the way, I will also touch on a less glamorous but surprisingly common task, moving data out of PDFs, and where a browser-based converter fits into that workflow.

Why "boring" tools matter more than we admit

When people talk about developer tooling, the conversation usually gravitates toward frameworks, IDEs, or the latest build system. But a lot of daily friction has nothing to do with code. It comes from small gaps: a file in the wrong format, a missing environment variable, an untracked change, a broken link in documentation.

The tools that solve these small gaps do not get much attention, but they save far more time in aggregate than most people realize. A five-second task done fifteen times a day adds up to real hours over a month. That is the real argument for paying attention to your daily toolkit instead of treating it as an afterthought.

With that in mind, here are five tools that quietly do a lot of heavy lifting for most developers, followed by a note on a task that sits just outside the usual dev toolbox but still shows up often enough to matter.

1. Git, used properly

Git is not a novel pick, but most developers only use a fraction of what it offers. Beyond add, commit, and push, commands like git bisect, git stash, git rebase -i, and git reflog solve real problems that come up weekly: finding the commit that introduced a bug, temporarily parking unfinished work, cleaning up a messy commit history before a review, or recovering a branch you thought was gone.

Learning these commands well is less about looking advanced and more about not losing time to avoidable mistakes. A clean git workflow also makes collaboration smoother, since reviewers spend less time untangling commit history and more time reviewing actual logic.

2. A capable terminal multiplexer or shell setup

Whether it is tmux, Zellij, or just a well-configured shell with aliases and functions, a good terminal setup removes a surprising amount of friction. Running multiple panes for logs, a running server, and an editor in one window avoids constant window switching. Custom aliases for long or repetitive commands (deployment scripts, database resets, test runners) reduce both typing and the chance of typos in critical commands.

This is one of those areas where a small one-time investment in configuration pays off every single day afterward.

3. API testing clients like Postman or Insomnia

Manually testing endpoints with curl works, but it does not scale well once you are dealing with authentication headers, environment variables, and dozens of endpoints across different services. Tools like Postman, Insomnia, or lightweight alternatives like Bruno let you organize requests into collections, share them with a team, and script pre-request logic without writing throwaway code every time.

For teams building or consuming APIs regularly, this kind of tool becomes part of the definition of done. If an endpoint has not been tested through a proper client with real headers and edge cases, it is not really finished.

4. Linters and formatters wired into the editor

ESLint, Prettier, Black, gofmt, and their equivalents in other languages are easy to take for granted until you work in a codebase that does not have them. Consistent formatting removes an entire category of pull request comments and lets reviewers focus on logic instead of style. Linting catches a meaningful number of bugs before they ever reach a test suite, things like unused variables, unreachable code, or type mismatches.

The real value shows up when these tools are wired into the editor and the CI pipeline together, so formatting and linting issues are caught before a human reviewer ever has to mention them.

5. A reliable file conversion tool

This one is less discussed than the others, but it comes up constantly in real work. Developers deal with PDFs more than most people expect: exporting reports, reading vendor documentation, pulling data out of invoices, or converting a spec sheet into something a script can actually parse. A PDF is great for fixed, printable layouts, but it is a poor format for anything that needs to be edited, queried, or fed into another tool.

This is where a browser-based PDF tool earns its place in the daily toolkit, not as something exciting, but as something that removes a recurring blocker. I have been working on PDF Converter, a free, browser-based PDF toolkit with more than 20 features, and the PDF to Excel converter is the one that comes up most often in this kind of workflow. Instead of manually retyping tables from a PDF report or writing a one-off parsing script for a single document, you can extract the tabular data directly into a spreadsheet format that is actually usable, whether that means quick analysis, feeding it into a script, or handing it off to someone on a non-technical team. It runs entirely in the browser, requires no account, and does not keep your files afterward, which matters if you are dealing with anything sensitive like financial or client data.

It is not a tool you build a workflow around the way you would with git or an API client. It is more like a utility drawer item: you do not think about it until you need it, and then you are glad it is there.

The pattern behind all five

Looking at this list, a pattern emerges. None of these tools are exciting on their own. What they have in common is that they remove small, repeated sources of friction that would otherwise chip away at a day. Version control friction, environment friction, testing friction, style friction, and format friction all fall into the same category: problems that are not hard to solve individually, but are expensive to solve manually every single time they come up.

The best developer tooling is often invisible in exactly this way. It does not show up in a demo or a highlight reel. It shows up in the fact that your day had fewer interruptions than it otherwise would have.

Closing thought

It is worth occasionally auditing your own daily toolkit the same way you would audit a codebase. Which tasks are you still doing manually that a tool could handle in seconds? Which tools have you set up once and never had to think about again? Those quiet, boring tools are usually the ones doing the most work, and they deserve a bit more credit than they get.

What is a tool in your own workflow that you would consider "invisible" in this sense? I would be curious to hear what other developers have quietly automated away.

Scanned vs Digital PDFs: Why Your Extraction Pipeline Needs Two Code Paths

Simon Briggs — Sat, 29 Aug 2026 09:08:40 +0000

3 AM, pager goes off. A batch job that's been converting invoices to spreadsheets for two months straight is now returning empty rows for 40% of a client's upload. No errors. No stack trace. Just... nothing. The pipeline ran, the file "processed," and the output sheet had a header row and silence.

Turns out the client had switched scanners. Same file extension, same MIME type, completely different problem underneath. I'd built an extraction pipeline that assumed every PDF had a text layer, because every PDF I'd tested against did. The new batch was scanned images wrapped in a PDF container, and my parser was faithfully extracting zero characters from a page full of pixels.

That bug taught me something that should've been obvious from the start: "PDF" isn't one file format from a processing standpoint. It's two, wearing the same extension.

The two things a .pdf can actually be

A digitally generated PDF, exported from Word, a web app, an accounting tool, whatever, stores its text as actual text objects. There's a font, a character encoding, positioning data. When you extract from it, you're reading structured data that was always structured.

A scanned PDF is a photograph. Someone ran a document through a scanner or snapped it with a phone, and the "PDF" is just that image dropped into a PDF wrapper, sometimes with an invisible OCR text layer bolted on by the scanning software, often without one at all. Ask a text extractor to read it, and you get exactly what's there: nothing, or garbage if the bolted-on OCR was bad.

Building one code path that assumes text exists is the root bug. You need two paths, and more importantly, you need a way to decide which one a given file needs before you waste a single CPU cycle on the wrong approach.

Detecting which one you've got

The heuristic that's worked best for me isn't complicated. Pull the text layer, count what comes back, and compare that against how much of the page is covered by images.

import fitz  # PyMuPDF

def classify_page(page, min_chars=20, image_area_threshold=0.85):
   text = page.get_text().strip()
   char_count = len(text)

   page_area = page.rect.width * page.rect.height
   image_area = 0
   for img in page.get_images(full=True):
       rects = page.get_image_rects(img[0])
       for r in rects:
           image_area += r.width * r.height

   image_coverage = image_area / page_area if page_area else 0

   if char_count >= min_chars and image_coverage < image_area_threshold:
       return "digital"
   return "scanned"

Two signals, checked together, catch more than either one alone. Char count alone fails on a page that has a scanned background image with a thin strip of real text overlaid on it (I've seen this on government forms constantly). Image coverage alone fails on a digital PDF that happens to have a large logo or watermark image taking up most of the page.

Run this per page, not per document. A 12-page contract with a digitally-generated cover page and 11 scanned exhibit pages is common, and treating the whole file as one type means you either miss the cover page's clean text or waste OCR time re-reading it.

Routing to the right path

Once you know what you're dealing with, the pipeline splits.

def extract_page(page):
   if classify_page(page) == "digital":
       return extract_text_layer(page)  # fast, near-instant
   else:
       return run_ocr(page)  # slow, CPU/GPU heavy

The cost difference here is the whole reason this matters at scale. Pulling a text layer off a digital PDF is milliseconds. Running OCR on a scanned page, even with something efficient like Tesseract, is measured in seconds per page, and that's before you factor in preprocessing steps like deskewing or contrast correction that scanned documents often need to OCR cleanly.

If you're processing a batch of 5,000 files and running every single one through OCR "just to be safe," you're paying that seconds-per-page tax on files that didn't need it at all. I've seen this mistake cut throughput by an order of magnitude on what should've been a simple batch job. The classification step isn't just about correctness, it's the difference between a job that finishes in ten minutes and one that finishes in three hours.

Where this gets tricky

A few edge cases worth planning for before they page you at 3 AM:

Fake text layers. Some scanning software adds an OCR text layer automatically, and it's often bad OCR, full of misread characters. Your char count check will say "digital" because technically there's text, but the text is garbage. Worth spot-checking extracted text against a basic dictionary or character-frequency sanity check if accuracy really matters downstream.

Vector graphics mistaken for images. Some PDF generators render text as vector paths instead of font glyphs, usually for print-perfect output. get_text() returns nothing, get_images() finds nothing either, since it's not a raster image; it's paths. This one doesn't fit neatly into either bucket, and honestly the most reliable fix is rendering the page to an image and running OCR on it regardless of what the "type" technically is.

Hybrid documents. As mentioned, per-page classification handles the common case of mixed-type files, but if you're stitching extracted tables across pages, make sure your merge logic doesn't assume every page in a document behaves the same way.

Why this matters beyond your own pipeline

If you're building this from scratch, budget real time for the classification layer; it's not a one-line if-statement in practice; it's the part of the system that determines whether your extraction is fast and accurate or slow and wrong. I underestimated it the first time and paid for it with that 3 AM page.

If you're not building this from scratch and just need PDFs, scanned or not, turned into usable spreadsheet data without maintaining this detection and OCR-routing logic yourself, this is basically the exact problem PDF Converter's PDF to Excel tool handles under the hood; it runs both paths and picks the right one per file so you don't have to.

Either way, the lesson holds: don't assume every PDF that lands in your pipeline is the same file format just because the extension matches. Check first, route second, extract third.

The Future of Small, Specialized Web Tools

Simon Briggs — Fri, 28 Aug 2026 04:23:13 +0000

Somewhere in the last decade, we convinced ourselves that software had to be big to be good. Suites replaced single-purpose apps. Dashboards grew tabs upon tabs. "All-in-one" became the highest compliment a product could receive. And yet, quietly, a counter-movement has been building: small, sharply focused web tools that do exactly one thing, do it fast, and ask nothing of you in return.

If you've ever searched "convert JSON to CSV online" or "compress this one PDF" at 11 PM instead of opening a full app, you've already participated in this shift. The question worth asking as developers is not whether these tools are useful. It's why they're becoming the default, and what that means for how we build software going forward.

The Rebellion Against Bloat

Every developer has felt it: the app that used to load in two seconds now takes eight, because somewhere along the way it accumulated a notification center, a plugin marketplace, an onboarding wizard, and three different ways to do the same task. Feature creep is rarely a single bad decision. It's the sum of a thousand reasonable ones, each shipped to satisfy one more segment of users.

Small tools sidestep this entirely by refusing to grow. A single-purpose image resizer doesn't need an account system. A markdown-to-HTML converter doesn't need a subscription tier. The constraint isn't a limitation, it's the product. When a tool does one job, every design decision can be optimized around that job instead of compromised to accommodate five others.

This is a genuinely interesting engineering discipline. Building something that resists scope creep requires more restraint than building something that embraces it.

Why the Browser Became the Perfect Host

A big part of this trend is technical, not just philosophical. Browsers have quietly become powerful enough to run real applications without installation. WebAssembly lets computationally heavy tasks (image processing, PDF manipulation, even video encoding) run client-side at near-native speed. The File System Access API lets web tools read and write local files without a server round-trip. Service workers let tools function offline after a single visit.

This matters enormously for small tools specifically, because it removes the two biggest costs of building software: distribution and infrastructure. You don't need an app store. You don't need a backend processing pipeline for every request. A tool that resizes images entirely in the user's browser costs the developer almost nothing to run, no matter how many people use it, because the computation never touches your servers.

That economic reality is quietly reshaping what kinds of tools get built. When the marginal cost of a user is close to zero, it becomes viable to build something extremely narrow. You don't need millions of users paying a subscription. You need a tool useful enough that people bookmark it and come back.

Privacy as a Feature, Not a Marketing Line

There's a second, less discussed advantage: when processing happens client-side, the data often never leaves the user's device. A PDF password remover that runs in-browser doesn't need to upload your contract to a server somewhere. An image compressor that works via WebAssembly doesn't need to store your photos, even temporarily.

For developers, this changes the privacy conversation from a policy document into an architectural decision. You're not promising to look at user data. You're building a system where there's structurally nothing to look at. That's a meaningfully different, and more trustworthy, guarantee, and users are increasingly able to tell the difference between the two.

The API-First Undercurrent

The other force pushing small tools forward is composability. A well-built single-purpose tool with a clean API isn't just useful on its own; it becomes a building block. Think about how many products are quietly stitched together from smaller specialized services: one for image optimization, one for PDF generation, one for email validation. The "big app" you use every day is often, under the hood, an orchestration layer sitting on top of a dozen small, specialized tools doing narrow jobs extremely well.

This has interesting implications for how we should think about developer tooling generally. A tool that only does text diffing but does it perfectly, with a documented API and predictable behavior, has more staying power than a sprawling suite that does diffing as one feature among fifty. Specialization is a form of reliability. It's easier to trust software when its scope is small enough to reason about.

What This Means Going Forward

None of this means large, integrated platforms are going away. Complex workflows still benefit from tools that talk to each other inside a shared environment. But the assumption that bigger software is inherently better software is losing ground, and rightly so.

For developers, the practical takeaway is this: there's real, sustainable value in building the narrow thing well. A tool that solves one specific, recurring frustration, loads instantly, requires no account, and respects user data by design will often outperform a bloated alternative on trust alone, even if it's missing ninety features the competitor has.

The future of web tools probably isn't a single winner-take-all platform. It's a growing ecosystem of small, sharp, single-purpose tools, many of them running entirely in the browser, that people reach for precisely because they don't ask for anything more than the one job they were built to do.

If you're deciding what to build next, that's worth sitting with. Sometimes the most useful thing you can ship isn't the platform. It's the one tool that just works, exactly as advertised, every single time.

We Have Cloud Storage, Yet We Still Lose Files

Simon Briggs — Tue, 25 Aug 2026 05:02:24 +0000

We live in an age of near-infinite storage. Google Drive, Dropbox, OneDrive, iCloud — pick one, pick all four, and you still get gigabytes for free. Redundancy is built in. Servers are mirrored across regions. Data centers have generators for their generators.

And yet, ask any developer, designer, or ordinary user about the last time they lost a file, and you'll get a story within seconds. A corrupted export the night before a deadline. A "file not found" error on something that was definitely there yesterday. A PDF that opens as a blank page. A sync conflict that quietly overwrote the good version with an empty one.

Cloud storage solved the problem of losing files to a dead hard drive. It did not solve the problem of losing files, period. Here's why that gap still exists, and what actually closes it.

Storage Isn't the Same as Preservation

It's worth separating two things that get bundled together: storage and preservation.

Storage means the bytes exist somewhere. Preservation means you can reliably get back a usable version of what you originally had. Cloud providers are exceptionally good at the first thing. They are not in the business of guaranteeing the second.

If you upload a corrupted file, the cloud will faithfully store that corrupted file, replicate it across three data centers, and back it up nightly. Redundancy protects the bytes, not the meaning inside them.

The Real Culprits Behind "Lost" Files

A few patterns come up again and again:

Format rot. File formats change. A document created in an old version of a tool doesn't always open cleanly in a new one. Fonts get substituted, embedded objects break, and formatting silently shifts. The file is "there," but it isn't the file you remember.

Sync conflicts. Working across a laptop, a desktop, and a phone means three clients trying to agree on what the "current" version is. Miss a sync window, edit offline, or hit a flaky connection, and you can end up with two versions competing for the same filename. One of them usually loses.

Silent corruption. Not every corruption throws an error. Sometimes a PDF opens, but a few pages render blank. Sometimes an Excel file opens, but a formula silently evaluates to zero. These failures are worse than a hard crash because nobody notices until it matters.

Conversion loss. Converting between formats- PDF to Word, image to PDF, spreadsheet to CSV- is one of the most common points of failure. Tables lose their structure, images lose resolution, metadata disappears. The cloud didn't lose the file; the conversion step quietly degraded it before it ever got uploaded.

Permission and account issues. A shared drive owned by someone who leaves the company. A personal account that gets flagged and locked. Files aren't gone, but they might as well be if you can't reach them when you need them.

Why This Matters More for Developers

If you work with documents as part of a pipeline, generating reports, converting user uploads, archiving records, these failure modes compound. A single bad conversion in an automated workflow can propagate a corrupted file into every downstream system that touches it, and nobody notices until a user complains.

This is also why "we store it in the cloud" is not, by itself, a data integrity strategy. Cloud storage answers the question "where does this live?" It doesn't answer "is this still correct?"

What Actually Reduces File Loss

A few practices go a long way, and none of them require exotic tooling:

Keep an original, untouched copy. Never let a converted or edited file overwrite the source. Conversions should always be a copy operation, not an in-place edit.
Verify after conversion, not just after upload. Open the output file and check it, especially for anything with tables, forms, or embedded images. A successful "conversion complete" message doesn't guarantee a correct file.
Avoid unnecessary format hops. Every conversion is a chance for something to break. Converting a file three times to get from A to B introduces three chances for loss instead of one.
Understand your tool's storage behavior. Some conversion tools keep your uploaded files on their servers indefinitely. Others process everything locally in the browser and discard files immediately after. If you're handling anything sensitive, that distinction matters as much as the conversion quality itself.
Treat sync tools as convenience, not backup. A synced folder is not a backup. If a bad edit syncs, it overwrites the good version everywhere. A real backup is versioned and separate from your working copy. ## Closing Thought

Cloud storage was never designed to guarantee that your files stay correct, only that the bytes stay somewhere. The actual causes of "lost" files- format rot, silent corruption, bad conversions, sync conflicts- live in the layer above storage: the tools and workflows that touch the file before and after it hits the cloud.

If your workflow involves converting files often, it's worth using a tool that processes files locally in the browser and doesn't hold onto your uploads afterward. I've been building PDF Conveter, a free, no-login PDF toolkit with 20+ conversion and editing tools, exactly with that in mind. Happy to hear what file-loss headaches you've run into in your own pipelines.

Why Good Developers Automate Boring Tasks

Simon Briggs — Fri, 21 Aug 2026 11:20:54 +0000

if a task takes you 5 minutes and you do it twice a week, that's about 8 hours a year. Doesn't sound like much.

Now imagine you do it every day. That's 20+ hours a year — half a work week — spent on something that takes 5 minutes each time, purely because nobody stopped to ask: "Wait, why am I still doing this by hand?"

This is the quiet tax that boring, repetitive tasks put on developers. Not the big, obvious inefficiencies — those get noticed and fixed. It's the small, forgettable ones: renaming files, copy-pasting deployment commands, manually formatting commit messages, checking the same dashboard every morning, re-typing the same SQL query with slightly different filters.

Good developers don't just write good code. They notice when they're the bottleneck in their own workflow — and they fix it.

Let's talk about why that instinct matters, and how to build the habit.

Automation Isn't About Laziness — It's About Attention

There's an old (and slightly overused) line: "I choose a lazy person to do a hard job, because a lazy person will find an easy way to do it."

The real insight buried in that quote isn't laziness — it's attention allocation. Every minute spent on a repetitive manual task is a minute not spent on:

Actually solving the hard problem in front of you
Reviewing a teammate's PR carefully
Thinking through an edge case before it becomes a production bug
Learning something that makes you better at your job Your brain has a finite budget of focus per day. Repetitive tasks don't just cost time — they cost cognitive bandwidth, even when they feel "easy." Automating them isn't about avoiding work. It's about protecting your attention for the work that actually needs a human brain.

The Three Signs a Task Should Be Automated

Not everything needs a script. Here's a simple mental filter:

You've done it 3+ times, and you'll do it again. One-off tasks aren't worth automating — the setup cost isn't justified. Recurring tasks are.
The steps are the same (or nearly the same) every time. If a task requires genuine judgment calls each time, automation is harder to justify. If it's mechanical — copy this, rename that, run this command — it's a prime automation candidate.
A mistake here is annoying, not catastrophic — but still costly. Ironically, the most "automatable" tasks are often the low-stakes ones nobody prioritizes fixing, precisely because each individual instance feels too small to matter. If a task checks all three boxes, it's not a question of if you should automate it — just when.

Real Examples (With Code)

Let's make this concrete. Here are common "boring tasks" and how developers actually kill them.

1. Repetitive Git Workflows

If you find yourself typing the same sequence of git commands constantly, wrap them in a script or shell alias.

# ~/.bashrc or ~/.zshrc
alias gcp='git add . && git commit -m "$1" && git push'

Or go further with a small Node/Python CLI that enforces commit conventions automatically:

import subprocess
import sys

def commit_and_push(message):
   subprocess.run(["git", "add", "."])
   subprocess.run(["git", "commit", "-m", message])
   subprocess.run(["git", "push"])

if __name__ == "__main__":
   commit_and_push(sys.argv[1])

2. File Renaming and Organizing

If you're manually renaming exported files (screenshots, reports, invoices) into a consistent naming convention every week, a short Python script eliminates it entirely:

import os
from datetime import datetime

folder = "./downloads"
for filename in os.listdir(folder):
   if filename.startswith("Untitled") or filename.startswith("Screenshot"):
       timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
       new_name = f"renamed_{timestamp}_{filename}"
       os.rename(
           os.path.join(folder, filename),
           os.path.join(folder, new_name)
       )

3. Repeated API Checks / Status Monitoring

Manually checking a dashboard or hitting an endpoint every morning to see "did anything break overnight" is a classic candidate for a scheduled script instead of a human habit.

import requests

def check_health(url):
   try:
       response = requests.get(url, timeout=5)
       if response.status_code != 200:
           print(f"⚠️ {url} returned {response.status_code}")
       else:
           print(f"✅ {url} is healthy")
   except requests.RequestException as e:
       print(f"🔥 {url} is unreachable: {e}")

check_health("https://api.example.com/health")

Pair this with a cron job or a scheduled GitHub Action, and a human never needs to remember to check it manually again.

4. Boilerplate Code Generation

If you're constantly hand-writing the same boilerplate (component scaffolds, test file structures, config templates), a simple generator script pays for itself almost immediately:

const fs = require("fs");

function createComponent(name) {
 const template = `import React from "react";

export default function ${name}() {
 return <div>${name}</div>;
}
`;
 fs.writeFileSync(`./src/components/${name}.jsx`, template);
 console.log(`Created ${name}.jsx`);
}

createComponent(process.argv[2]);

None of these examples are complicated. That's the point — most automation isn't about clever engineering. It's about noticing the pattern and spending 20 minutes once instead of 5 minutes repeatedly, forever.

The Trap: Over-Automating Too Early

It's worth naming the counter-argument, because it's a real failure mode too.

Automating a task you'll only do twice, or building an elaborate internal tool for something that changes constantly, can waste more time than it saves. This is the classic "is it worth the time?" tradeoff — automation has a break-even point, and jumping the gun on it is its own kind of inefficiency.

The skill isn't "automate everything." It's noticing recurring friction and making a fast, honest judgment call about whether the setup cost is worth it. Good developers get good at making that call quickly — not perfectly, just quickly and reasonably.

Automation Is a Habit, Not a Project

The biggest shift isn't technical — it's behavioral. It's the moment you catch yourself doing something manually for the third time and think, "wait, I should fix this," instead of just pushing through it again.

That small habit — noticing friction and acting on it — compounds. Developers who build this instinct end up with:

Personal toolkits of scripts that make their day-to-day smoother
Fewer manual errors from repetitive copy-paste work
More mental space for the actual hard problems
A reputation as the person who "just handles things" efficiently None of this requires being a 10x engineer. It just requires paying attention to your own friction — and treating that friction as a signal, not background noise.

TL;DR

Repetitive manual tasks cost more than time — they cost attention and focus.
A task is worth automating if it recurs, follows consistent steps, and carries a real (if small) cost when done wrong.
Most useful automation is simple: shell aliases, small scripts, scheduled jobs — not elaborate systems.
Don't over-automate one-off tasks — know the break-even point.

- The real skill is the habit of noticing friction and acting on it quickly.

Going Paperless Didn't Reduce Documents — It Multiplied Them

Simon Briggs — Thu, 20 Aug 2026 07:56:18 +0000

Somewhere between the rise of the PDF and the death of the fax machine, someone told us: "Go paperless and simplify your life."

No more filing cabinets. No more manila folders. No more searching through drawers for that one invoice from three years ago. Just clean, searchable, infinitely organized digital files.

Fast forward to today, and here's the plot twist nobody saw coming: we didn't reduce documents — we multiplied them.

Open your Downloads folder right now. Go on, I'll wait.

You've probably got: 14 PDFs named Untitled_scan_2.pdf, a dozen .docx contracts, a handful of .xlsx invoices, three versions of the same resume, a screenshot you saved "for later," and at least one file called final_FINAL_v2.pdf.

We didn't kill paper. We cloned it, gave it infinite copies, scattered it across five cloud drives, and forgot where half of it went.

This article is about why that happened, what it means for developers building document-heavy products, and the tools and patterns you can use to actually tame the chaos — instead of just digitizing it.

Why "Paperless" Backfired

It sounds counterintuitive, so let's break down the actual mechanics of how this happened.

1. Digitization removed the cost of creation

Printing a physical document had friction: paper, ink, a printer that's always out of toner. That friction was a natural rate-limiter.

Digital documents have near-zero marginal cost. Generating a PDF invoice, exporting a report, or auto-saving a Word doc takes milliseconds and costs nothing. When the cost of creating something drops to zero, you get way more of it — this is just supply and demand at the content layer.

2. Every SaaS tool generates its own documents

Two decades ago, an organization dealt with a handful of physical formats: memos, invoices, contracts, forms.

Today, every tool in your stack generates its own artifact:

Your accounting software → PDF invoices
Your CRM → exported reports
Your e-signature tool → signed contracts
Your project management tool → exported task lists
Your meeting tool → auto-generated transcripts and summaries
Your design tool → exported spec sheets Multiply that by every SaaS subscription the average company runs (analysts estimate mid-size companies use 100+ SaaS tools), and you get an exponential explosion of "documents" — most of which live in silos that don't talk to each other.

3. Compliance and audit trails require more paperwork, not less

Ironically, going digital made record-keeping easier, so organizations started keeping more of it. Regulatory requirements (GDPR, HIPAA, SOC 2, financial audits) mandate document retention, versioning, and audit trails. Every digital action can now generate a document proving it happened — a receipt for the receipt.

4. Search didn't actually get better — it got fragmented

The paperless promise assumed one unified, searchable archive. What we got instead is:

Files in Google Drive
Files in Slack threads
Files in email attachments
Files in Notion
Files in a shared network drive nobody has touched since 2019
Files in your CI/CD artifacts "Ctrl+F" only works within a single silo. Across silos, you're back to manually hunting — just like the old filing cabinet, except now there are 20 filing cabinets and they're all in different buildings.

What This Means If You Build Software

If you're a developer, this isn't just a lifestyle observation — it's a massive product and engineering opportunity. Document overload is a real, painful problem your users are living with daily. Let's look at the technical building blocks for solving it.

Parsing and Extracting Structured Data from Documents

The first challenge is almost always: "I have a pile of PDFs/scans/docs and I need structured data out of them."

A common Python starting point using pdfplumber for text-based PDFs:

import pdfplumber

def extract_text(pdf_path):
   full_text = []
   with pdfplumber.open(pdf_path) as pdf:
       for page in pdf.pages:
           full_text.append(page.extract_text() or "")
   return "\n".join(full_text)

print(extract_text("invoice_2024.pdf"))

For scanned documents (images pretending to be documents), you need OCR. pytesseract combined with pdf2image is a common open-source combo:

from pdf2image import convert_from_path
import pytesseract

def ocr_scanned_pdf(pdf_path):
   pages = convert_from_path(pdf_path, dpi=300)
   text = ""
   for page_image in pages:
       text += pytesseract.image_to_string(page_image)
   return text

This is the unglamorous, foundational layer beneath every "AI document processing" product you've ever seen marketed on LinkedIn.

Deduplication: Fighting the "final_FINAL_v2" Problem

Once you're ingesting documents at scale, duplicate detection becomes essential. A simple but effective approach is content hashing:

import hashlib

def file_hash(filepath):
   hasher = hashlib.sha256()
   with open(filepath, "rb") as f:
       while chunk := f.read(8192):
           hasher.update(chunk)
   return hasher.hexdigest()

For near-duplicates (same content, different formatting/metadata), you'll want something fuzzier — like comparing extracted text with a similarity metric (cosine similarity on TF-IDF vectors, or embeddings if you want semantic-level dedup).

Structuring Chaos with Metadata Tagging

The real fix for "document sprawl" isn't fewer documents — it's better metadata. Instead of relying on folder hierarchies (which break down past a few hundred files), tag documents with structured, queryable metadata:

{
 "id": "doc_8841",
 "type": "invoice",
 "vendor": "Acme Supplies",
 "date": "2026-03-14",
 "amount": 452.10,
 "source_system": "quickbooks",
 "tags": ["Q1-2026", "reimbursable"]
}

Store this in a lightweight database (SQLite, Postgres) alongside a pointer to the actual file (S3 key, local path). This turns "search through folders" into "run a query" — the single highest-leverage change you can make to a document-heavy system.

Using LLMs for Classification and Summarization

This is where modern tooling genuinely helps. Instead of manually tagging thousands of documents, you can use an LLM to classify and summarize them at ingestion time:

const response = await fetch("https://api.anthropic.com/v1/messages", {
 method: "POST",
 headers: { "Content-Type": "application/json" },
 body: JSON.stringify({
   model: "claude-sonnet-4-6",
   max_tokens: 500,
   messages: [
     {
       role: "user",
       content: `Classify this document into one category
       (invoice, contract, report, receipt, other) and give a
       one-sentence summary. Return only JSON: {"category": "...", "summary": "..."}

       Document text:
       ${extractedText}`
     }
   ]
 })
});

const data = await response.json();

At scale, this turns an unsorted pile of PDFs into a tagged, searchable, queryable dataset — automatically.

The Real Lesson: Paperless Was Never the Goal

The mistake was framing the problem as "eliminate paper." The actual goal was always: make information easy to find, trust, and act on.

Paper was never really the enemy — disorganization was. Digitizing without addressing structure just gave disorganization a faster engine.

If you're building tools in this space (document management, knowledge bases, internal search, compliance systems), the winning products won't be the ones that store the most documents. They'll be the ones that make documents disappear — not by deleting them, but by making the underlying information instantly retrievable without the human ever touching the file itself.

TL;DR for Devs

Digitization didn't reduce document volume — it removed the friction that used to limit it.
Every SaaS tool in your stack is quietly generating its own document sprawl.
Real solutions require: extraction (OCR/parsing) → deduplication → structured metadata → intelligent classification.
LLMs are genuinely useful here — not as a buzzword, but as a practical classification/summarization layer on top of traditional extraction pipelines.

I shipped the Wrong Config File. The Bug Wasn't in My Code.

Simon Briggs — Tue, 18 Aug 2026 06:16:34 +0000

I once pushed config_prod_FINAL.json to a staging deploy that was supposed to run against config_staging.json. Nobody caught it in review because the diff looked fine; the file just had the wrong values in it. We didn't notice until a support ticket came in about live payment webhooks firing in a test environment.

Nothing catastrophic happened. We caught it in about twenty minutes. But it stuck with me, because the root cause wasn't a logic bug. It was that I had three config files sitting in the same directory with names that only made sense to past-me at 11 pm three weeks earlier.

The bug wasn't in the code

Here's the thing about being a developer: we're pretty disciplined about version control for code. Branches, commits, PRs, all of it. But the second something isn't tracked in git, whether it's a local .env file, an exported report, a client-facing doc, or a one-off script output, the discipline disappears. We treat "not code" as "doesn't need a system."

That inconsistency is exactly how I ended up with this in one folder:

config.json
config_v2.json
config_staging.json
config_prod.json
config_prod_FINAL.json
config_prod_FINAL_actual.json

Every one of those was, at some point, "the current one." None of them were labeled with when they were current or why they existed. git log could tell me what changed inside a tracked file. Nothing could tell me which of these six untracked files I was actually supposed to be looking at.

Treating local files with the same discipline as commits

The fix wasn't a new tool. It was applying the same mental model I already use for git to things git doesn't track.

For config and environment files specifically, I started doing this:

# instead of overwriting or duplicating vaguely:
cp config.json config_v2.json

# name by purpose + date, and delete instead of stockpiling:
mv config.json config.staging.2026-08-14.json

Two changes, both small:

Purpose before version number. config.staging tells you what it's for immediately. config_v2 tells you nothing except that a config_v1 probably still exists somewhere.
Delete instead of archive. If a config file is superseded, it gets deleted, not renamed to _old and kept around. Old configs sitting in a working directory are landmines, not backups. If I actually need history, that's what git is for. I also stopped keeping generated or exported files in the same directory as source files. Reports, exports, anything meant to be read rather than run, now live in a separate /exports folder that's gitignored entirely, so it can never accidentally get mixed up with something that matters to the build.

The part that isn't about code at all

The other half of this problem shows up when you're handing things to people who aren't developers. PMs, clients, whoever's reviewing a spec or a report you generated from a script.

If you send someone a .docx or an editable export, you're implicitly asking them to trust that it won't get edited, forwarded, or opened in some tool that reflows the formatting. I've had a beautifully formatted markdown-to-PDF report turn into a mess because someone opened the intermediate .docx version in an older version of Word and every table shifted.

Now, anything that leaves my machine as a finished artifact, a status report, a client-facing doc export, documentation handoffs, gets converted to PDF before it goes out. It's a small step, but it means what I generated is what they see, full stop, regardless of what they open it with. I usually run it through PDF Converter for that last step since it's quick enough to not break my flow and doesn't need me to install anything or sign up for a tool I'll use twice a month.

The actual lesson

None of this was really about finding a smarter naming scheme or a better tool. It was realizing that "not tracked by git" doesn't mean "doesn't need a system." Config files, exports, generated docs, anything living outside version control still needs the same basic discipline: know what it is, know when it was made, and don't keep six versions of the truth sitting in the same folder hoping you'll remember which one is real.

Twenty minutes of a staging environment misbehaving is a cheap lesson. I'd rather learn it from a support ticket than from a production incident, so consider this the version of the story where nobody has to page you at 2 am.

If you're regularly exporting docs or reports and need them locked into a clean, unchangeable format before they leave your machine, PDF Converter is free and doesn't ask for much.

Why Simple Digital Tools Usually Beat Complicated Workflows

Simon Briggs — Mon, 17 Aug 2026 05:34:46 +0000

I once inherited a "workflow" from a previous freelance client that involved four different apps just to get an invoice from draft to sent. A doc editor, a PDF exporter with three configuration screens, a file renamer script someone had written in 2019, and an automation tool gluing it all together with six triggers.

The whole thing broke the week I started, because one API key expired and nobody noticed for a month.

That's the trap with complicated workflows: they feel powerful right up until the moment they don't, and then you're debugging someone's automation instead of doing the actual work.

The hidden cost of "powerful" tools

Every extra tool in your stack isn't just an extra feature. It's an extra thing that can break, an extra login, an extra thing to explain to a new hire, and an extra dependency you didn't know you had until it goes down mid-deadline.

Developers know this pattern well from software architecture. It's the same reason a monolith with three well-understood services often outperforms a microservices setup with twelve, if the team doesn't actually need that complexity yet. More moving parts means more failure surface, even if each part is "better" on paper.

Simple workflow: Draft -> Export -> Send
Complicated workflow: Draft -> Format check -> Export tool A ->
 Naming script -> Automation trigger -> Cloud sync -> Send

Six steps versus three. The six-step version might save you four seconds per file when everything works. It costs you forty-five minutes when one link in the chain quietly stops working and you don't find out until a client asks where their invoice is.

Complexity should be earned, not assumed

This isn't an argument against automation. It's an argument against automation you built before you actually needed it.

A good rule: don't automate a task until you've done it manually at least a dozen times and can describe the exact repeatable steps without thinking. If you can't describe it cleanly, automating it early just bakes your confusion into a script that's harder to fix later than the manual process ever was.

I've seen this go wrong in two directions:

Over-tooled solo freelancers who spend a weekend setting up a project management system with custom fields, automations, and integrations for a business with three active clients. The setup time alone eats more hours than the manual method would have cost in a year.

Under-tooled dev teams who keep doing something manually for eighteen months past the point where a fifteen-minute script would have paid for itself. Both are avoidable if you actually measure the task before deciding its complexity budget.

A quick framework for deciding

Before adding a tool or automation step to your workflow, ask three questions:

How often does this task actually happen? Weekly, sure, maybe worth streamlining. Twice a year, probably not.
What's the failure mode if this tool goes down or changes its API? If the answer is "I'm stuck," that's a real cost, not a hypothetical one.
Could a simpler, boring tool do 90% of this job? Boring tools (a plain converter, a basic spreadsheet, a single-purpose app) tend to be more stable long-term than flashy all-in-one platforms, because they have less surface area to change underneath you. That third question is the one people skip most often, usually because the boring option doesn't feel like "using the right tool for the job." But stable and unglamorous beats fragile and impressive most weeks of the year.

Where this shows up in everyday file handling

A concrete example most people run into weekly: turning a document into a shareable, locked-format file before sending it out.

You could build a whole pipeline for this. Watch folder, trigger conversion, rename, upload, notify. That's genuinely useful if you're processing hundreds of files a day and the volume justifies the setup and maintenance.

For most of us, we're converting a handful of files a week, and the actual need is just: take this Word doc or image, turn it into a clean PDF, done. I usually just run it through PDF Converter directly rather than maintaining a script for something that takes ten seconds by hand. No API key to expire, nothing to break silently at 2 AM.

That's the whole point. The complicated version isn't wrong; it's just solving a problem you might not have yet.

Simple doesn't mean lazy

There's a version of this advice that gets misread as "don't bother automating anything, just do everything by hand." That's not it either.

Simple means matching the tool to the actual scale and frequency of the problem, not the scale you imagine you might have someday. A single-purpose tool that does one thing reliably will usually outlast a complex stack that does everything, because the complex stack has more ways to quietly stop working while you're not watching.

Next time you're about to add a new tool, a new integration, or a new automated step to how you get work done, it's worth pausing on that third question: could something simpler and more boring get you 90% of the way there? Usually, it can.

If you're just trying to get a document into a clean, shareable PDF without setting up a whole pipeline for it, PDF Converter works fine for the occasional file and doesn't ask you to configure anything first.

The Hidden Cost of Saying "I'll Organize It Later"

Simon Briggs — Sat, 15 Aug 2026 05:43:19 +0000

Every developer has a folder called stuff or temp or misc sitting somewhere on their machine, quietly growing for the last two years. Mine is called _sort_later. It has 1,400 files in it. I checked before writing this. I am not proud.

"I'll organize it later" is one of the most expensive sentences in software development. Almost nobody notices the cost because it never shows up as one big bill. It shows up as a thousand tiny ones.

Later never actually arrives

This isn't a discipline problem. It's a design problem.

"Later" has no trigger. There's no cron job for it, no deploy hook, no CI check that fails if you skip it. Compare that to code review. It happens because a PR won't merge without it.

Organizing your downloads folder has no equivalent gate. So it just doesn't happen, until the folder is unusable and you nuke it in frustration instead of fixing the actual habit.

Where the real cost hides

It's not really about mess. Plenty of great engineers have messy desktops. The cost is in the small interruptions that mess causes, and how those interruptions compound.

The ninety-second search that isn't really ninety seconds

Say you're debugging something and need last month's API response payload to compare against today's. You know you saved it. You just don't know if it's named response.json, response(2).json, response_final.json, or buried in a Slack DM you sent yourself.

That's ninety seconds of searching. Ninety seconds isn't the problem.

The problem is that ninety-second search just broke your flow state, and getting back into the actual debugging headspace takes another ten minutes. That's the real invoice, and it's denominated in context, not time.

Multiply that by however many times a week you go looking for something you know you have but can't find. "I'll organize it later" starts looking less like harmless procrastination and more like a recurring tax on your attention.

Three habits that actually stuck

I've tried full organizational systems (PARA, Johnny Decimal, elaborate folder trees) and they all fell apart within a month because they required too much upkeep. What's worked instead is smaller and dumber.

Name things at the moment of creation

If I export a config, a log dump, or a screenshot, I rename it before I close the window it came from.

2fa-bug-repro-aug14.png instead of Screenshot 2026-08-14 at 3.42.11 PM.png.

It costs five seconds now. It saves five minutes of guessing later, and unlike most productivity advice, this one is basically free because you're already looking at the file.

One inbox folder, reviewed weekly

Everything unsorted goes into a single folder called inbox. I go through it every Friday for ten minutes.

Not sorting on arrival (too much friction, breaks flow). Not letting it pile up forever (defeats the point). A weekly cadence is the sweet spot where it's routine enough to stick but rare enough not to be annoying.

Separate "reference" from "active"

Docs, contracts, and specs I need to read once and act on live in one place. Docs I might need to reference again in six months live somewhere completely different.

Mixing these two categories is, in my experience, the single biggest reason folders become unusable. Active stuff needs to be found fast today. Reference stuff needs to be found reliably in a year. Those are different problems, and they deserve different homes.

A small example from last week

A client sent over a signed contract as a Word doc with tracked changes still visible, formatting broken across two page sizes, and a filename like FINAL_FINAL_v3.docx.

Rather than let that sit in my inbox folder as a landmine for future me, I converted it to a clean PDF right away, renamed it properly, and dropped it into the reference folder where signed contracts live. I used PDF Converter for that since it doesn't need an install and I was working from a machine that wasn't mine.

Ten seconds now, and future me never has to open a Word file with tracked changes on and wonder what's real.

The actual philosophy here

Every time you touch a file, you're deciding whether to pay a small cost now or a slightly higher, less predictable cost later, at a moment you don't get to choose.

Right after you download or receive something is the cheapest point in its whole lifecycle to deal with it. Every day after that, the cost goes up a little, mostly because you forget the context you had when you first saw it.

"I'll organize it later" isn't lazy. It's just betting that future you will have more time, more energy, and better memory than present you does.

Future you usually doesn't.

If you're dealing with a messy file today, it's worth handling it now instead of shipping it to your misc folder. And if it happens to be a document that needs to travel cleanly, PDF Converter is free and doesn't require an install.

The Lazy Person's Guide to Organizing Documents

Simon Briggs — Wed, 12 Aug 2026 06:40:53 +0000

Let's be honest. Nobody became a developer because they love file management. We optimize loops, refactor functions, and automate anything that takes more than two clicks, but somehow our own documents folder looks like a crime scene. Fifteen resumes named "resume2," a folder called "stuff," and a PDF you definitely need for taxes that's buried three folders deep inside "Downloads/new/final/old."

This guide isn't about becoming a minimalist filing guru. It's about doing the least amount of work possible while still being able to find what you need in six months. Lazy, but functional.

Why developers are especially bad at this

We're trained to think in systems, so, ironically, our personal files are chaos. Part of it is that code has enforced structure (compilers and linters won't let you get away with sloppy syntax), but a Documents folder has no rules at all. Nothing breaks if you name a file "asdf.docx." So it doesn't.

The other part is that document organization feels like a solved problem that isn't worth automating, so we never build a system for it the way we would for, say, a deploy pipeline. That's exactly why it stays messy. Nobody treats it like infrastructure.

Rule 1: Stop naming things by feeling

"final," "final2," "reallyfinal," "USE_THIS_ONE" are not naming conventions; they're a cry for help. The lazy but effective fix is a predictable pattern you never have to think about again:

YYYY-MM-DD_short-description_v1.ext

Example: 2026-08-12_client-invoice_v1.pdf

This sorts chronologically without effort, tells you exactly what it is without opening it, and eliminates the need to remember which "final" was actually final. You're not being fancy here, you're just removing a decision you'd otherwise make badly under time pressure.

Rule 2: Fewer folders, not more

The instinct when things get messy is to create more folders. Resist this. A deep folder tree is just procrastination wearing a productivity costume. Nested folders like Documents/Work/Clients/2026/Q3/Invoices/August/Final require you to remember a path, and lazy systems don't rely on memory.

A flatter structure with strong file naming beats a deep folder structure every time, because your file explorer's search bar is faster than your brain at recalling where you put something three months ago. Two or three top-level folders (Work, Personal, Archive) is usually enough. Let the filenames do the organizing.

Rule 3: Separate "editable" from "done"

This is the one habit that saves the most future pain. Working drafts and final documents should never live in the same mental bucket, because you'll eventually forward the wrong one. A simple mental rule:

Editable files (docx, xlsx, sketches, WIP) stay in a working folder
Anything you're sending externally gets converted to a locked format before it leaves your machine This matters more than it sounds like it should. An editable file sent externally can drift in formatting depending on what app or OS opens it, and it can be edited without anyone noticing. A locked PDF avoids both problems. If you're doing this manually and it feels like friction, a quick browser-based converter (I use PDF Converter; it's free and doesn't require installing anything) removes the excuse to skip the step.

Rule 4: Automate the boring part

If you're a developer, you already have an unfair advantage here: you can write a five-line script instead of doing this by hand forever. A basic example for renaming downloaded files by date:

import os
from datetime import date

folder = "/path/to/downloads"
today = date.today().isoformat()

for filename in os.listdir(folder):
   if filename.startswith("Untitled") or filename.startswith("Document"):
       new_name = f"{today}_{filename}"
       os.rename(
           os.path.join(folder, filename),
           os.path.join(folder, new_name)
       )

It's not elegant, but it solves the actual problem: things you download or export tend to have garbage default names, and a tiny script fixes that before it becomes a mess. You could extend this to auto-sort by file type or move things into dated folders, but don't over-engineer it. The lazy approach wins by doing just enough.

Rule 5: Archive instead of delete

Deleting feels productive but creates anxiety, because you're never fully sure you won't need that file again. The lazy compromise is a single Archive folder where old versions go once something is finalized. You don't have to sort it. You don't have to think about it. You just need it to exist so your active folders stay clean, and you have a fallback if you're wrong about not needing something.

Once a year (or never, if you're truly committed to laziness), you can skim the archive and delete anything obviously irrelevant. This is optional. The point of an archive is that it removes the pressure to make a permanent decision right now.

The actual system, summarized

If you want the tl;dr version to screenshot and forget:

Name files by date, not by mood
Keep folder structure shallow
Keep editable and final versions separate, lock anything going external
Automate the renaming step if you touch a lot of files
Archive instead of agonizing over deletion None of this requires a new app, a productivity system, or a weekend project. It requires about ten minutes of setup and a habit you barely notice after the first week. That's the whole appeal of a lazy system: it has to be easier than doing nothing, or you won't keep doing it.

If you're the kind of developer who automates everything except your own desktop, this is the cheapest fix you'll make all year.

Why Images Are Terrible for Long Documents (And What Developers Keep Getting Wrong)

Simon Briggs — Tue, 11 Aug 2026 05:00:18 +0000

Every developer has done this at least once: taken a screenshot of an error, a config file, or a terminal output, and dropped it straight into documentation instead of typing it out. It feels efficient in the moment. It's the opposite of efficient the moment that document grows past a page or two.

Images work fine for a single screenshot in a Slack message. They fall apart completely once you're dealing with anything resembling a real document, onboarding guides, technical specs, API references, or anything longer than a quick note. Here's why, and what actually works instead.

You Can't Search an Image

This is the most obvious problem, and somehow still the most ignored one. If your documentation is a series of screenshots stitched together, or even a PDF made entirely of scanned or photographed pages, none of that text is searchable. Ctrl+F does nothing. Someone looking for a specific error message, a config value, or a function name has to scroll through the entire document manually, hoping they recognize it visually.

For a one-page cheat sheet, that's mildly annoying. For a 40-page onboarding doc or a long API reference, it's genuinely unusable. New team members give up searching and just ask in Slack instead, which defeats the entire purpose of writing documentation in the first place.

Images Don't Scale Across Screen Sizes

Text reflows. Images don't. A screenshot that looks perfectly readable on a 27-inch monitor becomes a blurry, illegible mess on a laptop screen or a phone. Long documents built from stacked images inherit this problem at every single page, since each image has a fixed resolution that either gets scaled down awkwardly or forces horizontal scrolling on smaller screens.

This matters more than it used to, since a lot of documentation now gets read on tablets, phones, or split-screen setups rather than a single dedicated monitor. Text-based content adapts to all of that automatically. Image-based content just breaks.

You Can't Copy Anything

Try copying a code snippet out of a screenshot. You can't. You either retype it manually, which introduces the very real risk of typos in something that needs to be exact, or you zoom in and squint until you're confident you've transcribed it correctly. Multiply that across a long document with dozens of code blocks, config examples, or command-line instructions, and you've turned a five-second copy-paste into a genuinely time-consuming, error-prone task.

This is one of the most common complaints from anyone reading image-heavy technical docs, and it's completely avoidable. Anything meant to be copied and used- code, commands, config values- needs to exist as actual text, not a picture of text.

File Size Balloons Fast

A long document built from screenshots or scanned pages gets heavy fast. Each image adds real weight, and a 30-page image-based PDF can easily end up several times larger than the same content in proper text form. This becomes a real problem when that document needs to be emailed, uploaded to a wiki with size limits, or shared through a platform like Slack or GitHub that caps attachment sizes.

If you're stuck with a document that's already been built this way, scanned forms, exported image-heavy reports, or a stack of photographed pages, compressing it before sharing at least keeps it usable. A quick pass through a Compress PDF tool can shrink an oversized file significantly without destroying the readability of the content inside it, which matters when the alternative is an upload that just won't go through.

Accessibility Breaks Down Completely

This one gets overlooked constantly, but it matters a lot. Screen readers can't parse text inside an image. Someone relying on assistive technology to read documentation gets nothing useful out of a page that's really just a picture. Even basic accessibility tools like browser text-to-speech or translation extensions fail the same way, since they need actual text to work with, not pixels arranged to look like text.

For internal team docs, this might feel like a minor concern. For anything public-facing- user guides, API documentation, onboarding material for a broader audience- it's a real accessibility failure that excludes people unnecessarily, especially when the fix is often as simple as using real text instead of a screenshot in the first place.

Version Control Basically Doesn't Exist

Text-based documentation can live in a repo, get diffed, reviewed in a pull request, and tracked properly over time. Image-based documentation can't. If a screenshot in your onboarding doc shows an outdated UI or a config value that's since changed, there's no clean way to update just that piece. Someone has to retake the screenshot, manually replace it, and hope everyone remembers to actually do that when things change.

This is a big part of why image-heavy docs go stale so quickly. Updating text is a five-second edit. Updating a screenshot means recreating the exact scenario that produced it in the first place, which people understandably deprioritize until the document is embarrassingly out of date.

When Images Actually Make Sense

None of this means images are useless. Diagrams, architecture visuals, UI walkthroughs where the visual layout genuinely matters- these are legitimate uses for images in documentation. The mistake isn't using images at all. It's using images as a substitute for text content that should have stayed text in the first place: error messages, code snippets, config examples, and anything meant to be copied, searched, or read by assistive technology.

The Better Habit

If you've inherited a document that's already image-heavy, whether that's scanned pages, exported screenshots, or old documentation nobody's touched in years, it's worth converting the useful parts back into real text before treating it as a long-term reference. A quick Image to Word conversion can pull text out of an image-based document, giving you something searchable and editable to actually maintain going forward, instead of a static picture that quietly rots the moment anything changes.

Long documents are meant to be searched, copied, updated, and read by more than just a pair of human eyes squinting at a screenshot. Text does all of that by default. Images do none of it. Once you start noticing which one you're actually building, the fix is usually just a change in habit, not a technical one.