Hi, I’m Peter the CEO of CodeStream. I’ve been an internet entrepreneur for the last 23 years and I am very fortunate to have worked with the same management team during that time, with two eight-figure and one nine-figure exits under our belts. Commissioner.COM (now CBSSports.com) was the first to bring fantasy sports online. Multiply introduced the first social network news feed. And Glip, which launched the same month as Slack with a very similar product, is now the app serving RingCentral’s nearly three million paying customers. These three companies all had something in common, which is enabling group conversation and collaboration at scale.
Understanding code is one of the hardest problems in software development. At CodeStream, we think we have a novel approach to address this by first making it easier for developers to talk about code, and then capturing those code-based conversations and homing them where they belong -- with the code.
How we deliver the first phase of this functionality, and why we think it’s important, is outlined in the link above.
[sorry if you saw this yesterday; I had a glitch in posting it the first time]
We do plan to include what support we can in vim, given the limitations of the UI. It's certainly one of our most-requested editors.
Quick question on vim usage. Do you live in your terminal, and fire up vim, edit the file, and quit? Or do you leave your vim process running all the time (or nearly all the time)?
I live in the terminal, and fire up a vim instance when I need it (which is frequently). I probably have a few to a dozen processes at any one time depending on what I'm doing.
We are in planning stages for a new project, with everyone remote, this looks like a great way to keep the project moving forward and help with code review. Any ETA on VS Code availability?
You mentioned this "...the ability to talk about any block of code, on any branch, in any state..." Re: "any state." On our team, we'd love the ability to comment on uncommitted changes and share with the team, as it would prevent us from requiring short-lived feature branches. Is that ability available now?
Personally, it's been my (cynical) conclusion that a lot of times the bad-communication around code (e.g. lack of documentation/comments, resistance to PR feedback, closed architecture discussions), when it happens, can be attributed to motivations rather than lack of means.
But perhaps tooling provides more visibility around that and reduces the barrier for edge-cases.
there's one other aspect i've learned from having built and studied communications systems over the last two decades, which is that you shouldn't underestimate how many edge-cases there are when barriers are reduced.
in 2004 nobody shared photos of their lunch with their friends, not because it wasn't possible, but because it wasn't easy. last week i witnessed a teenage girl in a restaurant spend the entirety of a 30-minute dinner taking and sharing selfies. perhaps 100 in total.
it's my sincere hope that a reduction in friction gets us all talking about code more often.
Hi, thanks for building CodeStream, I'm working on a universal celebration platform (LinKedIn for celebration), but is a social value network not a social media network. Basically we don't see end user as a by product so is a different business_logic_$, the project is in stealth mode for now but it will be released shortly, probably 1Q_2019. Long story short we plan to use CodeStream and contribute to CodeStream mission, thanks.
24 comments
[ 3.7 ms ] story [ 57.6 ms ] threadUnderstanding code is one of the hardest problems in software development. At CodeStream, we think we have a novel approach to address this by first making it easier for developers to talk about code, and then capturing those code-based conversations and homing them where they belong -- with the code.
How we deliver the first phase of this functionality, and why we think it’s important, is outlined in the link above.
[sorry if you saw this yesterday; I had a glitch in posting it the first time]
We also plan to publish our marker API so that fans of a particular editor will be able to create a client, should they be so motivated.
PS. +1 for Webstorm support
React UI
Editor extension (initiates webview)
LSP agent
——cloud or on prem——
API/mongo
Hopefully this means most of the work happens in the three layers that are common across editors, and only the extension code needs to be ported.
Quick question on vim usage. Do you live in your terminal, and fire up vim, edit the file, and quit? Or do you leave your vim process running all the time (or nearly all the time)?
You mentioned this "...the ability to talk about any block of code, on any branch, in any state..." Re: "any state." On our team, we'd love the ability to comment on uncommitted changes and share with the team, as it would prevent us from requiring short-lived feature branches. Is that ability available now?
Personally, it's been my (cynical) conclusion that a lot of times the bad-communication around code (e.g. lack of documentation/comments, resistance to PR feedback, closed architecture discussions), when it happens, can be attributed to motivations rather than lack of means.
But perhaps tooling provides more visibility around that and reduces the barrier for edge-cases.
currently, all code comments are declarative, requiring you to pay into the system now, not knowing if anyone will ever benefit from your effort.
with question-driven comments, you get answers to exactly those parts of the codebase that aren't clear, as it should be.
well that's the hope anyway.
in 2004 nobody shared photos of their lunch with their friends, not because it wasn't possible, but because it wasn't easy. last week i witnessed a teenage girl in a restaurant spend the entirety of a 30-minute dinner taking and sharing selfies. perhaps 100 in total.
it's my sincere hope that a reduction in friction gets us all talking about code more often.