HN Reader

They don't explicitly ask for it, but they won't take you seriously if you don't at least pretend to be. "Fast" is assumed. Imagine if Rust had shown up, identical in every other way, but said "However, it is slower than Ruby". Nobody would have given it the time of day. The only reason it was able to gain attention was because it claimed to be "Faster than C++".

Watch HN for a while and you'll start to notice that "fast" is the only feature that is necessary to win over mindshare. It is like moths to a flame as soon as something says it is faster than what came before it.

In response, Casey spent <1 week making RefTerm, a skeleton proto-terminal with the same constraints Microsoft people had - using Windows APIs for things, using DirectDraw with GPU rendering, handling terminal escape codes, colours, blinking, custom fonts, missing font character fallback, line wrap, scrollback, Unicode and Right-to-Left Arabic combining characters, etc. RefTerm had 10x faster throughput than Windows Terminal and ran at 6-7000 frames per second. It was single-threaded, not profiled, not tuned, no advanced algorithms, no-cheating by sending some data to /dev/null, all it had to speed it up was simple code without tons of abstractions and a Least Recently Used (LRU) glyph cache to avoid re-rendering common characters, written the first way that he thought of. Around that time he did a video series on that YouTube channel about optimization and arguing that even talking about 'optimization' was too hopeful, we should be talking about 'not-pessimization', that most software is not slow because it has unavoidable complexity and abstractions needed to help maintenance, it's slow because it's choked by a big pile of do-nothing code and abstraction layers added for ideological reasons which hurt maintenance as well as performance.

[1] https://www.youtube.com/watch?v=hxM8QmyZXtg - "How fast should an unoptimized terminal run?"

This video[2] is another specific details one, Jason Booth talking about his experience of game development, and practical examples of changing data layout and C++ code to make it do less work, be more cache friendly, have better memory access patterns, and run orders of magnitude faster without adding much complexity and sometimes removing complexity.

[2] https://www.youtube.com/watch?v=NAVbI1HIzCE - "Practical Optimizations"

I distinctly remember when Slashdot committed suicide. They had an interface that was very easy for me to scan and find high value comments, and in the name of "modern UI" or some other nonsense needed to keep a few designers employed, completely revamped it so that it had a ton of whitespace and made it basically impossible for me to skim the comments.

I think I tried it for about 3 days before I gave up, and I was a daily Slashdot reader before then.

I asked an agent to write an http endpoint at the end of the work day when I had just 30 min left -- my first thought was "it took 10 minutes to do what would have taken a day", but then I thought, "maybe it was 20 minutes for 4 hours worth of work". The next day I looked at it and found the logic was convoluted, it tried to write good error handling but didn't succeed. I went back and forth and ultimately wound up recoding a lot of stuff manually. In 5 hours I had it done for real, certainly with a better test suite than I would have written on my own and probably better error handling.

See https://www.reddit.com/r/programming/comments/1lxh8ip/study_...

I have found this true for myself as well. I changed back over to Go from Rust mostly for the iteration speed benefits. I would replace "fast" with "quick", however. It isn't so much I think about raw throughput as much as "perceived speed". That is why things like input latency matter in editors, etc. If something "feels fast" (ie Go compiles), we often don't even feel the need to measure. Likewise, when things "feel slow" (ie Java startup), we just don't enjoy using them, even if in some ways they actually are fast (like Java throughput).

Early in my career as a software engineer, I developed a reputation for speeding things up. This was back in the day where algorithm knowledge was just as important as the ability to examine the output of a compiler, every new Intel processor was met with a ton of anticipation, and Carmak and Abrash were rapidly becoming famous.

Anyway, the 22 year old me unexpectedly gets invited to a customer meeting with a large multinational. I go there not knowing what to expect. Turns out, they were not happy with the speed of our product.

Their VP of whatever said, quoting: "every saved second here adds $1M to our yearly profit". I was absolutely floored. Prior to that moment I couldn't even dream of someone placing a dollar amount on speed, and so directly. Now 20+ years later it still counts as one of the top 5 highlights of my career.

P.S. Mentioning as a reaction to the first sentence in the blog post. But the author is correct when she states that this happens rarely.

P.P.S. There was another engineer in the room, who had the nerve to jokingly ask the VP: "so if we make it execute in 0 seconds, does it mean you're going to make an infinite amount of money?". They didn't laugh, although I thought it was quite funny. Hey, Doug! :)

For example, if you're running experiments in one big batch overnight, making that faster doesn't seem very helpful. But with a big enough improvement, you can now run several batches of experiments during the day, which is much more productive.

[1] https://speechischeap.com

He pays special attention to the speed of application. The Russian social network VK worked blazingly fast. The same is about Telegram.

I always noticed it but not many people verbalized it explicitly.

But I am pretty sure that people realize it subconsciously and it affects user behaviour metrics positively.

Almost everywhere I’ve worked, user-facing speed has been one of the highest priorities. From the smallest boring startup to the multi billion dollar company.

At companies that had us target metrics, speed and latency was always a metric.

I don’t think my experience has been all that unique. In fact, I’d be more surprised if I joined a company and they didn’t care about how responsive the product felt, how fast the pages loaded, and any weird lags that popped up.

It's a retroactively fixed thing. Like imagine forgetting to make a UI, shipping just an API to a customer then thinking "oh shit, they need a UI they are not programmers". And only noticing from customer complaints. That is how performance is often treated.

This is probably because performance problems usually require load or unusual traffic patterns, which require sales, which require demos, which dont require performance tuning as there is one user!

If you want to speed your web service up first thing is invest time, maybe money in really good observability. Should be easy for anyone in the team to find a log, see what CPU is at etc. Then set up proxy metrics around speed you care about and talk about them every week and take actions.

Proxy metrics means you likely cant (well probably should not) check the speed that Harold can sum his spreadsheet every minute, but you can check the latency of the major calls involved. If something is slow but metrics look good then profiling might be needed.

Sometimes there is an easy speed up. Sometimes you need a new architecture! But at least you know what's happening.

First, efficient code is going to use less electricity, and thus, fewer resources will need to be consumed.

Second, efficient code means you don't need to be constantly upgrading your hardware.

Microsoft needs to take heed, for example Explorer's search, Teams, make your computer seem extremely slow. VS Code on the other hand is fast enough, while slower than native editors such as Sublime Text.

I used to play games on N64 with three friends. I didn’t even have a concept of input lag back then. Control inputs were just instantly respected by the game.

Meanwhile today, if I want to play rocket league with three friends on my Xbox series S (the latest gen, but the less powerful version), I have to deal with VERY noticeable input lag. Like maybe a quarter of a second. It’s pretty much unplayable.

On interfaces:

It's not only the slowness of the software or machine we have to wait for, it's also the act of moving your limb that adds a delay. Navigating a button (mouse) adds more friction than having a shortcut (keyboard). It's a needless feedback loop. If you master your tool all menus should go away. People who live in the terminal know this.

As a personal anecdote, I use custom rofi menus (think raycast for Linux) extensively for all kinds of interaction with data or file system (starting scripts, opening notes, renaming/moving files). It's notable how your interaction changes if you remove friction.

Venerable tools in this vein: vim, i3, kitty (former tmux), ranger (on the brim), qutebrowser, visidata, nsxiv, sioyek, mpv...

Essence of these tools is always this: move fast, select fast and efficiently, ability to launch your tool/script/function seamlessly. Be able to do it blindly. Prefer peripheral feedback.

I wish more people saw what could be and built more bicycles for the mind.

baba is fast.

I sometimes get calls like "You used to manage a server 6 years ago and we have an issue now" so I always tell the other person "type 'alias' and read me the output", this is how I can tell if this is really a server I used to work on.

fast is my copilot.

Speed is what made Google, which was a consumer product at the time. (I say this because it matters more in consumer products.)

For what is worth I built myself a custom jira board last month, so I could instantly search, filter and group tickets (by title, status, assignee, version, ...)

Motivation: Running queries and finding tickets on JIRA kills me sometimes.

The board is not perfect, but works fast and I made it superlightweight. In case anybody wants to give it a try:

https://jetboard.pausanchez.com/

Don't dare to try on mobile, use desktop. Unfortunately it uses a proxy and requires an API key, but doesn't store anything in backend (just proxies the request because of CORS). Maybe there is an API or a way to query jira cloud instance directly from browser, I just tried first approach and moved on. It even crossed my mind to add it somehow to Jira marketplace...

Anyway, caches stuff locally and refreshes often. Filtering uses several tricks to feel instant.

UI can be improved, but uses a minimalistic interface on purpose, like HN.

If anybody tries it, I'll be glad to hear your thoughts.

I have been asking about Latency-Free Computing for a very long time. Every Computing now is slow.

nowadays it's fancy touch display, requires concentration and often sluggish, and the machine often felt cheap and made cheap sound when tapped on, I don't think the operator are ever enjoying interacting with it and the software's often slow across the network....

I'm all for fast. It shows no matter what, at least somebody cared enough for it to be blazing fast.

I don't want my code deployed in seconds or milliseconds. I'm happy to wait even an hour for my deployment to happen, as long as I don't have to babysit it.

I want my code deployed safely, rolled out with some kind of sane plan (like staging -> canary -> 5% -> 20% -> 50% -> 100%), ideally waiting long enough at each stage of the plan to ensure the code is likely being executed with enough time for alerts to fire (even with feature flags, I want to make sure there's no weird side effects), and for a rollback to automatically occur if anything went wrong.

I then want to enable the feature I'm deploying via a feature flag, with a plan that looks similar to the deployment. I want the enablement of the feature flag, to the configured target, to be as fast as possible.

I want rollbacks to be fast, in-case things go wrong.

Another good example is UI interactions. Adding short animations to actions makes the UI slower, but can considerably improve the experience, by making it more obvious that the action occurred and what it did.

So, no, fast isn't always better. Fast is better when the experience is directly improved by making it fast, and you should be able to back that up with data.

Windows is the worst offender here, the entire desktop is sluggish even though it there is no computational task which justifies those delays.

C++ with no forward decls, no clang to give data about why the compile time is taking so long. 20 minute compiles. Only git tool I like (git-cola) is written in Python and slows to a crawl. gitk takes a good minute just to start up. Only environments are MSYS which is slow due to Windows, and WSL which isn't slow but can't do DPI scaling so I squint at everything.

You make much better code, and much better products, if you "fast" from your vocabulary. Instead set specific, concrete latency budgets (e.g. 99.99% within x ms). You'll definitely end up with fewer errors and better maintainability than the people who tried to be "fast". You'll often end up faster than them too.

> But software that's fast changes behavior.

I wonder if the author stopped to consider why these opposing points make sense, instead of ignoring one to justify the other.

My opinion is that "fast" only becomes a boon when features are robust and reliable. If you prioritize going twice as "fast" over rooting out the problems, you get problems at twice the rate too.

This is true, but I also think there's a backlash now and therefore some really nice mostly dev-focused software that is reeaaaaly fast. Just to name a few:

- Helix editor - Ripgrep - Astral python tools (ruff, uv, ty)

That's a tiny subsection of the mostly bloated software that exists. But it makes me happy when I come across something like that!

Also, browsers seems to be really responsive despite being one of the most feature bloated products on earth thanks to expanding web standards. I'm not really counting this though because Firefox and Chrone might rarely lag, the websites I view with them often do, so it's not really a fast experience.

I loathe working on it but don’t have the time to refactor legacy code.

———————-

I have another project that I am principal engineer and it uses Django, nextjs, docker compose for dev and ansible to deploy and it’s a dream to build in and push features to prod. Maybe I’m more invested so it’s more interesting to me but also not waiting 10 seconds to register and hot reload a react change is much more enjoyable.

Assuming, like, three days, 6 minutes is 720x faster. 10000x faster than 6 minutes is like a month and a half!

Fast is indeed magical, that's why I exclusively browse Instagram from the website; it's so slow I dip out before they get me with their slot machine.

I don't know, there are a sizeable subset of folks who value fast, and it's a big subset, it's not niche.

Search for topics like turning off animations or replacing core user space tools with various go and rust replacements, you'll find us easily enough.

I'm generally a pretty happy MacOS user, especially since M1 came along. But I am seriously considering going back to linux again. I maintain a parallel laptop with nixos and i'm finding more and more niggles on the mac side where i can prioritise lower friction on linux.

Speed of all kinds is incredibly important. Give me all of it.

- Fast developers

- Fast test suites

- Fast feedback loops

- Fast experimentation

Someone (Napoleon?) is credited with saying "quantity has a quality all its own", in software it is "velocity has a quality all its own".

As long as there is some rigor and you aren't shipping complete slop, consistently moving very quickly fixes almost every other deficiency.

- It makes engineering mistakes cheaper (just fix them fast)

- It make product experimentation easy (we can test this fast and revert if needed)

- It makes developers ramp up quickly (shipping code increases confidence and knowledge)

- It actually makes rigor more feasible as the most effective rigorous processes are light weight and built-in.

Every line of code is a liability, the system that enables it to change rapidly is the asset.

Side note: every time I encounter JVM test startup lag I think someday I am going to die and will have spent time doing _this_.

Again, no ill will intended at all, but I think it straddles the promotional angle here a bit and maybe people weren't aware

>Performant stealth mode

>Scale browsers with bot anti-detection. Access high performant residential proxies and built-in auto-CAPTCHA solvers

[0] https://www.onkernel.com/#:~:text=Performant%20stealth%20mod...

The greatest day of productivity in my life was a flight from Melbourne to New York via LAX. No wifi on either flight, but a bit in transit. Downloaded everything I needed in advance. Coded like a mofo for like 16 hours.

Fast internet is great for distractions.

https://magarshak.com

https://miracles.community

https://qbix.com

https://intercoin.app

Here is some extensive advice for making complex websites load extremely quickly

https://community.qbix.com/t/qbix-websites-loading-quickly/2...

Here is also how to speed up APIs:

https://community.qbix.com/t/building-efficient-apis-with-qb...

One of the biggest things our framework does as opposed to React, Angular, Vue etc. is we lazyload all components as you need them. No need for tree-shaking or bundling files. Just render (static, cached) HTML and CSS, then start to activate JS on top of it. Also helps massively with time to first contentful paint.

https://community.qbix.com/t/designing-tools-in-qbix-platfor...

All this evolved from 2021 when I gave this talk:

http://www.youtube.com/watch?v=yKPKuH6YCTc

As some working on embedded audio DSP code I just had to laugh a little.

Yes, there is a ton of code that has a strict deadline. For audio that may be determined by your buffer size — don't write your samples to that buffer fast enough and you will hear it in potentially destructively loud fashion.

This changes the equation, since faster code now just means you are able to do more within that timeframe on the same hardware. Or you could do the same on cheaper hardware. Either way, it matters.

Similar things apply to shader coding, game engines, control code for electromechanical systems (there, missing the deadline can be even worse).

https://blog.superhuman.com/superhuman-is-being-acquired-by-...

Being fast helps, but is rarely a product.

However the capital required will probably never happen again in relation to the return for any investor involved in that product.

Props to them for pushing the envelope, but they did it in the zero interest era and its a shame this is never highlighted by them. And now the outcome is pretty clear in terms of where the company has ended up.

I once used Notion at work and for personal note taking. I'd never felt it was "slow." Until later I moved my notes to Obsidian. Now when I have to use Notion at my job it feels sluggish.

It's gorgeous

I know this is completely different scale, but compare: [1] https://github.com/git/git [2] https://gitpatch.com/gitpatch/git-demo

And there is no page cache. Sub 100ms is just completely different experience.

https://ocw.mit.edu/courses/6-172-performance-engineering-of...

That's because it's understood that things should work as quickly as possible, and not slowly on purpose (generally). No one asks that modern language is used in the UI as opposed to Sanskrit or heiroglyphs, because it's understood.

At least in B2B applications that rely heavily on relational data, the best developers are the ones who can optimize at the database level. Algorithmic complexity pretty much screams at me these days and is quickly addressed, but getting the damned query plan into the correct shape for a variety of queries remains a challenge.

Of course, knowing the correct storage medium to use in this space is just as important as writing good queries.

It was unpopular, because devs love the shiny. But it worked - we had nice quick applications. Which was really important for user acceptance.

I didn't make this rule because I hated devs (though self-hatred is a thing ofc), or didn't want to spend the money on shiny dev machines. I made it because if a process worked acceptably quickly on a dev machine then it never got faster than that. If the users complained that a process was slow, but it worked fine on the dev's machine, then it proved almost impossible to get that process faster. But if the dev experience of a process when first coding it up was slow, then we'd work at making it faster while building it.

I often think of this rule when staring at some web app that's taking 5 minutes to do something that appears to be quite simple. Like maybe we should have dev servers that are deliberately throttled back, or introduce random delays into the network for dev machines, or whatever. Yes, it'll be annoying for devs, but the product will actually work.

My favourite example of not "fast" right now is any kind of Salesforce report. Not only are they slow but you can't make any changes to the criteria more often than once a minute. Massively changes your behaviour.

Btw, cool site design.

It is implicit, in the same way that in a modern car you expect electric windows and air-conditioning (yes, back in the day, those were premium extras)

Figuring out the best way to present logically complex content, controls and state to users that don’t wrangle complexity for a living is difficult and specialized work, and for most users, it’s much more important than snappy click response.

Both of these things obviously exist on a spectrum and are certainly not mutually exclusive. (ILY McMaster-Carr) But projects rarely have enough time for either complete working features, or great thoughtful usability, and if you’re weighing the relative importance of these two factors, consider your audience, their goals, and their technical savvy before assuming good performance can make up for a suboptimal user workflow.

Thanks for enduring my indulgent rant.

Is the most pressing problem facing the world is that we are not doing enough things fast enough? Seems a bit off the mark, IMO.

Bookmarking this one

https://permacomputing.net/

For example, looking up command flags within man pages is slooooow and becomes agonizingly frustrating when you're waking up and people are waiting for you so that they can also go back to sleep. But if you've spent the time to learn those flags beforehand, you'll be able to get back to sleep sooner.

Yeah, that's not "a world" it's just the USA. Parts of the world - EU, UK etc have already moved on from that. Don't assume that the USA is leading edge in all things.

Are you kidding me? My product owner and management ask me all the time to implement features "fast".

Tell me "fast" again!

Of course fast has downsides but it's interesting this pitch is here. Must have occurred many times in the past.

"Fast" was often labeled "tactical" (as opposed to "strategic" in institutions). At the time I remember thinking a lot about how delays plus uncertainty meant death (nothing gets done, or worse). Even though Fast is often at the cost of noise and error, there is some principle that it can still improve things if not "too far".

Anyone know deeper writings on this topic?

Genuinely hard to read this and think little more than, "oh look, another justification for low quality software."

(Throw tomatoes now but) Torvalds said the same thing about Git in his Google talk.

Fast reading does not just enumerate examples.

Fast reading does not straw-man.

Fun conveys opportunity and emotion: "changing behavior", "signals simplicity", "fun". Fun creates an experience, a mode, and stickiness. It's good for marketing, but a drag on operations.

Fast is principles with methods that just work. "Got it."

Fast has a time-to-value of now.

Fast is transformative when it changes a background process requiring all the infrastructure of tracking contingencies to something that can just be done. It changes system-2 labor into system-1 activity -- like text reply vs email folders, authority vs discussion, or take-out vs. cooking.

When writers figure out how to monetize fast - how to get recurrent paying users (with out-of-band payment) just from delivering value - then we'll no longer be dragged through anecdotes and hand-waving and all the salience-stretching manipulations that tax our attention.

Imagine an AI paid by time to absorb and accept the answer instead of by the token.

Fast is better than fun -- assuming it's all good, of course :)