Forem: Michael Gersh

CodeStream Case Study: Hearst Communications

Michael Gersh — Mon, 11 May 2020 14:58:02 +0000

Overview of Hearst Communications

Hearst is a leading global diversified media, information and services company. Its major interests include ownership in cable television networks such as A&E, HISTORY, Lifetime and ESPN; global financial services leader Fitch Group; Hearst Health, a group of medical information and services businesses; transportation assets including CAMP Systems International, a major provider of solutions for managing maintenance of jets and helicopters; 33 television stations which reach a combined 19% of U.S. viewers; newspapers such as the Houston Chronicle, San Francisco Chronicle and Times Union; more than 300 magazines around the world, including Cosmopolitan, ELLE, Men's Health and Car and Driver; digital services businesses such as iCrossing and KUBRA; and investments in emerging digital entertainment companies such as Complex Networks.

The Challenge

Heart’s front-end site rendering team of 20 engineers builds and maintains a platform that powers the customer-facing experience for 175 online magazines. The team uses multiple tools for communicating and sharing information, including Slack, Jira, GitHub pull-requests, and email. In addition, the team is mostly distributed across the US, and from time to time they work with international teams as well, where the ability to share information contextually is even more important.

As the team became larger, important conversations about the code were scattered across their various development tools and systems. It was becoming increasingly common for team members to misunderstand a key decision because they could only see part of the discussion, or altogether miss key conversations and information exchanges. They needed a solution to consolidate team communication and make information about the code readily accessible to all team members. Enter CodeStream.

The Hearst Front-End Site Rendering team derived the following benefits from CodeStream:

The team uses CodeStream as the central communications hub for their several development tools and systems.
The speed of getting questions answered has greatly accelerated. Previously, an engineer would have to go to the source code to share or understand context. Because CodeStream links comments and discussion to the code they refer to, the friction and overhead are completely eliminated.
CodeStream’s latest in-IDE code review feature has given the team a fast and easy way to request early feedback on new code, so work-in-progress is being reviewed even before being committed or pushed. This reduces the chances of a team member going down a coding rabbit hole that could cause painful re-work later in the cycle.
Overall, the team is better aligned, communicating about the code earlier, and code quality has improved.

The Bottom Line

“Great communication is essential for any software development team, but as your team grows, sharing key information about your code simply becomes harder to do. Important conversations become fragmented across different tools and systems, and for teams with remote workers, this is even a bigger problem. For our team at Hearst, CodeStream is the missing tool that helps engineers discuss and review code earlier and more often, and it saves that information alongside the code where it matters most. No tool is perfect, but I give CodeStream 9 out of 10.”

‍- Alfredo Lopez, Director of Engineering, Hearst Communications

SUKU: Using CodeStream for Code Review, Easier than Pull Requests

Michael Gersh — Mon, 06 Jan 2020 16:18:42 +0000

Overview of SUKU
SUKU is a blockchain solution used by companies to drive efficiency, transparency, and ultimately bring an institutional level of trust to the consumer-brand relationship. SUKU’s platform employs an on-demand, open, decentralized software distribution model which consists of applications and services that are utilized by various participants. These applications are intended to be built with technology partners in a continually evolving ecosystem.

The Challenge
Engineering managers for global companies like SUKU commonly face the challenge of how to efficiently review code when working with offshore development teams. The challenge stems from the significant time zone differences between the teams, which was 11.5 hours for the SUKU team. The offshore team primarily relies on Slack for communications, but engineering management was seeking a more contextual way to communicate during the code review.

How the SUKU Team Uses CodeStream
As a project release to address a user story nears the end of the development cycle and enters QA, an engineering manager or development lead will check out the branch and review the code using CodeStream.
CodeStream allows the manager to review the code in his or her IDE and leave comments alongside the code, much in the same way as you can use the comment function in Google Docs to mark up a shared document.
SUKU leverages CoderStream’s Slack integration, so the developers receive the reviewers’ comments via Slack, and they can respond directly from Slack if they have questions.
When the code review cycle is finished, comments can be archived or deleted if they are no longer relevant, or they can be kept alongside the code if they provide lasting value as a form of documentation.

The Bottom Line
“Using CodeStream for code reviews is easier than using pull requests. It’s as simple as checking out a new branch and leaving comments alongside the code in my IDE, like you would comment on a Google Doc. CodeStream handles delivering my comments to the developers via Slack with all the related code snippet and location information they need to resolve the issue. CodeStrream has shortened our code review time by around 25%, which enables us to work more efficiently while maintaining quality.

Bryce Doganer, Blockchain Engineer

iManage- Reviewing Code Earlier to Improve Code Quality

Michael Gersh — Thu, 19 Dec 2019 19:29:40 +0000

Overview

iManage is a leading provider of work product management solutions for law firms, corporate legal departments, and other professional services firms such as accounting and financial services companies. iManage helps these firms serve their clients more effectively by improving productivity and governance throughout the creation, sharing, and security of work product. iManage is trusted by over 3,000 professional services organizations and one million professionals worldwide.

The Challenge

Engineering managers on the iManage Collaboration Project Team were seeking options for improving code quality and team productivity. One idea was to find a way to review code and provide feedback earlier in the development process, so they could find and fix small issues before they grow into larger problems. Traditional code review based on PR comments is cumbersome and not well suited for this lightweight approach.

How the iManage Collaboration Project Team Uses CodeStream

Each developer on the team pushes his or her feature branch daily, and the team leads use CodeStream to highlight specific areas for discussion and leave feedback alongside the code so they can work on it the following day.

This feedback is highly contextual - viewable alongside the code in the developers’ IDE much like a comment in a Google doc, so it’s easy to identify sections of the code that need work and read the reviewer’s suggestions for making improvements.

The team is now reviewing code earlier and catching issues sooner, rather than waiting to the end of a cycle when there is more resistance to major rework that could impact the schedule. This results in better code quality and less technical debt.

Once issues are resolved, CodeStream makes it easy to manage the information that came from the feedback process. The team can simply resolve comments that are no longer relevant to free up screen real estate or choose to leave comments permanently linked to the code if they believe they will be valuable over time.

The Bottom Line

“We were looking for a simple and intuitive way to supplement our code review process with earlier feedback for our developers. CodeStream makes it easy to identify problems and leave clear suggestions and instructions alongside the code in the IDE. CodeStream doesn’t replace your formal code review process, but it does make it faster and easier. Our code quality has definitely benefited from using CodeStream in our workflow.”

-Arvind Agarwal, Head of Engineering, iManage Collaboration Project Team

Coformatique: Using CodeStream for Real-Time Code Review with Remote Teams

Michael Gersh — Thu, 14 Nov 2019 19:27:01 +0000

Overview

Coformatique uses CodeStream to facilitate more effective and efficient peer code review between remote development team members.

Company Background

Coformatique is a software development company using the latest platforms and technologies to create innovative mobile and web applications for its clients. The company specializes in designing and developing new applications and MVP products. Coformatique has executive leadership and sales personnel in Europe, while the development team is located in Cairo, Egypt.

The Challenge

Peer code review using pull requests is a common method for monitoring and improving code quality. Coformatique, however, realized that using pull requests alone is a cumbersome and inefficient approach to code review because the discussion is limited to only the specific lines of code being committed at that point in time. This limitation is particularly acute when developers and reviewers are in different locations and can’t simply spin their chairs around and discuss issues with the code. Coformatique was seeking a faster and more flexible approach for remote peer review to identify and avoid potential problems as early as possible in the development cycle.

Why Coformatique Likes CodeStream

CodeStream gives reviewers and developers a simple way to highlight and comment on any code visible in the IDE, even lines that have yet to be saved or committed, so you don’t need to be physically in the same room with your colleagues to feel like you’re working closely with them.
CodeStream is fast, delivering comments and messages swiftly between reviewers and developers, dramatically accelerating the rate at which you can discuss and review code together.
CodeStream’s integrations with Slack and Microsoft Teams gives Coformatique’s developers the freedom to use their favorite IDEs to write and review code, while remaining connected through a single shared communications platform.
The ability to display historical pull request comments in the IDE means that Coformatique can leverage past practices in combination with CodeStream’s real-time code review capabilities.
CodeStream feels like it’s part of the IDE. It doesn’t make you stop to think about using yet another development tool when it’s time to review code.

The Bottom Line

“The fact that you can be on the phone with a remote colleague, or sharing your screen, or messaging over Slack - while using CodeStream to highlight and review code is the core benefit we get from CodeStream. CodeStream is powerful because it is simple to use and it does this one thing really well for us. I’d recommend CodeStream as a better way for any software team to review code, but especially to those with remote developers.”

                   - Osama Abdelmoghni, Founder and CEO

CodeStream for JetBrains is Here

Michael Gersh — Tue, 16 Jul 2019 14:31:16 +0000

CodeStream is now available for the JetBrains family of IDEs!

CodeStream make it easy for developers to review, discuss, and understand code. Conversations about code are saved with your code, so that a knowledge base builds up over time, with zero additional effort. Watch the following short video to see how all of this magic happens right inside your favorite JetBrains IDE.

Confessions of a First Time VC

Michael Gersh — Thu, 06 Jun 2019 14:20:32 +0000

Mr. Andrew Miklas co-founded PagerDuty, Inc. in 2009. He joined S28 in December 2017 and serves as a Partner. Mr. Miklas holds a BSE in software engineering from University of Waterloo from 2001-2006, and an MSc, in computer science from University of Toronto in 2006-2008.

Claudio Pinkus: Thanks for taking the time to talk to me today. The first question is what is it that you think makes for successful companies? What are the most important ingredients? Please narrow it down to the essence.

Andrew Miklas: I think the traditional answer - “founders, market, and product” - is pretty close to the right one. More specifically, my partners and I have a theory that for any successful startup, there are probably only seven or so unique factors that drive its success.

Those things will be different for different businesses, though they will relate back to the general “founders, market, and product” trinity I mentioned above. To give an example, at PagerDuty, I believe one of them was the way we became positioned as one of the flag bearers for DevOps – a movement that swept through the engineering community starting in around 2010. Another was our focus on putting the practitioner first in our marketing message & product design in an industry where that often wasn’t the case.

CP: What do you mean when you say that those things drive a business's success?

AM: Our belief is that businesses do well based on the strength of those few special observations or ideas baked into them at their start, and are therefore surprisingly resilient to problems outside of those things. Put another way, a whole lot can go wrong and a whole lot of mistakes can be made as long as the seven things or so things that are “right” about a business continue to be true.

CP: You’re suggesting that even if you have a great team, if you are swimming upstream you’re going to be facing obstacles that you don’t need to face had you picked a market that is secularly moving in the right direction?

AM: Exactly. When I see a company that is targeting a market I perceive is shifting to something else I ask what the market might be like in ten years. People say stuff like “there’s still of lot businesses like X so it will make sense to target that.” The start-up might be making millions of dollars targeting that industry. I’m very reluctant to invest in that. I’d much rather invest in something where I feel like there’s a story for where it’s going to be bigger in the future, even if revenue and metrics in that business are much smaller today.

CP: How long have you been a VC?

AM: I’ve been investing personally for a couple of years, and started investing professionally last year.

CP: You were an entrepreneur for a long time and now you have a very different hat on as an investor? How is that transition?

AM: It’s still kind of weird. When I talk to people they’ll say “oh you work finance?” I still think of myself as a technologist and engineer who just happens to be investing. One of things that’s very different right now that I’m still getting used to is depth versus breadth. As an engineer all you do is think about one very particular problem. As an investor it’s completely flipped. You’re expected to have a great deal of breadth to understand many industries. As an investor the idea is that you’re able to piece together what’s going on across many areas of the economy, but what happens is when you’re talking to somebody you very quickly run off the end of your understanding their particular zone.

The way I used to work, if there was something I didn’t understand I’d just lock myself in a room for 3 hours and study or play with it. Figure out how this new library works just by doing. That doesn’t work as an investor. There’s not enough hours in the day to do that.

Another shift that I’ve started to get a little more used to is the feedback cycle for investing. When you’re working on a company you find out very quickly if you’re doing the right things. You have this agile process - you try something, put it in the market, and if it doesn’t work you try something different. With investing it takes years to understand if you’re any good at all. That’s sort of a disconcerting feeling for me.

CP: I totally get that. I cook every evening. And sometimes I'm asked why I do that even when I am busy. I could be doing something else with my time. The answer is that I spent so many years investing in long term things that I needed something more immediate that gives me short term results to feel a certain level of satisfaction. (laughs) And you can just chop something up and throw it in the oven and an hour or two hours later, you eat it. And that feels like the immediate gratification that investment does not give you.

AM: Yes. Definitely not. Another difference is that as an engineer I had this drive to systematize and construct. I’m not going to solve this problem just once, I’m going to figure out how to do it repeatedly and build a system so that I don’t have to do this again. I sort of initially approached investing the same way. When you go to raise your next fund, you want to be able to say “here’s what I did and here’s how I know I can do it again.” But I’m also realizing how resistant the the field is to that. So much really is just dependent on happenstance. Everyday is so different. The companies you’re seeing are so different. It doesn’t lend itself to automation or systematization that an engineering mindset sort of creates.

CP: It kind of ties back to what you said to start with. Which is, if your most important criteria for deciding to invest in a company is that it's on a good market trajectory, then it follows that all kinds of other things are just dependent on whether you found something that has the potential to become a big thing because of its market. Even an average company in a good market is better than a great company in a shitty market.

AM: Yes. Yeah for sure. Even when you ask, what specifically about this opportunity, this investment opportunity makes you drawn to it. I try to talk with other investors and ask: what is it that you see here? Or not see here? And I try to predict what they're going to say. And it's very hard because I don't even know if in their minds they have a clear framework for how they look at things. And at the same time, I don't think it's all luck. It's not like I'm sitting here saying the great investors just get lucky time after time. But whatever it is they're doing, at some level, defies pure systematization.

CP: As a former co-founder of PagerDuty, what would you advise founders at the early stage of their company to focus on? What’s most important to their success?*

AM: Number one, it’s building a team. You need a good co-founder and the question is what are you looking for in a co-founding team? Things like a complementary skill-set, working well together. Respect for one another without the cagey stuff that feels like you can’t question one another. There’s a very careful balance. You need to really understand why you’re solving the problem that you’re trying to solve and why the team is uniquely suited to doing so. A team of two engineers who only worked on writing code in their life may have a business plan that is going to require conducting million dollar plus sales to a bank. That can be very difficult with their skill set. Also, do they have the right blend of perseverance and flexibility. You want people who aren't going to give up at the first sign of resistance, but you also don't want someone who's going to be like, "This is the way that this problem needs to be solved and I am solving it this way and it doesn't matter what anybody tells me."

CP: What you’re pointing to is that you’re really creating a culture that is going to permeate your organization if you’re successful. Perhaps you know what that is. Perhaps you don’t. But it’s happening anyway.

AM: Yes. What becomes the culture are the points of commonality between the founders that they don’t necessarily even realize that they have, because they’re the things that you don’t talk about. When you hear people at an early stage company start to talk about culture it’s usually something aspirational. Much later on at an organization, maybe even after the founders have left, you try to ask yourself what’s different about this place? You trace it back to the founding team. It's the things that the founders would have never thought to call out as something. Because it's so baked into how they operate that it almost doesn't seem worth talking about.

CP: Let’s shift to something different. Macro trends. What do you feel are the macro trends that are driving growth today?

AM: Essentially, how the automation or optimization of industries through software still has a very, very long way to go. It’s not anywhere near done. One of our portfolio companies, Social Construct, is looking at how to build interiors of apartment buildings more efficiently. They're almost applying software engineering workflow principles to the process of construction. That is an amazing idea, and an amazing approach that they're taking, by essentially taking software into businesses that historically have not had it.

CP: It seems that software development is still too much of an artisan type of job. I think that there is a lot of time wasted on things that could be automated and we end up with situations where the tools that software developers are using continue to be less efficient than the tools that they make for their customers. As in “The barber has the worst haircut in town.” What is the right balance and where do you draw the line between creativity and automation?

AM: There's an aspect of software development that's almost accidental, basically. It's just a result of the interactions between the tools: the tooling and the language choice you're going to use, how the database interacts with this other database and all that. To me, those problems are actually the ones that are right for better tooling to reduce.

It used to be that there’s a distinction between software engineers and systems analysts. Those fields have come closer together. Software engineers are no longer sitting there hand assembling flow charts. Now software does that. There’s software that handles a lot of operational aspects. Whereas before you used to have assistance wiring computers together, now we have AWS, and we’re actually moving on top of AWS again with layers of extraction where you don’t really perceive there being an actual system beneath it. Going back to the original question, when I look at developer tools or operation tool companies, it's about understanding “What are those things for other people?”. Specifically, our software engineers' minds have to focus on the sort of intrinsic complexity of the problems they're working on, rather than the dealing with how to actually make the thing work.

CP: How are things different today than they were a decade ago?

AM: A decade ago AWS was just a few years into its run. You had the ability to pay by the hour for hosting but you didn’t have these higher levels of abstraction. The amount of effort it took to get a startup off the ground was definitely less than a decade before, and certainly cheaper than a decade before that, but still not as easy as I think it is today.

Another big change is the way capital is raised now, especially in the early stages. It is pretty different than what I was used to. You got a bunch of angels together, maybe you got a seed investment, and then that was kind of it. Twelve to 18 months later, you had to do a Series A or you wouldn't, and that was that. Now, the when and what that goes on in the pre-A stage of financing is much more fluid. You have small seed funds, big seed funds, companies that do one seed and then do another seed, then maybe another seed, and it's just a more fluid process as to what's going on in there. Once you hit 'A' things sort of settle out more similar to how they'd worked traditionally.Another big difference from seven years ago is how much bigger A rounds are!

Another change is that people outside of tech have an opinion on tech, and I don't know that that was happening 10 years ago. Maybe it was happening during the first dot-com bubble; I wasn't here for that. But now it seems there is much more - I almost want to say tech is a power to be reckoned with. Google and Facebook and all these guys were considered reputational-y in a positive light. There's sort of this shift that's happening where they're almost now - People talk about Google and Facebook like- I'm going to say 'big data', or perhaps 'Big tech', right? In the same way they talk about 'big oil' or something like that. It's weird to see these things, in some sense, see yourself, realize that other people see you kind of as the villain. That wasn't true 10 years ago.

CP: Definitely wasn't, but they were thinking about it because Google would not have chosen 'don't be evil' as their motto, otherwise.

AM: That is true. It wasn't as pervasive. You didn't open the New York Times and read three articles about how ‘tech is going to destroy democracy' every day, right? Now as the technologist, I'm thinking about these things. Did we actually build things that are going to be not net-positive for the world?

CP: I think we already have. The only question is, is it something that's irreparable? Some damage was done by us, too, to at least parts of what's considered to be valuable in society.

AM: An example is the almost behavioral modification thing that happens, especially in consumer products like smartphones where you're pushing engagement at the expense of everything else, and it almost retrains people’s' minds. I used to have a longer span of attention than I do today.

CP: We'll see how we can somehow contribute to the improvement of those situations.

AM: I think that would be a good area for investment work or something. I'm sort of on the lookout for companies or groups of people thinking about this problem space.

CP: Last question. You’ve invested in CodeStream. What is it about the opportunity do you find most compelling?

AM: There’s multiple answers here but the strongest one - When software engineers build software, there's the actual code that they produce, and then there's the mental processes that go on in their head, and that framework, about what they did and why they did it and how to extend to all of that. The difficulty is that software engineers typically are coming and going between companies, basically switching jobs every 18 months, and when they leave, you get to keep the code, but you don't get to keep what was going on in their head. Whoever comes takes over the code, you now have to figure out how to get to what was going on in one person's head into the new guy's head before they can really start to produce code themselves. We obviously know how to capture the actual source code. I’m hoping that CodeStream will be able to capture and transfer more of what’s going on inside the engineer’s head, if that makes sense.

CP: It does. As we tend to say, we are about the ‘why’, and to the extent that we can capture the ‘why’, we’ll be answering a lot of WTFs along the way.

Thank you very much for your time.

AM: You as well.