Just another developer
Every team I know does code review. Very few have ever asked themselves what they are actually doing when they do it. On paper it’s a simple practice: before a change lands on the main branch, somebody who didn’t write it reads it. It started as a quality control mechanism - Fagan’s formal inspections at IBM in the seventies, with assigned roles, scheduled meetings and defect logs - and over time…
A few evenings ago I was out for dinner with a friend who works as a developer. At some point the conversation drifted to work: how do you actually bring some quality into a company that doesn’t seem to want any? Which arguments land, and which ones fall flat. And almost by reflex, one of us pulled out the classic argument - the one we all reach for sooner or later: look how much a bug costs you…
Back in 2016, my colleagues called me “minottobot” - out of both affection and frustration. Every pull request came back with meticulous comments: syntax, style, naming, indentation. I was a human linter. Relentless. Insufferable. Years later, I moved deeper into quality engineering. The line-by-line work became irrelevant - it was treating symptoms, not disease. The real questions were: Why are…
There’s a question that echoes through every legacy codebase, every late-night deploy, every “it works on my machine” moment: did you actually try it? Not in a dismissive way - in the most honest, pragmatic sense. Did someone, with their own hands, open a browser and verify that the thing works the way it’s supposed to? This article is about that question, where it comes from, and a small tool I…
Anyone who works with automated test suites knows the frustration of a flaky test: one that fails every now and then for no apparent reason, blocks the pipeline, and distracts the whole team. The classic fix is to comment out the test, push a commit, and open a PR - a slow and noisy process for a problem that is often temporary. Skipper was built to eliminate that friction. What is Skipper Skipper…
Anyone who has worked on a frontend or mobile app knows this: waiting for a backend to be “ready” is one of the fastest ways to slow everything down. And even when the backend exists, what you really need for productive development is often missing: realistic responses, reproducible edge cases, coherent data across endpoints, and a simple way to switch between mock and real upstream behavior.…
Over the past few years, I’ve been using Playwright almost every day. Over time, it stopped being “just another tool” and became a core part of how I approach web software quality. Honestly, it’s hard to find something that works better: the HTML report is clear, multi-browser support is reliable, the trace viewer is incredibly powerful, and parallelization (workers, shards) works seamlessly. Add…
Trust is one of those concepts we usually associate with people. We trust colleagues, managers, companies. But in software development, trust goes much further than that. We trust our tests. We trust our codebase. We trust the systems we build. And the interesting part is this: when trust breaks in one place, it often starts breaking everywhere. Trust in Automated Tests In modern development…
A few years ago, during a particularly tense retrospective, someone said: “Wasn’t this bug supposed to be caught by QA?” The room went quiet. It wasn’t an open accusation. But in that sentence there was a clear boundary: quality had an owner. And it wasn’t “the team”. In that moment, I realized the problem wasn’t the bug. It was our definition of quality. We often talk about tools, pipelines,…
When we talk about software quality, we usually think about automated tests, architecture, code reviews, or reliability metrics. Much more rarely do we think about Git history. And yet it is one of the most underestimated assets of a project. Git history is not just a record of what changed in the code: it is the evolutionary memory of the system . It tells how the software grew, which decisions…