boredtofears

> Both DuckDuckGo and Kagi are, purely focused on result quality in 2025 far better than Google currently

I wish this was true

Maybe, but this isn’t one of the ways it does.

> For instance you’re probably iterating over those six plans and inserting them individually in the DB. Another approach would’ve been to accumulate all of them in memory then build and perform a single query. That’s not something people really consider because it’s “micro” optimization and makes the code look worse.

This same pitfall exists in every language. This has nothing to do with Ruby.

I have to spend 3 days working on someone else's "narratives that are more fun to apply their creativity to" all the time, even when my intuition and experience tells me it isn't a good idea. Sometimes my intuition is wrong. I've yet to meet a product manager that isn't doing this even when they claim to have all the data in the world to support their narrative.

Personally I don't think there's anything wrong with scratching that itch, especially if its going to make you/your team more comfortable long term. 3 days is probably not make-or-break.

Both 4k and 120hz were very noticeable improvements imo.

Of course you did - thanks, huge fan!

Is there an easy way to get a whole codebase into GPT 5 Pro? It's nice with claude to be able to say "examine the current project in the working directory" although maybe that's actually doing less than I think it is.

I like the best of both worlds approach of asking Claude to refine a spec with me (specifically instructing it to ask me questions) and then summarize an implementation or design plan (this might be a two step process if the feature is big enough)

When I’m satisfied with the spec, I turn on “allow all edits” mode and just come back later to review the diff at the end.

I find this works a lot better than hoping I can one shot my original prompt or having to babysit the implementation the whole way.

I've never worked at a place where I have any shortage of work to do. Usually the roadmap is several years out.

Or you keep your team of 10 and produce more things.

I get so many LLM death spirals with playwright.

When it works, its totally magic, but I find it gets hung up on things like not finding the active playwright window or being able to identify elements on the screen.

Any idea what people have generally moved on to? Currently using jest but its definitely showing its warts often and is pretty slow. Curious if there is an obvious successor.

I haven't shipped to a shared host since the 00's. We deployed to isolated VMs a decade before docker.

I wonder if we’ll start seeing things like more powerful eGPU’s built into the docking area.

This mirrors my experience with AI so far - I've arrived at mostly using the plan and implement modes in Claude Code with complete but concise instructions about the behavior I want with maybe a few guide rails for the direction I'd like to see the implementation path take. Use cases and examples seem to work well.

I kind of assumed that claude code is doing most of the things described this document under the hood (but I really have no idea).

Woah, I did not know about this installable web app feature - this is a game changer. Thanks for sharing.

This is what I mean - even opinions on domain are wildly different. I've seen people say Claude's React is best.

What I find interesting is how much opinions vary on this. Open a different thread and people will seem to have consensus on GPT or Gemini being superior.

Even the bench marks don’t seem all that helpful.

who are these mythical jr devs and where do i find them

i just want devs who actually read my pr comments instead of feeding them straight into an llm and resubmitting the pr

I had problems with prop drilling on early projects but since Context has been around it hasn't been an issue. Never bothered with all these state management libraries, any time someone on my team has tried to sell me on it they've never made a strong case for it over simple proper react state management. useEffect took a little getting used to - it becomes much less problematic when you learn which scenarios to use it in (fewer than you initially think). I've had to use React.memo() at times, but it's usually done in a simple optimization pass not unlike something I'd do in a backend framework.

The only time I am even aware of these problems is when I stick my head into the javascript frontend framework "scene" where everyone acts like each one of these are dealbreakers and they happen constantly all the time.

Life is actually pretty easy as a React dev, it's a well polished and at this point battle tested framework. I wish the other tools in my dev stack were as easy to deal with.

I just logically group tabs into the same terminal window. All OS's have hotkeys for switching between tabs and windows.

To throw gasoline on the fire: this how I’ve always felt about tmux. Why use an incomplete in terminal windowing system when I can just have multiple terminal windows open managed by the superior OS window system.

(That said I know tmux is sometimes the only option and then it makes sense to me)

At my work were replacing administrative interfaces/workflows with an MCP to hit specific endpoints of our REST API. Jury is still out on whether or not it will work in practice but in theory if we only need to scaffold up MCP tools we save a good chunk of dev time not building out internal tooling.

You mean the same kids that are currently cheating their way through their education at record rates due to the same technology? Can't say I'm optimistic.

On that note, the font isn't symmetrical and the bar graph itself uses jagged lines. This makes it hard to read and much less precise. I'd prefer all websites in monospaced fonts with only the straightest of lines.

How so?

> you'd have to spam debug printfs all around you expect this chain to happen to replace the debugger which would waste time

It's not wasting time, it's narrowing in on the things you know you need to look for and hiding everything else. With a debugger you have to do this step mentally every time you look at the debugger output.

And just like the rule that it replaced, the rule of three is now often interpreted as the "correct" approach always, while I still find reality to be more nuanced.

Sometimes you do have the domain expertise to make the judgment call.

A recent example that comes to mind is a payment calculation. You can go ahead and tie that up in a nice reusable function from the get go - if you've ever dealt with a bug where payment calculations appeared different in some places and it somehow made it in front of a customer you're well aware of how painful this can be. For some things having a single source of truth outweighs any negatives associated with refactoring.

I’ve been bottlenecked by that middle part quite often. A design isn’t finished, we’re awaiting user feedback or testing, specs are done but waiting for sign off from required parties, etc..

I’ve never had a shortage of work as an engineer, but that doesn’t mean that work has always been perfectly optimized to business priorities - there’s plenty of other bottlenecks in the process that are not coding.

A fully curated backlog with complete specifications that is kept up to date with current changes in the product/industry? I've never had the privilege of working in an environment like that.