iparaskev

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.

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.

With a buddy of mine we have built Hopp, which is an oss pair programming app, https://github.com/gethopp/hopp. Feel free to pass by our discord server if you want help with self hosting.

This is nice suggestion. I created https://github.com/gethopp/hopp/issues/52. Feel free to add more info on how the ideal workflow would look like to you.

One of the maintainers here. Very good point. Yes we want (and need) to start doing this, we should open github issues so people can help if they want.

Thank you :) (one of the maintainers here)

One of the maintainers here. I am looking at improving this more. With av1 we can get even better latency at 4K, the problem is that it is not supported on Safari for old devices, so I am looking into getting the stream in rust and sending it to the frontend via a local ws server, surprisingly to me the added transport latency is less than 5ms.

This is a good point. Lately I have been experimenting with phrasing the question in a way that it makes it believe that I prefer what I am suggesting, while the truth is that I don't.

For example: - I implement something. - Then I ask it to review it and suggest alternatives. Where it will likely say my solution is the best. - Then I say something like "Isn't the other approach better for __reason__ ?". Where the approach might not even be something it suggested.

And it seems that sometimes it gives me some valid points.

The real breakthrough came when I stopped thinking of AI as a code generator and started treating it as a pairing partner with complementary skills.

I think this is the most important thing mentioned in the post. In order for the AI to actually help you with languages you don't know you have to question its solutions. I have noticed that asking questions like why are we doing it like this and what will happen in the x,y,z scenario, really helps.

After working with LiveKit for low latency screen sharing, I thought it will be a good idea of having a more detailed comparison of the encoders someone can use. I'm keen to hear your thoughts on the methodology I used and suggestions for future experiments.

We might have missed something here, but the `tauri://localhost` is the Webview memory in https://gethopp.app/blog/tauri-vs-electron#memory-usage, and the executable path is: `/System/Library/Frameworks/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc/Contents/MacOS/com.apple.WebKit.WebContent`. The measurements were taken on macOS.

I totally agree. If it turns out that we are getting too many bugs because of the different web engines, then we will ditch tauri for sure.