LookML gives developers lots of flexibility when it comes to reporting, which is great, but at times can be the LookML developer’s Achilles heel. The fact that you can accomplish the same result in more than one way sometimes slows down the development process (we’ve found this to be especially problematic for novice LookML developers). It takes time to think about modeling decisions or to research the docs before deciding how to code a particular element in the model. For example, standardizing the way a measure like ‘Net sales’ is displayed in visualizations can be done in a number of ways:

• At the view level, (e.g., with value_format_name:  or value_format:)
• At the model level, (e.g., with named_value_format:)
• At the Look level (e.g., in the visualization options), or
• Within LookML dashboard code.

But these aren’t the kinds of decisions that will drive the greatest value add for clients and stakeholders. Instead, developers' time is better spent, for instance, improving model optimization, simplifying the Explore user interface, and providing more informative data visualizations.

Solution: Our Looker style guide helps Brooklyn Data Co. developers save time by answering a lot of these questions up front. For example, our guide takes a stance on what case (e.g., upper, lower, snake, title, camel) should be used when defining fields and writing descriptions, and provides visualization formatting guidelines.

Analysts working with LookML for the first time or junior analysts still working on building their coding skills often find a fully operational Looker instance overwhelming. While Looker provides tons of great training material that helps flatten the learning curve, the reality is that it can take time for folks that are new to LookML development to be effective collaborators. As consultants, we’ve observed this when handing off a Looker model to a client’s data counterparts who are working with Looker for the first time.

Solution: Code that is consistent, logically organized, and thoughtfully commented makes it easier for novice and intermediate-level developers to understand all elements of a project and speeds up the time it takes to add value to the development process. The guidelines laid out in our Looker style guide encourage a simpler experience for folks writing, reviewing, and editing LookML code.

Not all stakeholders we support are savvy when it comes to business intelligence tools – in fact, most aren’t. A lot of the business folks we support are comfortable in Excel and Google Sheets, but are unfamiliar with more robust reporting platforms like Looker. They share their frustrations about not knowing where to look for the data they need and being confused by what they find (e.g., similarly named dimensions and measures in a poorly classified field picker). One especially frustrating experience is the ‘One Explore to Rule Them All’ where LookML developers try to answer any and all possible business questions in one mega Explore. Imagine an explore with over 2,000 fields (yes, we’ve seen that in production!).

Solution: Our style guide serves as a reminder for developers and code reviewers to carefully consider how fields are named, described, and presented to data consumers who interact with Looker features like Explores. For example, we recommend giving ratios descriptive field names: 30_day_repeat_purchase_rate is more effective than customer_repeat_rate.

When working as part of a team of developers, we’ve observed opportunities for improvement related to process, style, and strategy.

• Workflow opportunity: Where should we discuss and resolve questions? Each developer might have their own preference (e.g., over email, in Slack, on Zoom, etc.), but for a development team to be efficient, it’s key to have well-documented work and consensus around how the team will communicate.
  
  Solution: Our team’s preferred solution is to connect to a Git repository and integrate it with our Looker instance so we can funnel all reviews, comments, and suggestions to pull request (PR) reviews in GitHub. We’ve found this approach helps increase transparency for our clients, who can then track all of our Looker development work in a single organized location.
  
  
• Style opportunity: How should we resolve subjective choices about code development? (This is a continuation of tip #1.) For example, should we organize dimensions defined in our view files alphabetically, or by clear functional sections such as primary key, timestamps, etc.?
  
  Solution: Rather than spend time negotiating how to comment on and fix those elements, the PR reviewer can point to the section of the style guide that lists the team’s agreed-upon approach for those situations.
  
  
• Strategy opportunity: Ever find yourself coming back to code that was written a few months ago (or maybe even a few weeks or days ago) only to ask yourself, “Why did we make that change to the model?” Lack of documentation and organization can end up costing developers lots of time when recovering the context behind decisions and strategic choices.
  
  Solution: We work with a PR template. It encourages better documentation of the work that was completed, links to supporting material (e.g., related Jira tickets), any open issues/items the reviewer needs to know about, and reminds the developer/author to be thorough about quality assurance before requesting a review. All this provides ample context up front to reduce the time to complete a review; this is especially helpful if your team is remote or geographically distributed across time zones.
  

Writing LookML can be daunting, especially if you’re coding under the pressure of a deadline. There are many elements to think about, and it can be tempting to just build fast with a focus on working code, rather than taking time to build more organized and maintainable code. We’ve found that this problem is compounded when there are multiple developers working on the same model: you can end up with a mishmash of code that is more complex than it needs to be (I call this flavor of tech debt ‘LookML entropy').

Solution: Use comments to create explicit sections in files and follow standardized conventions across all models. This will help developers know what to expect when reading something new and give them guidelines when building on existing code. Our style guide, for example, includes agreed upon conventions around organizing Model files, naming aggregates, and ordering parameters in field definitions. This is especially helpful when working with complex Looker models or across multiple instances of Looker.

We’re excited to share our Looker style guide and welcome your feedback as we continue to improve our guidance on writing LookML like a pro!  Check out our other style guides for dbt and SQL, and find more Looker content throughout our blog.