Forem: Brandon Hopen

Human-Centric Code Reviews

Brandon Hopen — Tue, 26 May 2020 16:47:37 +0000

Code reviews can be a great opportunity for software development teams to learn, mentor, and collaborate with one another. However, they can quickly become cumbersome if colleagues are not thoughtful with one another in how they communicate feedback during the process. All too often teams focus on providing the best technical guidance to developers while ignoring the psychology on how to deliver feedback. Ideally, the code review process touches upon elements of the psychology of the team as well as the technical workflows. Microsoft, for example, has implemented a number of strategies for providing feedback that includes a mix of both of these considerations. A code review model that fails to utilize feedback mechanisms on how team members actually learn and absorb information can risk jeopardizing team chemistry in the middle of a sprint.

Here are some best practices we recommend to increase the effectiveness of providing feedback during code reviews:

1. Conduct code reviews more frequently: provide rewards for completing more tasks

According to a study at Cornell, “people who received immediate, frequent rewards for completing small tasks reported more interest and more enjoyment in their work, compared with people who received delayed rewards only given out at the end of a long project.”

Institute a regular practice of developers submitting smaller, bite-sized code reviews frequently rather than waiting at the end of a process for feedback. If managers regularly reward developers with feedback during each step of the way, even during a work in progress, then developers are more likely to stay motivated during the course of a project.

2. Provide feedback with the same expressions and terms a colleague used when they submitted their initial code review

Adopting the same language, pitch, and tone as a counterpart establishes trust between two parties. Mirroring the way another person communicates is likely to help with problem-solving. In a study, published in 2008 in the Journal of Experimental Social Psychology, 62 students were assigned to negotiate with other students. Those who mirrored others’ posture and speech reached a settlement 67% of the time, while those who didn’t reach a settlement 12.5% of the time.

If you are discussing a change and are communicating through messaging and comments, it’s important to be thoughtful about how your language comes off. Reviewers should strive to maintain a sense of psychological safety to discuss a problem. Both the reviewer and developer should try to use common terms both parties are familiar with.

Of course, these changes should be subtle and a reviewer should not blatantly mimic the expressions of the developer, as that has proven to backfire.

3. Be considerate in how you frame comments to a colleague

A doctor walks up to two recently diagnosed patients with the same critical illness but presents the information differently. The doctor says to one, you have a “95% chance of living”, while saying to another, “you have a 5% chance of mortality.”

How you document feedback and message important information to the developer matters. To improve the cohesion of a team, managers should be thoughtful in their feedback and not assume that there is one way to present a point of view to the developer. Reviewers should be cognizant of the language they are using and document how particular feedback impacted the quality of the review. Reviewers should then have a source of data to understand the best method of delivery.

4. The end of a reviewer’s feedback will have the strongest impact

What may seem like conventional wisdom rarely gets executed in practice. Citing research from Stanford University and the University of Michigan, Daniel Pink explains that people often rate something higher if they know it’s the end. They rate their day better if they know it’s the last day of class, or rate a snack better than prior snacks if it’s the last one. If you want feedback to stick, deliver the most important information at the end. The last bit of information will be the most impactful to the developer.

As a reviewer, if you have a constructive commentary for a developer, don’t water down the significance of the change towards the end of a thread. Remember that the last piece of information delivered will create the strongest impact. If you are batch processing your code reviews by reading through multiple proposed file changes during one block of time, make sure to save the most important change for the very end.

And if you want to vocalize your appreciation for a job well done, the compliment will be strongest if it’s delivered at the end.

5. Frequently check in on how a colleague is approaching a problem — switching costs increase the longer you wait

Asking someone to change methods is hard. Daniel Kahneman, author of Thinking, Fast and Slow writes, explains that individuals value the psychological safety of the status quo and what they currently own, more than the potential upside of switching behaviors. It’s the reason people tend to hold onto shares in a losing company longer than they ought to, and are hesitant to switch passwords even when prompted by a security expert.

Reviewers should keep this psychological tendency in mind when providing feedback to developers. Asking a colleague to make a radical departure from the methods they traditionally use to solve a problem can lead to a psychological backlash creating internal conflict. Even if your preferred method as a reviewer is truly better, it will be much harder to convince a developer to switch at the end of a process than at the beginning.

Asking a developer to approach a problem differently at the beginning of a process can lessen the psychological burden of switching gears. This is why it’s important to check in even during a work in progress or when a function is mapped out, before the approach is decided.

Managers can also attempt to work within the context of how a developer approaches a problem rather than presenting an alternative perspective as a radical departure from the status quo.

Five Ways Open Source Communities Can Increase User Engagement

Brandon Hopen — Thu, 16 Jan 2020 15:20:48 +0000

TLDR

Today, open source communities struggle to scale because they are focused solely on building new features. Maintainers and core contributors need to invest in tools to make the software building process more dynamic and collaborative. With a code discussion tool, which introduces the ability to comment and discuss code natively in your IDE, open source leaders can create more trust in the community and empower more contributors to be involved in maintaining an open source project.

Introduction

Last year I wrote about my observations coming out of KubeCon, in short enterprises are ratcheting up purchases of open source software in new domains and the amount of projects is growing. Developers are building new ground breaking products focused on transparency at an amazing rate enabled by the rise of git and cloud services. Open source is increasingly touching new industries from data modeling to farming, where developers are pushing businesses to make their software publicly available. It’s safe to say we are at the peak of the adoption curve for open source products.

The adoption of open source technology represents a broader, seismic shift happening across the technology industry. Developers have been awarded more autonomy to choose which products they want to use and how they want to perform work. In some respects, developers behave similarly to any other consumer. Acquisition is difficult because the attention span of any consumer is low and options are endless. Developers are bombarded everyday with pitches for shiny new toys. If you struggle for a second to keep a developer engaged with your product, they will likely leave and join another community.

Investment into new product development is table stakes at this point. New open source tools can only scale if they are focused on growing (and keeping) developer mindshare from day one. I spoke to a number of open source communities at Kubecon and the feedback was consistent — they all prioritized continued product innovation, but very few thought deeply about investing into community engagement.
Tim Hockin emphasized this during his KubeCon keynote that open source technologies survive based on the strength and engagement of their respective communities.

Open source leaders engage with their members across several channels. The activism we’ve seen from community members to push technology companies in one direction typically happens online in forums (StackOverflow, Dev.To), messaging boards (Slack), or public comments in version control systems (GitHub, GitLab). Similarly to the retail industry, omni-channel interaction with community members is becoming more important. Maintainers are hosting Meetups followed by inquiries and discussions in a community Slack channel.

It’s easy for large projects with already high levels of penetration, such as Kubernetes, to engage their community with the resources of the Cloud Native Compute Foundation. Smaller, nascent projects have to fight an uphill battle with established projects for the same level of developer mindshare.

How can open source communities increase engagement

Open source communities have an enthusiastic base of contributors who are often working on projects outside of work hours — working out of passion rather than compensation. While the fragmented nature of open source allows creativity to flourish, the cost can be less engagement. Fortunately, there are a few tools, such as CodeStream that can help increase engagement while keeping the decentralized approach to building an organization.

Accommodate the distributed, global contributors

Consistent communication with contributors is difficult at a global scale under the status quo. Unlike most companies where workers are typically in close proximity to each other, open source communities by nature maintain a distributed, global user base. Developers can’t stand up and ask someone a question about the codebase. Communication on Slack becomes difficult when new contributors are added from different time zones. By the time a community member in one time zone wakes up to answer a question, a conversation has already moved higher in the news feed with multiple conversations happening about different topics.

An easy solution to the geographic barriers and impediments to a newsfeed would be attaching conversations and commenting right next to the codebase in your IDE. Anyone would be able to discuss code at any given time and not compete for attention with other more recent conversations. This method would allow anyone at any time to see the last comment or answer questions without having to scroll up in a feed to see prior comments. For contributors who aren’t in Pacific Standard Time or European Standard Time, this would be a huge plus to encourage more participation from under-represented geographies.

Keep conversations in a knowledge base to supplement a pull (or merge) request

A great way to keep contributors engaged is introducing the ability to see why a pull (or merge) request was executed, directly attached to code blocks in your IDE. Contributors would be able to understand the direct impact they’ve made on a project.

I had spoken with one project at Kubecon who mentioned it can often be months before a request is completed. This is due to the fact that a large user base will introduce more feature requests without any organization. This way when a request is finally completed, contributors won’t scratch their heads and endlessly search Slack archives for a conversation months ago to understand why the change was made.
Remove friction from the onboarding process to decrease new contributor dropout rate

The ability to view discussion on a block of code inside the editor would be helpful to onboard new developers. Many developers may lose interest in contributing to an open source project if they do not understand the documentation or the rationale for the project. With CodeStream, strategic discussions can be archived next to the code blocks inside your IDE. As a developer begins to make their first contributions to the project, the community can provide quick, informal feedback in the form of comments.

By expediting time for a potential contributor to understand the technical nuances in an open source project and provide feedback early on in the contributor’s journey, open source communities can decrease the drop off rate of contributors no longer interested in maintaining a project.

Increase collaborative peer reviews

“When an open source project becomes large it becomes increasingly difficult for a limited number of core contributors to review each and every code request submitted. Very quickly this becomes a bottleneck for the entire project and slows the progress…Implementing peer review is the most common practice for fixing this bottleneck…”
-David Hurley, founder of Mautic (open source marketing automation service)

CodeStream enables collaborative peer review in real time by allowing the core contributors and users to discuss code changes. CodeStream encourages a process when any user can voice their opinion. Collaborators are freed up with more time to do what they do best — build more features. They do not have to answer every question since any user is free to comment on the codebase. This mechanism also empowers any user to actively participate in discussions where they are comfortable having smaller, informal conversations.

Streamline customer support for enterprises

The benefit of open sourcing technology is providing more transparency. Potential customers can look “under the hood” to see how a new technology is built. Enterprises can properly audit the backend of software for any compliance or regulatory challenges. Open source effectively is a risk-free way for potential customers, who may want to buy a premium version of an open source product with enterprise controls in place to try the product first.

CodeStream is a great tool for core contributors to interact with these potential enterprise customers. Customers can point out specific code blocks which need to be edited or modified to use. This feedback layer works exceptionally well to ensure customers and contributors are looking at the same technology backend. Rather than go back in fourth on a Slack channel and look up specific instances, if a customer or general user who downloaded the product has a question, they can simply comment on the area to start a discussion with a contributor.

Top 4 Takeaways From KubeCon 2019

Brandon Hopen — Tue, 03 Dec 2019 22:40:51 +0000

This year I attended the Kubernetes Cloud Native Open Source Summit for the first time. For those who don’t know, KubeCon is the largest open source conference in North America with over 12,000 attendees. Several companies sponsor panels, meetups and round-table discussions on new feature releases for the open source cloud native community. I was impressed by the level of engagement from speakers and attendees. I also thought the most under-appreciated perk was the ping pong table in the expo area — great way to relax between sessions and networking.
Here are my top four takeaways.

1. Containers are reliable and powerful enough to build telecommunications infrastructure

Heather Kirksey, VP of Community Development at Linux Foundation, and Azhar Sayeed, Chief Architect at Red Hat, presented a demo of an end-to-end 5G Network built on open source infrastructure. They began their keynote with an overview of the challenges involved in scaling a telecommunications network using a cloud native approach.

In short, telcos are uniquely difficult to scale because the infrastructure is decoupled. Innovation in the industry has been lackluster due to the fact that critical communications, such as air traffic control and emergency response are expected to perform seamlessly at all times. There are no APIs that seamlessly integrate services at the present state.

Despite these limitations, the team presented a successful demo on the keynote stage showcasing the power of cloud native. Azhar’s team walked the audience through the process where they connected to a packet core in Montreal, an LTE lab in France, and accessed a mix of global private and public cloud services. Each service needed to be broken up into distinct components as the networks are incredibly fragmented.

Building upon cloud native certainly has advantages as it would allow telecommunications companies to consolidate resources, scale up bandwidth for different devices and users, and allow enterprises to move from disparate networks to a shared service offering.

I’m excited about the role the Kubernetes ecosystem will play in powering the next generation of devices. It’s up to the ecosystem to innovate and think about how it can further expand on Azhar’s work to bring cloud native into communications.

2. Policy-as-Code is becoming a critical portion of infrastructure

It’s clear that the Kubernetes ecosystem is investing heavily behind OPA (“Open Policy Agent” ) as a standard approach to represent, enforce and govern policies across applications.

Vicki Cheung, Engineering Manager at Lyft and Co-Chair of KubeCon, opened her keynote with the notion that infrastructure is taking on greater responsibilities. Vicki specifically highlighted how the OPA project is restricting what images can run on containers.

OPA works on the basis that policy decision-making should be decoupled from policy enforcement. Policy enforcement can be standardized across a wide range of technology at any layer of the stack. Some of the use cases can include admission control, risk management, API authorization, and data protection.

The project started in 2016, but is beginning to amass mainstream momentum.

I attended a presentation sponsored by Reddit regarding how the company used OPA to protect against malicious activity, and also control costs. OPA can prevent the creation of server policies that have not been approved by the administration. If you want to restrict actions on Kubernetes objects, OPA allows users to create cluster policies around enterprise needs.

Before OPA, guardrails would have to be programmed manually in each specific application and if there were updates on policy, programmers would have to go back and change the code in each application. An example of where you would want to restrict permits could be support staff having only access to customer service tickets. More importantly, OPA allows engineers to test if a policy is implemented correctly and if administrative access is being restricted properly.

We are at an inflection point with regard to our attitudes towards technology and privacy. As different industries and geographies build unique frameworks, engineers will need a way to dynamically update policies in a way that’s consistent across all applications.

3. Cloud Native is increasingly accommodating on-prem

Despite hype around cloud software eating the world, on-prem remains a major focus for enterprises. The Kubernetes ecosystem is no longer dogmatic about pushing cloud-based technologies.

Rae Wong, group product manager at Google, mentioned during the second day of keynotes that hybrid environments were still the reality for today’s enterprises and the Kubernetes community had to be accommodating.

If you were to take financial services, for example, on-prem is still very much the starting point in discussions due to security and compliance concerns. Laura Schornack, Senior Architect at JPMorgan, and Jeff Fogarty, Innovation Engineer at USBank, spoke about the necessity for cloud native software to hand over controls such as data and credential management. JPMorgan and USBank are forward-thinking in their approach to IT relative to other banks. Laura and Jeff gave the example of deploying advanced workloads by running machine learning applications inside Kubernetes clusters. However, they added that support for air gapped environments is still necessary.

More cloud services are also facilitating portability to private instances. Ultimately, I expect to see all major cloud native tools having a strategy for on-prem.

4. “GitOps” is gaining adoption as the single source of truth for the infrastructure

More responsibilities that were traditionally under operations teams are shifting to application engineers. With an endless amount of micro-services running in real-time, it can be challenging to manage where exactly to push changes.

“GitOps” is the science of using Git pull requests to manage infrastructure provisioning and software deployment

This practice makes sense for a few reasons. First, version control can help with auditing different types of infrastructure to streamline operations. Second, teaching developers to create git requests does not require reinventing the wheel, since most are already familiar with the practice. Third, security teams can troubleshoot and understand where dependencies may lie since developers have to submit PRs for each new server request.

Tamao Nakahra, Head of Developer Experience at Weaveworks, led a great presentation on the keynote stage with representatives from Palo Alto Networks, Branch, Under Armour and Intuit on using GitOps to solve infrastructure needs.

Javeria Khan, Senior Site Reliability Engineer at Palo Alto Networks spoke in depth of how the company is using GitOps for secrets management, where the company knows exactly when keys and authentication controls have been updated.

In a separate keynote, Maneesh Vittolia and Sriram Komma of Walmart discussed how they used GitOps to create custom pipelines and used the same Kubernetes images across other services. The consistency of GitOps allowed Walmart to simplify consumption of resources, and integrate across servers for each storefront.

In conclusion

The cloud native ecosystem is growing tremendously with more enterprises increasing adoption of containers and embracing open source technology. It will be exciting to see the direction the community takes to built on its current momentum.

Lastly, I wanted to give a shout out to Bryan and Vicki for putting together such a great experience!

Why I Joined Codestream: From VC to Dev Tools

Brandon Hopen — Tue, 29 Oct 2019 18:03:58 +0000

After spending two years at ICONIQ Capital, I am excited to share the news that I have decided to join CodeStream, makers of a leading code discussion tool that is revolutionizing developer documentation and code review methodologies. I wanted to share why I embarked on this journey to help build a company in the software development tool space.

Over the past two years, I learned a tremendous amount about how the venture capital ecosystem operates and the characteristics of quality businesses. I attended conferences across industries, and worked with operators who challenged conventional thinking.

I wanted to apply the high-level insights I gleaned from working in venture capital to help scale a business. I spent time understanding different lenses to view sales and marketing efficiency, but had yet to build a growth campaign of my own.

I explored working at an early stage company for some time and had not found a perfect fit until I came across the CodeStream team through an article outlining the massive problem they were solving: developers had broken lines of communicating, documenting and retaining their knowledge.

I was determined to work for a company that builds products for developers. I ultimately believed investment into these tools would be the largest source of value creation for the enterprise.

There are several trends that helped shape my thinking, driven by the way businesses rely on critical applications to stimulate innovation.

Previously siloed departments – data science, product, operations and networking – work interdependently requiring tooling to coordinate software delivery.
Large teams are increasingly distributed across the globe, enabled by new messaging and communication technologies.
Open source communities are now mainstream, and a new breed of products are required to both secure and manage adoption for the end user.
Until recently, one of the most important pieces of real estate for the developer had yet to be disrupted: the application where the developers actually write their code, also known as the Integrated Developer Environment or IDE.

Enter CodeStream, a tool for developers to collaborate, review, and document code at a rapid pace in the IDE itself.

No matter their tooling up to now, developers struggle with documenting their code. Ask any developer, and they will tell you about the difficulties in knowledge sharing and the persistent lack of documentation that makes it so challenging. Documentation helps you understand code faster, leading to shorter code reviews and better code quality. When your documentation is right there in your IDE, it explains it all in context, linked to the code blocks it refers to. This kind of documentation behaves like a persistent set of Google Docs comments that explain how it all works. It all happens effortlessly, because it’s created by capturing the discussions and interactions between developers and their tools and attaching them to the code their refer to.

It seemed obvious to me when I encountered CodeStream that if you could utilize developer discussions during the development process to document the code, you would have the potential to materially affect developer productivity. All other enterprise functions (Marketing, Sales, HR, etc.) have knowledge bases, like CRM, that document established processes, but nothing existed until now for the engineering team to retain this type of information.

I loved the product vision, but the team sold me on the opportunity.

Spending time with Peter, Claudio, Dave, Michael, and Scott made it clear CodeStream relentlessly prioritized product feedback. Peter had a keen sense of the common pain points many developers faced with code review and collaboration, having previously built a business that became the messaging infrastructure for RingCentral and the first social news feed in a social network. The CodeStream product today is an evolution from previous experience working with communication-centric productivity tools. Despite launching four prior companies, Peter and Claudio joined the Y Combinator batch in Winter 2018 to garner even more feedback. Peter’s humility and strong technical aptitude were attributes I deeply admired.

The opportunity to help scale CodeStream’s marketing efforts and learn from a team of seasoned entrepreneurs was something I could not pass up. It’s an opportunity to do more of what I have done before – work with the best-in-class operators and continuously learn. I could not be more excited to be part of the CodeStream team and embark on the journey.