
Show HN: CoDiff, a new collaboration tool for developers - jtsiskin
A recent HackerNews comment - “For one programmer&#x27;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&#x27;s productivity?”  <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19339467" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19339467</a>
This is what we have come up with.<p>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. <a href="https:&#x2F;&#x2F;codiff.com" rel="nofollow">https:&#x2F;&#x2F;codiff.com</a><p>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.<p>This live code view leads to a many other productivity benefits. Existing tools will let you know your teammates&#x27; 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.<p>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.<p>We currently have the first <i>alpha</i> build available on <a href="https:&#x2F;&#x2F;codiff.com" rel="nofollow">https:&#x2F;&#x2F;codiff.com</a>. 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.<p>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!
======
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.

------
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](https://news.ycombinator.com/item?id=19591227)

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

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

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

------
indentit
The download button
([https://download.codiff.com/](https://download.codiff.com/)) gives me a
simple plain text response:

> Version not found: latest

perhaps its Mac-only?

~~~
jtsiskin
Hey sorry! What OS are you using?

~~~
indentit
Linux (Ubuntu 18.04)

