The CodeStream Blog

Fast error resolution is an important point of collaboration between development and operations teams. CodeStream 12.0 makes observability actionable for developers by bringing New Relic One into the IDE. Operations and dev teams can identify application owners quickly, easily work together to resolve critical production errors, and improve software performance with unprecedented ease and efficiency. 

With CodeStream 11.1 we are taking a first step toward eliminating the concept of a CodeStream “team” and moving toward a model similar to Slack where all developers from your company can be in a single CodeStream “organization.” The notion of a CodeStream team was introduced to help manage the signal-to-noise ratio in your activity feed, but there were some drawbacks. When larger companies onboarded there was a tendency for duplicate teams to get created, and time had to be spent getting everyone consolidated onto the proper teams. The team-based model also unnecessarily limited access to your company’s knowledge base on CodeStream. For example, if a developer on the “frontend” team is checking out some code in the api server repo, they wouldn’t see any of the codemarks associated with that code added by someone from the “backend” team.

The more our team used our CodeStream IDE extension for discussing and reviewing code, the more frustrating or inconvenient it became when we did have to leave our IDE for some development related task. So in addition to building our proprietary collaboration tools we also started working on integrating tasks into the IDE that previously required switching windows. But CodeStream is not the only VS Code extension that helps improve productivity by allowing you to stay in your IDE. Below are 5 other extensions our team uses to avoid window and context switches.

The headline of this article was conceived of by one of our engineers, @BrianCanzanella, during a brainstorming session to come up with a tag-line for CodeStream’s light-weight, pre-commit, pre-pull request (or pre-merge request) code review functionality. Many of us thought it was brilliant given all the frustrations developers voice over code review but, for whatever reason, it didn’t perform that well when used in the banner ad below. 

We wholeheartedly over the top agree that everyone should “review early and often” and “small reviews improve quality and avoid rework”, but not with necessarily equating code reviews with pull requests. Solving for more frequent reviews by suggesting smaller pull requests (or merge requests) reminds me of a famous quote (likely inaccurately) attributed to Henry Ford: “If I had asked people what they wanted, they would have said faster horses.”

More collaboration. Better transfer of knowledge. Increased team transparency. Earlier code reviews. These things are helpful to all developers on a team, but can be especially valuable to new hires. Here are four ways CodeStream accelerates onboarding.