For most write-ups, I’ve switched to en-dash flanked by two spaces these days. Easier to type and looks less gippitified imo.
> But British usage - instead - uses spaces, so an en-dash or an em-dash is acceptable.
Readit Newsrednafi commented on Show HN: Hacker News em dash user leaderboard pre-ChatGPT gally.net/miscellaneous/h... · Posted by u/tkgally
rednafi commented on Do the simplest thing that could possibly work seangoedecke.com/the-simp... · Posted by u/dondraper36
The problem with this is no one can agree about what "at scale" means.
Like yes, everyone knows that if you want to index the whole internet and have tens of thousands of searches a second there are unique challenges and you need some crazy complexity. But if you have a system that has 10 transactions a second...you probably don't. The simple thing will probably work just fine. And the vast majority of systems will never get that busy.
Computers are fast now! One powerful server (with a second powerful server, just in case) can do a lot.
Yep, vertical scaling goes a long way. But it’s not compute where the bottleneck for scale lies, rather in the resiliency & availability.
So although a single server goes a long way, to hit that sweet 99.999 SLA, people horizontally scales way before hitting the maximum compute capacity of a singe machine. HA makes everything way more difficult to operate and reason about.
rednafi commented on Do the simplest thing that could possibly work seangoedecke.com/the-simp... · Posted by u/dondraper36
Though in my previous job, a huge amount of complexity was due to failed, abandoned, or incomplete attempts to refactor/improve systems, and I frequently wondered, if such things had been disallowed, how much simpler the systems we inherited would have been.
This isn't to say you should never try to refactor or improve things, but make sure that it's going to work for 100% of your use cases, that you're budgeted to finish what you start, and that it can be done iteratively with the result of each step being an improvement on the previous.
Every refactor attempt starts with the intention of 100% coverage.
No one can predict how efficacious that attempt will be from the get-go. Eventually, often people find out that their assumptions were too naive or they don’t have enough budget to push it to completion.
Successful refactoring attempts start small and don’t try to change the universe in a single pass.
rednafi commented on Do the simplest thing that could possibly work seangoedecke.com/the-simp... · Posted by u/dondraper36
Man, who hurt you?
I certainly don’t agree with everything Sean says and admit that “picking the most important work” is a naive thing to say in most scenarios.
But writing Python in production is trivial. Why would anyone lie about that? C is different OTOH. But just because you do a single config change and get paid for that doesn’t mean it’s true for everyone.
Also, staff at GitHub requires a certain bar of excellence. So I wouldn’t blindly dismiss everything just out of spite.
rednafi commented on The Cost of Slow Feedback Loops revontulet.dev/p/2025-hid... · Posted by u/rednafi
One thing I like to add to this is that there is a cost of context switch (average of 15-25 minutes, depending on the study, and obviously varying significantly between types of tasks), and we lose focus when waiting takes more than 15s or 30s [citation missing, though you can look it up].
Slow feedback loop will add the above 15-20 minutes as soon as you switch to something else because it took more than 15-30s (on average, though).
I like to note that there are also people who are amazing good at both regaining focus, and not getting flustered by switching between tasks. I am not one of them, though :)
The SoA and the team structure often worsen this. If your service consists of AWS S3, SQS, MSK, and Kinesis, then you'd have to invest quite heavily in the local setup to make sure everything still works and that the majority of the tests can be run in a reasonable amount of time.
Of course, it's impossible to run the full fleet locally if it's a substantially large system, but investing in the local workflow for a particular domain is absolutely paramount. Otherwise, the context switch required to integrate and work with a system like this is absolutely massive, and the lead time for a new feature will take a major hit.
I do not understand why they chose Norway. I would choose a country where it is easy to build up a new power plant quickly with solar and wind, close to the site of the data center. Maybe they just have too much electricity up there that is not needed by the population or existing industry?
I understand why they didn’t choose Germany: they didn’t want to buy the GPUs in cash and send the receipts via Fax.
rednafi commented on In retrospect, DevOps was a bad idea rethinkingsoftware.substa... · Posted by u/aard
DevOps is a good idea. But most have no clue about the Ops part
All the devops I have encountered so far have been “sysadmin in a trench coat.” Most couldn’t write anything beyond basic Python and Shell scripts. It was mostly ops folks jumping into a fancy new title. So every time something would go poof, they had to pull in devs to debug the most basic stuff.
rednafi commented on In retrospect, DevOps was a bad idea rethinkingsoftware.substa... · Posted by u/aard
Most of the DevOps folks I’ve encountered, unfortunately, couldn’t code much. So it was mostly ops work with a fancy new title.
The idea of a single entity being responsible for development, operations, observability, and support is flawed from the start. That’s not a one-person job, and the expectation simply doesn’t scale. So DevOps often ends up being either ops folks or dev folks, and rarely a true blend of the two.
What we need are feature-focused developers, ops-savvy devs who can deploy their own work, and a strong team dedicated to observability and applying modern SRE practices.
So I think curious developers who aren’t afraid of infra, along with a solid platform engineering team, are a real improvement over the status quo.
For coding, unless I’m writing trivial RPC endpoints, editing docs, or writing tests for an already hardened API, I find agents a complete waste of time. So my usage is mostly limited to chat sessions.
To use up the quota, I apply the provided tokens to a few personal projects here and there, but no one can make me push an actual production CL with them unless I find it useful myself.