HN Explorer

Show HN: CoDiff, a new collaboration tool for developers

26 points by jtsiskin ↗ HN
A recent HackerNews comment - “For one programmer's hourly cost, you could run 4000 CPU cores continuously. Can there really be no practical way to apply thousands of cores to boosting the programmer's productivity?” https://news.ycombinator.com/item?id=19339467 This is what we have come up with.

The current productivity tools - Slack, Asana, Trello, Facebook Workplace, etc. - are great, but lack direct access to your code. Building a tool directly around the code makes it more powerful for software developers: CoDiff. https://codiff.com

The foundation of CoDiff is a live-view of your teammates’ local Git repositories. This brings communication benefits that other productivity tools fundamentally cannot provide. Wherever you are working, you can essentially pull up a chair next to your coworker to see and discuss what they are working on.

This live code view leads to a many other productivity benefits. Existing tools will let you know your teammates' task, but not the exact lines of code they are modifying. CoDiff on the other hand, can notify you in real-time when you conflict with one of your teammates. This greatly reduces the time spent in resolving merge conflicts, prevents duplicated work, and unobtrusively improves productivity.

In the future, CoDiff will integrate with your favorite editors and other productivity tools for even greater benefits. A few examples: get conflict notifications in your IDE, set statuses according to Trello task, and share links to live code snippets on Slack.

We currently have the first alpha build available on https://codiff.com. It’s completely free now and we would be extremely grateful for anyone to try it out. We never touch your git repository - no extra branches or commits - we are read only.

We are looking for feedback at this point to help shape the future of the product–on the idea, the app, the workflow, or new directions. Anything you can share would be extremely helpful!

12 comments

[ 4.4 ms ] story [ 31.3 ms ] thread
joerromano
How much CPU/memory does this tend to use on large codebases or ones with a lot of unstaged changes? I'd be nervous about performance impact.
indentit
I can't help but wonder whether this could be solved more simply, allowing people to just use their normal git workflow and tools (with syntax highlighting etc) by just auto committing and pushing changes to a `wip_<username>` branch, then one can see the changes just by fetching from the remote as usual... I know the premise here is that it treats the repo as read-only, but IMO it loses a lot of power and transparency by doing so.
Terretta
Could even only “auto-commit” when the dev attempts to “run” locally, e.g., imagines they’ve got enough code entered to be a meaningful increment.
jtsiskin
This is an interesting idea! Although it may be tricky to know when something is 'run', but there are ways to solve that.

A use case we found useful was: while working, I can ping my coworker and say "I'm having some debate over the design of x, can you look at it when you have a chance?" and continue working on x. My coworker can then take a look at what I have even before I am in a state to compile and run.

marginalmingle
Has potential.. Definitely a need for this exists. Sometimes at work we share tmux sessions and give ssh access to each other on our developer machines so that we can easily pair on things. Vim is a great editor once you've customised it. Also check out space Macs
amirathi
Access to all/some contributor's local git repository is a powerful capability but you need to think deeply about 1 or 2 core use cases. "Pull up a chair" is only a surface activity, what's the user's real intent here? Is she trying to understand some part of the codebase or pair programming or debugging together? How can CoDiff help in that core activity?

To get you started here's something I would find useful,

- If I am starting to edit parts of the code that would create conflict with remote or peer's local state, just send us a notification. Much easier to avoid merge conflicts than resolving them.

Also think of developer psychology, e.g. I don't want peers to randomly peek into my WIP code. Things of that sort. Good luck!

jtsiskin
Thank you for this! It is very true we need to focus on 1 or 2 key features. The real intent of 'pull up a chair' is to be able to discuss WIP code together and help decide and debug. Working next to my coworkers I often show them my screen and ask them questions about what I'm currently doing; we hope CoDiff can give this ability to all teams, local and remote.

We agree completely with the first bullet point - that is one of our key features we have found useful. The second point is very interesting. What would you say is the reason you don't want peers peeking at your WIP code? We were wondering if it could be beneficial and have an effect similar to https://news.ycombinator.com/item?id=19591227

OriPekelman
Hi,

Really cool approach, but even for an alpha product I think it could be a very good idea to publish a security contact (there is no contact information at all on your home page).

I'll try a couple of blind addresses @codiff.com ...

Cheers..

jtsiskin
Yes, anything@codiff.com works! We added an email, thanks!