Working on migrating Hopp's [1] overlay window, which we use for drawing the remote cursors, from winit + wgpu to gpui. I used claude in the weekend to make a prototype and now I want to make a gpui app, which will replicate all of our requirements, in order to see what is missing and if I need to contribute upstream. I am planning to write a blog post when the migration is over.

[1] https://github.com/gethopp/hopp

OP here, I didn't write the post, but found it interesting and posted it here.

> So i understand correctly, they spend more even thought They can, optimize and spend less

This is what I understand as well, we could utilise the hw better today and make things more efficient but instead we are focusing on making more. TBH I think both need to happen, money should be spent to make better more performant hw and at the same time squeeze any performance we can from what we already have.

What is your setup when pairing remotely? (Full disclosure I am building an OSS app for this purpose and just want to learn what is working for people)

Our team uses IntelliJ so we use Code with Me with Slack for AV. Specifically on Slack we have channels called pairing-room-1, pairing-room-2, etc. Allows colleagues to drop in and out.

I would try Tuple but to be honest we are fine on Code with Me.

Not OP, but Tuple is pretty great.

Indeed Tuple is a great product. The goal is to match their quality and make it the OSS alternative, it's still early though, and I am trying to get some feedback.

With zed you can also share your screen in the editor which makes it a bit better, but still you can't take control of the other machine.

IMO if you only care about coding doing it in the editor is the best approach, you get zero latency and have all the context that you need (most of the times). But if you want to do more, like opening the browser for whatever reason, or teaching how to use a specific cli, etc, then taking control works better.

If you liked pop you might like gethopp.app, which is an OSS pair programming app (full disclosure I am the co-maintainer). Unfortunately because we have chosen tauri for the frontend we can only support macos and windows, but I am working on a solution for Linux too.

While I like rust and use it for my own projects I agree 100% with you. No reason to replace sw that has been working perfectly for many years.

I also like Rust but I honestly don't understand why they are desperately replacing battle tested production quality sw for alpha quality ones. It is insane.

I see your point and I agree that pair programming code reviews give a lot of value but you could also improve and learn from comments that happened async. You need to have teammates, who are willing to put effort to review your patch without having you next to them to ask questions when they don't understand something.

> this kind of interview is way harder to set up

This is a good point.

I will add a note in the post to highlight this.

This is good point. I thought of including this but decided against it at the last minute. I will update the article to briefly mention this, because I also think it is becoming a problem. Thanks for the suggestion.

This is a valid point. But I think there is merit on working for a few days with a potential hire in order to see how good of a fit they are to you and you to them. You reduce the chances of having a false positive hire.

Intuitively I agree with this too. I would love to see results from other companies as evidence it’s correct, is all

I agree that is hard to remember every little detail for every project you have worked on, but I can definitely recollect how I approached the biggest problems on almost every project. Usually these are the ones worth talking about.

That's nice and all, but you sound young (less than middle aged) if that's the case. Get 20-30 years of projects under your belt and try that, lol. Anyway, cherish it while you can, and have some empathy for those that no longer can, please and thanks!

I would have to think a really long time to come up with an answer to “describe a hard problem you’ve solved” at all. I might have to consult notes. After that, to make it an interview-friendly narrative, I’d have to fill in a lot of details with plausible speculation because god knows I don’t actually remember (and I don’t really trust memory very much, anyway)

The joys of age plus extremely-poor autobiographical memory.

It doesn’t help that what I think of as actually hard, day to day, is shit like documentation from FAANG companies lying to me and wasting a whole fucking day of my time, terrible error messages, mismanagement of upstream projects, bureaucracy making a two-day task take four weeks, and, in some common ecosystems, awful design of core tools and major libraries, or horribly wasteful library churn. “Hard problems” are nothing next to bullshit problems.

My career isn't long, about five years, but so far I haven't encountered a technical problem that wouldn't be trivial. Like, "just follow whatever ChatGPT says" trivial. The real challenge are people problems - corporate work teaches you that the real tough shit is surviving being surrounded by idiots.

Not a lot comes to mind that really falls between “basically trivial” and “you’re gonna need to hire a team of PhDs” or “you have accidentally asked me to write a custom distributed file system, and you probably don’t want to pay for that”

Which is to say that usually the hard stuff is an accidental request that nobody actually wants to pay for, so the only thing “hard” about it is recognizing that the client/stakeholder has wandered into territory they really ought not.

Yes you are certainly right that it will be much harder the more years of experience you have.

That said, I think that someone could remember a few things for past projects when preparing for an interview. Of course doing that on the spot might be very hard.