About worldofbs
A working engineer's notebook on software architecture, developer tooling, and the parts of the industry that deserve a closer look.
Why This Site Exists
Most of what gets published about software engineering is either marketing dressed up as a tutorial or a conference talk recycled into a blog post. There's a gap between the polished case studies and what actually happens when you sit down to refactor a service at 4pm on a Thursday. worldofbs tries to live in that gap.
The site started as a private wiki. Notes on why a particular build pipeline kept breaking, a list of NixOS quirks worth remembering, half-formed rants about hiring loops. After enough colleagues asked for links to specific entries, it made more sense to publish the lot.
The name is a hint about the editorial filter. If a claim doesn't survive contact with a real codebase, it doesn't get a post.
Our Mission: Useful Engineering Over Theatre
The mission is narrow on purpose: write things that a mid-to-senior engineer can actually use on Monday morning. Not inspiration. Not thought leadership. Specific, testable, occasionally wrong opinions backed by code that exists.
What "useful" means here
- Concrete trade-offs, with the losing side named explicitly.
- Configuration that has run somewhere longer than a demo.
- Critiques aimed at ideas, not at people or companies.
- Plain prose. No "unlock", no "leverage", no "journey".
What we deliberately avoid
We don't run sponsored posts disguised as reviews. We don't chase the framework-of-the-week unless there's something genuinely new under the hood. And we try to resist the urge to write about a tool until we've used it on something that matters, which usually means at least a few weeks of friction.
What We Write About
Four areas, chosen because they're where the writers actually spend their working hours. Anything outside this scope gets handled briefly or not at all.
Software Architecture
System design without the whiteboard fantasy. Coupling, boundaries, the cost of abstractions you'll regret. Examples from real services, not the canonical pizza-ordering app.
Developer Tooling
Linux, NixOS, terminal setups, keyboards, the editors people argue about. Reviews written after months of use, not a weekend.
Engineering Culture
How teams actually work. Documentation that nobody reads, standups that became status theatre, the politics of code review. Honest, sometimes uncomfortable.
Industry Opinions
Hot takes on hiring loops, buzzwords, the AI hype cycle, and whatever consultancy is currently selling "transformation". Sharp, but argued.
How We Form an Opinion
A reasonable question, given that the whole site is opinions. The short answer: most posts start as a problem someone on the team is actually trying to solve. The longer answer has a process attached.
The rough workflow
- Use it in anger. A tool or pattern doesn't get reviewed until it has been deployed, broken, and debugged at least once in something resembling production.
- Write the strongest version of the opposite view. If we can't articulate why a reasonable engineer would disagree, the post isn't ready.
- Cite the version numbers. Software ages. A claim about Postgres 12 is not a claim about Postgres 16, and we try not to pretend otherwise.
- Internal review. At least one other contributor reads it before it goes up, mostly to catch overconfident statements.
This is still a small operation, and the process leans on judgement more than instrumentation. We're upfront about that.
The Team Behind the Posts
A small group of working engineers, not a content marketing department. Everyone here has a day job writing or reviewing code, and contributes to the site on the side. Bylines are real names where possible, pseudonyms where employer policy makes that complicated.
Collectively the team has experience across backend systems, infrastructure, platform engineering, and a fair amount of time spent in code review at organisations ranging from approximately twelve-person startups to companies you've heard of. Nobody here is a full-time pundit, which we consider a feature.
If you want to reach the team directly — to correct something, suggest a topic, or argue with a take, the Contact page is the right starting point.
Scope, Limitations, and Corrections
A few honest notes about what this site is and isn't.
A note on certainty: Our writing reflects the stacks we work in — primarily Linux servers, JVM and Go backends, and Nix-based environments. Recommendations may not transfer cleanly to mobile, embedded, or heavy Windows-centric shops, and we try to flag that in the posts where it matters.
Corrections
When we get something wrong, the post gets edited with a visible note at the bottom. We don't quietly rewrite history. If a benchmark turns out to be flawed, or a tool fixes the issue we complained about, that update belongs on the page.
Conflicts of interest
If a contributor has a financial or employment relationship with a tool being discussed, it's disclosed at the top of the relevant post. We don't accept payment for reviews.
Legal and privacy
The boring but necessary documents live at Privacy Policy and Terms of Service. Read them if that's your kind of evening.