Looker is one of my favorite BI tools. Ever since it was acquired by Google in 2019, it has become a part of the Google Cloud Platform (GCP) and its functionalities have become more and more practical. In this article, I’m going to share my tips to sharpen your LookML code skills.

1. Only build the absolute necessary dimensions and measures

Looker is a self-serve tool, though it’s the LookML developer’s job to identify which metric (dimension and measures) is important to their colleagues — especially if the data (table from a data source) is big.

Always ask yourself if “this dimension (or measure) is necessary?”, “Does this appear somewhere else?”

Two key benefits of selecting dimensions wisely:

• Saves time: I get many confusing feedback from internal users when fields appear multiple times in the same explore (meaning, same view).
• Saves cost: People have different ways to get the same results. And using the same dimension in different views costs much more.

For example, I have 2 tables snapshot_user and user_daily. Snapshot_user is to describe all user’s information at the latest time (today) while user_daily is to describe all user’s information on the daily level (exp: same user A spent 20USD on Monday, 30USD on Tuesday, 40 USD on Wednesday).

However, both views have the user’s name and the user’s DOB (Date of birth). There is a different query would happen (Assuming PII is not a factor in my example):

SELECT user_name, user_dob FROM snapshot_user

While someone can have the same result with a higher cost of the query

SELECT user.user_name, user_daily.user_dob

FROM snapshot_user AS user

LEFT JOIN user_daily USING (user_id)

2. Structure your View and Models

After years of writing LookML code, one tip I always suggest to my team is when we build a big view (let’s say greater than 50 dimensions and measures), it’s good to structure your view from the beginning.

Example: Applicant view’s structure

• When other developers read your code, it is easier to review what is inside the big view.
• On the other hand, it is also easier for developers to search for specific dimensions or measures in the key part. Assuming I only want to check 03. Applicant Risk Assessment, then it will only show twice in the view (1) at the beginning of the view — View structure and (2) at the beginning of your code.

3. Follow LookML standards and always have descriptions!

Same reason as the previous tips, consistency and standard are very important practices after tidying your view structure. Personally, I have two strong recommendations for all LookML developers:

• Always have descriptions for every single dimension and measure of your build. It is essential to understand your data, its definition and use case of the metric. Even if it is an obvious name like “applicant_id”, sometimes, the id is returned by different providers and can impact results.

• Follow the standard guideline from Looker. Looker contains many great pieces of training around organizing Model files, naming aggregates, and ordering parameters in field definitions. I believe it is very useful for self-practices.

4. Peer Code Review Process

To achieve the three practices above, I would recommend the team always have a good code review process. Developers sometimes could miss things. The analytics engineer team should always have a good guideline checklist, either taking reference from Looker guidelines or from experiences.

Some must-have checklists I would recommend:

• Purpose of dimension/measures
• Check LookML validation
• How SQL is done — check the join. If sometimes, your SQL is too complicated to define a dimension while the metric can be used multiple times, we should bring it to DBT (the link would suggest the best DBT practice)
• Description and style

Above is my personal practice daily to build a good LookML code. Let me know your tips too