When I added mobile personas to a browser that already had desktop ones working, I assumed the work was mostly string substitution: swap the user agent, set touch points to 5, shrink the viewport, done. That assumption survived about a day.
Two test suites can have exactly the same average runtime and still create completely different development workflows. I modeled 300 code → test → fix cycles while keeping mean feedback latency close to ten seconds and changing only its variance. One runner behaved predictably. The other was usually fast but occasionally became extremely slow. The average stayed almost the same. The cost of waiting did not.
Self-hosted Sentry means 65 containers, 16-32 GB of RAM, and a dedicated engineer just to keep it alive. All that - to catch stack traces. We dig into why the industry treats this as normal, compare the alternatives (GlitchTip, BugSink, Hawk), and take a look at Metric - a Sentry-compatible monitoring platform written in Rust that runs on 1 GB of RAM and two containers. Migration is a single-line DSN change.
Two months ago I gave an agent a simple job: log into a vendor portal, download last month’s invoice PDF, rename it, drop it in a folder. It worked on my laptop. It failed on the server, silently, in a way that took me a full day to understand — the page loaded, the DOM was there, the login form was there, and the credentials were rejected with a generic error. No CAPTCHA. No block page. Just “something went wrong.”
A test taking 20 seconds does not necessarily cost a developer only 20 seconds. At some point during the wait, staying in the IDE becomes less attractive than opening a browser, checking documentation, reading a message, or starting another small task. I built a simulation of 300 code → test → fix cycles to estimate what happens when test latency begins to trigger context switching, and why cutting a test from 20 seconds to 10 may be much more valuable than cutting it from 5 seconds to 1.
CreepJS is the test everyone in this space quotes and almost nobody reads carefully. It’s an open-source page that fingerprints your browser and then — this is the part that matters — checks whether your browser is lying. Not whether your values are unusual. Whether they’re internally possible.
I wanted to see what actually changes when the same small data-processing program travels through four generations of programming languages. So I built it in BASIC, C, Pascal and Python, kept the algorithm as similar as possible, and compared not only execution speed but also memory use, binary size, debugging time and the amount of code I had to keep in my head. C was fast. Python was short. Those parts were predictable. BASIC and Pascal were where the experiment became interesting.
AI-generated code often looks cleaner than code written by a tired developer at 2 a.m. It has sensible names, neat layers, comments, tests and even error handling. The problem starts when the code meets something the prompt forgot to mention: two requests at once, a repeated webhook, a cancelled task or a database failure halfway through an operation.
This article is about bugs that stay invisible during a normal code review. I took several ordinary backend tasks, generated working solutions and then tried to break them with timing, retries and bad input. The code compiled. The tests were green. Some of it was still unsafe.
My name is Anton Omelianenko and I’m head of software development. A manager runs a team so that it delivers results for the business. To judge how well people are handling their work, a manager needs data and a system for assessing it. In software development this is harder than it looks.
This article covers three questions: why classic metrics fail when assessing developers, how to measure performance properly and what to do when an employee may not be working only for you.
A normal code review comment usually sounds harmless.
Rename this variable. Move this method. Add a test. Remove the duplicate condition. But sometimes an experienced developer leaves a much shorter comment: No.
Not maybe. Not could we simplify this. Just a clear rejection of the entire approach.
For a junior developer, this can feel strange. The code compiles, tests pass, the implementation is readable, and the ticket requirements seem complete. Why throw it away?
I started saving such cases after one of my pull requests was rejected for the third time in a week. The goal was not to prove that the reviewer was wrong. I simply wanted to understand what experienced engineers noticed before everyone else.
Over several months, I collected review discussions from backend services, internal tools, queue consumers, APIs, and data-processing jobs. I removed comments about formatting and naming. Only full design-level rejections remained.
The result was a small catalogue of professional paranoia.
And honestly, most of it was useful.
Deleting code sounds easy until the code belongs to a running product.
A function may have no direct callers but still be loaded through a plugin registry. A serializer may look duplicated but quietly preserve an old field name used by one customer. A command may not appear in analytics because it runs from cron at 3:10 a.m. on the first Sunday of each month. Python makes this even more fun because imports, decorators, entry points, reflection, monkey patches, and strings can all become hidden edges in the dependency graph.
The project in this story was a multi-tenant reporting backend written in Python. It accepted events, stored normalized records, generated reports, exported CSV and JSON files, and delivered them through HTTP, email, and object storage. Nothing huge. Around 140 API endpoints, 46 background tasks, PostgreSQL, Redis, and a queue.
The repository contained 62,914 lines of Python excluding tests and migrations.
That number was not the actual problem. The problem was that a small change in report filtering could require edits in the API schema, a service class, a repository, a filter translator, a query builder, an export adapter, and several nearly identical tests. The system had layers, but the layers did not reduce complexity. They distributed it.
The first plan was a rewrite. Fortunately, that plan died before production did.
Instead, the question became much simpler: How much code can disappear while externally observable behavior remains unchanged?
That wording changed the whole project.
At some point, ChatGPT stopped feeling like a tool and started feeling like a reflex.
Need a parser? Ask ChatGPT.
Strange exception in a background worker? Ask ChatGPT.
Forgot how a lock behaves under contention? Ask ChatGPT.
Need to rename a method? Apparently, that also required artificial intelligence.
Nothing looked wrong on the surface. Tasks were moving. Pull requests were getting merged. The code usually worked. Sometimes it even looked cleaner than what I would have written from scratch. But there was a small problem. A few days later, I often could not explain why a certain solution was built that way. I remembered the task, the final code, and maybe the prompt. The reasoning in between was missing.
That bothered me more than I expected.
So I set a simple rule: for six months, no ChatGPT, no Copilot Chat, no AI-generated code pasted into production. Documentation, source code, issue trackers, books, debuggers, profilers, and search engines were allowed. AI assistants were not.
The experiment started as a way to test my own dependence. It ended up changing how I design APIs, debug systems, read unfamiliar code, and even write comments.
Regular expressions have the ability to track the path and some reflection. We'll try to use these features to capture and colorize text parts and output them to the console using AutoHotkey.
Совершать невозможное и раздавать пинки здравому смыслу — в этом и состоит жизнь членов Гуррен-Дана! (C) Камина
This article enters into a technical debate with a 2015 article by Atakua, whose approaches I am attacking. Atakua explores 7 types of bytecode interpreters, but does so disrespectfully - the fastest turns out to be binary translation, which is essentially no longer a bytecode interpreter, but a form of Ahead-Of-Time compiler. This binary translation translates bytecode into machine code, which is a chain of calls to compiled service routines. The very same ones that are responsible for executing each opcode in a bytecode interpreter.
But Atakua didn't squeeze all the possible speed out of bytecode interpreters. So this article is a tutorial: how to write a bytecode interpreter that can outperform JIT/AOT compilation in speed. Interested? Read on!
A benchmark is included. There will be a bit of hardcore and not a single AI-generated image!
A mind-blowing mix of 64/32-bit assembly and good old C++ awaits us. We will create our own implementation of... Fibers (fibers) without calling the Win API or dialing 911.
Yesterday (November 27), Habr hosted an 'Author's Fireside Chat'.
It was very interesting, and one of the speaker's statements struck me. It was that AI can help write simple pieces of code but doesn't work with complex things. Thus, large language models are likened to a junior programmer.
I decided to write an article about it this morning, drawing on my knowledge and experience in computational mathematics (I used to do modeling in the past, and for the last few years, I've been teaching computational mathematics at MIPT). Let me know what you think.
I think this is the main myth of vibe-coding. It's exactly the opposite — AI is often good at writing quite complex things and retrieving important information that is difficult to find on your own. But it gets confused in the most elementary things. It's a reverse junior.
The problem is that this is a dangerous illusion, and I will now clearly explain why, and how it can be dangerous. Brew some coffee and get ready for a debunking that might save your millions, your career, or even human lives in the future.
On a Friday evening, a colleague, let's call him Avenger, asked if I had ever encountered a problem where a route returns 400... but "if you change the name to something very different," then everything is okay. At first, I didn't pay attention to the word "very". Maybe the route registration is duplicated somewhere? Or Avenger mixed up GET and POST. Or is there some general bug in handler creation?
It would seem that modern C++ offers so many possibilities... Let's try to dissect all this immense power, starting with the first step in any programming language — "Hello World".
How do compiler implementations greet a newcomer who has just written their first lines of code?
What are ANSI codes and how does the terminal process them? Why terminal emulators even exist? How to format the output to PowerShell from AutoHotkey? Let's dive in!
How to write console output algorithm on AutoHotkey, why this language is awesome and what to consider when writing on your high-level language.
