iparaskev

Feel free to try Hopp[1], which supports self hosted backends without having to rebuild the client. Selfhosting takes literally less than 5 minutes.

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

(disclaimer I am one of the maintainers)

I almost missed my metro stop because I couldn't stop reading.

I agree that in the end the most important thing is to have the correct mental model of the code, and there is no need to know every implementation detail if you can ensure with other means that they address your requirements. An issue I can can see with not reviewing the code (especially code someone else wrote) is how do you create the mental model? Can a design.md file replace the process of slowly understanding the data flow by reading?

He is the creator of redis.

Have you tried using a purpose built pair programming app? Essentially these are tools with low latency screen sharing and remote control. Then you can pair-prompt in a call.

I think it doesn't really matter if the fund manager was committing a fraud. The author had fun, met their spouse and just enjoyed life with the information they had at that point.

Still working on Hopp, an oss pair programming app. A few months ago we ported part of the frontend in rust, to work around the webrtc limitations imposed by webkit (Hopp is written in tauri), which caused some stability issues. Now the app is more stable again but we are still making improvements and fixes.

https://github.com/gethopp/hopp

Hi! Seeing how many maintainers and repos have issues with PRs made by bots, we decided to do something, and we started building cherry.

We are doing a private beta and we'd love to hear your thoughts on how to solve this without discouraging legitimate junior developers. What kind of heuristics do you currently use manually that we could automate?

The hobbit!

> Biggest risk I've found building solo with AI isn't bad code — it's accepting plausible code without interrogating it

Totally agree. While I am aware of the danger, sometimes I become lazy and something slips.

> Adding AI to the mix might make it a harder sell, not easier.

100%. I think teams that already pairing could try something like this.

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.

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.

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)

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 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.

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.

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.