Oh yeah, back in the late 80s we (for some finite and not so big values of "we") were counting MOS6502/6510 cycles to catch the electron beam on a display and turn on some nice/nasty viaual effects.
Tell me "fast" again!
Fast
351–360 of 450 posts
Re: Fast
#352Earlier quoted context omitted.
As a counter example (re: agents), I routinely delegate simple tasks to Claude Code and get near-perfect results. But I've also had experiences like yours where I ended up wasting more time than saved. I just kept trying with different types of tasks, and narrowed it down to the point where I have a good intuition for what works and what doesn't. The benefit is I can fire off a request on my phone, stick it in my poc…
Thats cool, how are you integrating your phone with your Claude workflow?
My dev environment works perfectly on Termux, and so does Claude Code. So I just run `claude` like normal, and everything is identical to how I do it on desktop.
Edit: clarity
Re: Fast
#353Earlier quoted context omitted.
As a counter example (re: agents), I routinely delegate simple tasks to Claude Code and get near-perfect results. But I've also had experiences like yours where I ended up wasting more time than saved. I just kept trying with different types of tasks, and narrowed it down to the point where I have a good intuition for what works and what doesn't. The benefit is I can fire off a request on my phone, stick it in my poc…
Sounds like a slot machine. Insert api tokens, get something that's pretty close to right, insert more tokens and hope it works this time.
Except the tokens you insert have meaning, and some yield better results than others. Not like a slot machine at all, really. Last I checked, those only have 1 possible input, no way to improve your odds.
Re: Fast
#354Superhuman achieved their sub-something speed maybe (has anyone measured it except them? Genuinely, post a link, appreciated)
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.
Re: Fast
#355[dead]
Re: Fast
#356Earlier quoted context omitted.
The HN UI could do with some improvements, especially on mobile devices. The low contrast and small tap areas for common operations make it less than ideal, as well as the lack of dark mode. I wrote my take on an ideal UI (purely clientside, against the free HN firebase API, in Elm): https://seville.protostome.com/ .
Anyone who goes to the trouble of making their own HN front end is entitled to complain as much as they want, in my book! Nicely done.
It’s hilarious to me that I find this thread. I read the comment you’re replying to before I saw who wrote it. I exclusively read HN on iOS using https://hackerweb.app/ in dark mode precisely because I found it to be the most pleasing mobile experience. And here’s dang replying to my co-worker who commented that he wrote his own HN reader because the actual site isn’t the best on mobile. I could literally reach out my hand, show my phone and share my mobile HN experience with him, except I’m 99% remote. (But I did sit at his desk just last Thursday when he was remote.)
Just goes to show that all of us reading HN don’t actually share with each other how we’re reading HN :)
Too funny… thank you!!
Re: Fast
#357Earlier quoted context omitted.
Information density and ease of identification is the antithesis of "engagement" which often has some time on site metric they're hunting. If you can find what you want and read it you might not spend 5 extra seconds lost on their page and thus they can pad their stats for advertisers. Bonus points if the stupid page loads in such a way you accidentally click on something and give them a "conversion". Sadly financial…
The one and only thing I'd do is make the font bigger and increase padding. There's overwhelming consensus that you should have (for English) about 50–70 characters per line of text for the best, fastest, most accurate readability. That's why newspapers pair a small font with multiple columns: to limit number of characters per line of text. HN might have over 100 chars per line of text. It could be better. I know I c…
I’d very much prefer more padding between the clickable UI elements on mobile in particular, because the zoom in -> click upvote -> zoom out, or the click downvote by accident -> try to unvote -> try to upvote again, well, it gets pretty old pretty fast.
The text density, however, I rather like.
Re: Fast
#358Just want to say how much I thank YCom for not f'ing up the HN interface, and keeping it fast. 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 impossibl…
What changes have been made to the HN design since it was launched? I know there are changes to the moderation that have taken place many times, but not to the UI. It's one of the most stable sites in terms of design that I can think of. What other sites have lasted this long without giving in to their users' whims? Over the last 4 years my whole design ethos has transformed to "WWHND" (What Would Hacker News Do?) ev…
Slashdot looked a lot like HN with high information density. It was fast and easy to read all the comments. Then a redesign happened because of web 2.0 or "mobile-first" hype and most of the comments got hidden/collapsed by default, sorted almost randomly etc. So a new user would come there and say "wtf this is a dead conversation" or would have to click too many times to get to the full conversation. So new user would leave, and so would the old ones because the page was so hard to use. It just lost users and that was that. All because of the redesign which they never wanted to revert. Sad really because I still think it had/has the best comment moderation by far.
Re: Fast
#359Kinda funny but I think LLM-assisted workflows are frequently slow -- that is, if I use the "refactor" features in my IDE it is done in a second, if I ask the faster kind of assistant it comes back in 30 seconds, if I ask the "agentic" kind of assistant it comes back in 15 minutes. 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 min…
I'm consistently seeing personal and shared anecdotes of a 40%-60% speedup on targeted senior work. As much as I like agents, I am not convinced the human using them can sit back and get lazy quite yet!
That sounds plausible if the senior did lots of simple coding tasks and moves that work to an agent. Then the senior basically has to be a team lead and do code reviews/qa.
Re: Fast
#360Earlier quoted context omitted.
Thats cool, how are you integrating your phone with your Claude workflow?
My dev environment works perfectly on Termux, and so does Claude Code. So I just run `claude` like normal, and everything is identical to how I do it on desktop. Edit: clarity
Do you use it on a phone or on a tablet?