How to code better and faster: lessons from research into Google developers

I stumbled upon a research paper that used both surveys and log analysis to understand developer behavior at Google.

This is intended to be a collaborative post, meaning it's an open invitation to connect and discuss.

Why?

Because I believe the results of the research point to an interesting way for you to:

• Learn how to code faster
• Learn someone else's code faster
• Ship code faster
• Reduce errors
• Collaborate better
• Get out of refactor jail faster
• Reduce technical debt

What was interesting to me was the results from the logs (although the surveys helped to provide valuable qualitative coloring).

The internal tool that they used was a "code search" tool. Most devs use their IDE, Github, or grep when doing code search. So the concept of searching for code isn't new or breaking ground.

However, the use-cases and frequency of code search made me realize that a purpose-built tool would enable new kinds of behavior for developers outside of Google.

I recognize that Google would build their own code search because of their "Big Code." And for those working on small code bases, the use cases and capabilities don't apply.

However, I don't think having as much internal code as Google is the threshold for achieving "Big Code" and the associated problems.

Not to belabor it since it's not the purpose of this post, but the top three reasons more and more developers should learn how Google devs leverage code search are because more developers will have environments that are similar:

1. Open source actually makes the code base big faster
2. Micro-services and active M&A results in multi-repo environments
3. Remote dev creates the same demands on context and collaboration as being in the belly of a massive corporation

What were developers at Google trying to do?

The list, below, is probably not surprising. You may have a similar list.

But that's the point: if Google is using a special tool with their own course on how to do so, perhaps this is helpful for developers not at Google.

Here are the major categories of what they are trying to do:

• Looking for Example Code (How)
• Exploring or Reading Existing Code (What)
• Code Localization (Where)
• Determine Impact (Why)
• Metadata (Who and When)

What helps you the most?

The research was helpful at a high-level.

But what is the problem to solve and outcome that you would be most interested in help in?

What saves you the most time and broadens your opportunities?

I am honing in on:

1. How to understand new code (open source or new private code) faster
2. How to refactor existing code in less time and fewer mistakes

Are there other things that would be helpful?

What do you think of this concept?

Thanks!