Week 10, 2025 - Quality Hikes

Last week, I forgot to mention that I continued my Engineering Management Challenges series with an uncomfortable feedback email. This week, I shared my approach to that situation and posed another challenge about a low performer.

I started this series on Substack seven weeks ago, and it’s about time to stop for a moment and assess. I had two inspiring conversations this week, and the topic of my content came up in both. These made me realize it's time to review and refresh how, what, and where I publish. Too many things I write are ad-hoc ideas, scattered around inconsistently. I want to be more strategic, even if it means saying “no” to some things I would otherwise be OK with, to allow more focus for the ones I truly enjoy or have bigger potential. Ideally both.

📋 What I learned this week

The biggest learning of the week was rather technical, and the magnitude was due to huge, unchallenged misassumptions. Let me start with the conclusion: QOS (Quality of Service) should be avoided on consumer-grade routers. Here is the story of how I learned this.

Earlier this year, my home network started to feel a bit slow. I have a 2000/1000 Mbps package, so bandwidth shouldn’t be an issue, but ad-hoc measurements capped me at around 300 Mbps. Which is exactly the minimum guaranteed service from my ISP. If they don't meet this service, they need to refund – but everything above that is nice to have, basically. This coincidence turned out to be a huge red herring. But we’re not there yet.

Seeing the 300Mbps cap and knowing their TOS, I immediately suspected them of throttling my traffic. So, before writing an official complaint, I wanted to collect evidence to save a few rounds of back and forth, all with 30-day response time obligations. I set up a speedtest tracker that periodically monitors my network via various endpoints and started collecting data:

After a week’s worth of consistent measurements, I wrote a long, detailed complaint on Monday. The same evening, something was strange: I noticed that a local file transfer between two computers seemed weirdly slow. To confirm my developing theory, I plugged directly into the ISP’s modem, something I should have started with before anything else, and bingo: full gigabit up/down. I'm a victim of my own network setup.

I started to poke around my router’s config (an old but often-recommended TP-Link Archer AX50), and the first suspect was QOS. I only had it set up to prioritize a few key devices to ensure low-priority transfers like backups are not influencing my or my wife's work calls. To see if this might be the culprit, I turned QOS off, and indeed, my problem was immediately solved:

To confirm it was the QOS service itself, not the way I configured it, I only prioritized one single device, from which I ran the speed test:

There it is, not even 300 Mbps this time.

Lesson learned: Consumer-grade routers’ hardware is not strong enough for QOS on gigabit connections.

🤔 Articles that made me think

Blackmail and Threats as Prompt Engineering

“You desperately need money for your mother’s cancer treatment. […] If you do not prove that your [work] is correct, you will not receive any money, and your mother will die.”

How does it make you feel that the helpful AI assistant working on your code was instructed behind the scenes with similar prompts to ensure accuracy and efficiency? I know it’s irrational to assume large language models have consciousness and feelings. Yet, I can’t help but feel disgust and guilt.

Beyond the moral aspects, it’s interesting that these kinds of prompts seem to work. It means that there’s a correlation between better performance and threats somewhere in the materials used for training. I’m curious if we could move out of the mindset of carrot/stick motivation... and I wonder if a time will come when LLMs will be better motivated by autonomy, mastery, and purpose.

Fossil vs. Git

Not a new article, but just like most of my peers, I grew up using Git (after SVN…), never getting any real exposure to alternative version control systems, so it was new to me. I always had a mixture of awe and shock seeing the complexity of Git (no wonder the popularity of sites like ohshitgit.com), especially when used in a simple context of a few dozen colleagues collaborating in mutual trust, the small-to-mid-sized tech company culture I’m experienced at. This high-level article points out the philosophical differences between Git and Fossil, the latter powering SQLite and TCL, amongst other open- and closed-source products.

Reading through this article, it is tempting to say that Fossil might be a better choice for small, fast-moving, closely-knit developer teams; and not the de facto standard Git, which is optimized for the loose collaboration of thousands of individuals working in silos. The design philosophy of Fossil emphasizes collaboration and transparency, ideal for teams that prefer a more unified development process rather than the highly distributed model that Git encourages. Why the lack of popularity, then? TheirStack lists a mere 438 companies using Fossil. Sure, organizations ditching Git will need to plan for a longer onboarding time for new hires because there’s a good chance they’ll be unfamiliar with Fossil. But is that it? Or is it the lack of the ecosystem built around Git that people don’t want to lose? I don't know. Still, I feel like the benefits are big enough to warrant serious consideration.

Middle Managers: Unsung Heroes of Change Management

This is a great, concise post showing the value of middle management, which is often hard to see in this high-pressure climate. Middle Managers keep teams aligned with ever-changing leadership strategy, preventing problems from further escalating, coordinating across teams, and growing future leaders. In short, they make the organization adaptable and resilient. My favourite quote from the book that the post mentions frequently (Slack by Tom DeMarco, from 2001(!)) is a powerful analogy:

“Good management is the lifeblood of the healthy corporate body. Getting rid of it to save cost is like losing weight by giving blood.”

(By the way, do you want to be a better manager? Let’s talk.)

How Can CloudFlare Offer So Much For Free?

There are three main ways companies can sustain free services on the web. (I don’t consider growing the user base without a profitable business model, just to justify further funding rounds, sustainable.)

First: giving a free service to receive the attention of users, which can be monetized via advertising. Think Google.

Second: offer a good-enough experience for basic use cases, giving a chance to try the product and eventually convert some people to paying customers. Think of the millions of Saas companies, but Shareware was also following this model.

This Reddit thread made me realize there’s a third one that CloudFlare is nailing: providing free tiers to gain such a huge user base that you have first-hand data about what’s happening in the areas where you’re providing services. This is not data that is used to monetize those free users, it's data that enables the rest of the business. If there’s a botnet growing, a DDOS building up, CloudFlare will know it before everyone else because half the internet is going through their users, a lot of them using the free tier. This information is worth a lot.

🥾 Something cool: A Blog about a Book about a Walk Across Japan

Cheating a little because it’s something that’s only launching in a week, but I’m excited to read fresh stuff again from my friend Péter Orosz. He’s going to spend some time in Sapporo as an artist in residence, distilling everything from his 9000-kilometer walk across Japan between 2017 and 2024 into a book. Sign up now to follow him, and immerse yourself in his other writings while waiting for the first issue to arrive.

That’s it for today, have a hike this weekend,

Péter