Hands On data
My 0 to 1 Journey Learning SQL
What I wish I knew when getting started with SQL.
Structured Query Language or SQL — “sequel” — is one of the most important tools in the shed of today’s data-oriented business.
A little over five years ago I couldn’t tell you what a Product Manager does but here I stand today, five years behind me solving customer problems — more on that in a separate article.
My major in college was in Management Information Systems. It's clear to me now the skills (and logical thinking mindset) I gained during some of my most disliked courses have helped me progress in my career more than I could have imagined. One course in particular centered around database management and let me cut my teeth on SQL statements with MS Access (this was not as long ago as reading this statement implies). What I didn’t know at the time was that my trajectory would land me squarely in the realm of DATA!
Three years ago I jumped into the data-as-a-service space with barely any understanding of what Select * from * would produce. Given the need to learn I dug into SQL and it became a differentiator in my success and ability to solve problems quickly.
If you work for or interact with any modern business that hasn’t buried its head in the sand for the past twenty years then you understand the need to utilize metrics and statistics to make decisions.
The data exists; the answers/insights are within, but you need the right key.
TLDR; My mantra is always “with a little bit of Google, and a little bit of guidance, I’ll figure it out” and you can too.
How I got started
It's a bit cliche but a problem presented itself — rather an abstract problem was thrown at me and I had to produce an answer. When you work for a data business and your end product is data you need to understand your asset. For the sake of the remainder of the article, the assumption is that you either truly want to dig into the data and/or you don’t have a full-blown business intelligence team that you can throw your complex data problems toward.
- Make sure you have access (or request it) to the system(s) where the data can be queried.
- Find your expert and lean on them. Depending on your organization this maybe someone on your team, the business intelligence team, a data engineer, or some combination of multiple people. It's invaluable to have a guiding hand to show you the ropes when querying production datasets using a system you’ve probably never accessed.
- Brush up on your basics and understand the syntax of the system you’re using — Things to consider: Legacy SQL? Standard SQL? MySQL DB? NoSQL DB?
- Search skills matter —SQL isn’t new, if you’re trying to solve a problem and don’t know where to start, my first recommendation is Google (or Stack Overflow).
What I wish I had known then
- Ask questions first (Asking why is not only good form it will save you time and headaches later). I’ve outlined some things to consider above and more below.
- Review the Schema — review the data assets you have available. The goal here is to logically grasp the structure of the data. Things to consider: Is it stored in a database? Is the data “event” based? Is the data “user” based? What is the update cadence and how is that reflected in the database?
- Know the cost. Know your personal and system limitations: How much data equals an adequate sample size to solve your problem with reasonable accuracy? Are you querying a system being utilized in production or a copy of the data? How much does it actually cost (in $) to run this query? (Select * is not your friend here)
- Keep a record. You will inevitably solve a problem using SQL and IT WILL COME UP AGAIN or at least something similar enough that your query can be re-used (Some systems save your querying history — Google BigQuery for example — will get into that later).
- Practice. But Find problems to solve. It will be easier to learn if you have a real problem to solve or insight you’re looking to obtain from YOUR data.
- Avoid decision bias. Data can often be manipulated to produce the result you seek. If you go into a problem seeking a particular answer you may inadvertently come up with a solution that leads to that answer.
Where does this leave us?
Okay, so I’m a bit biased in my preferences and approach — as are most people who spend any time working with data. My best data analysis experiences have come while working with Google’s BigQuery tool.
I cover the basics of getting started with BigQuery in this article:
The key takeaway here is for you to understand the power of SQL and empower you to dive into your own data analysis. As I’ve called out already, having a real problem with data that is relevant to you, at least for me, makes it much easier to learn. If you don’t have a real dataset already, don’t forget, data is all around you!
My journey into data, I imagine, is no different than most, pushed out of the need/desire to be self-sufficient. Having the wherewithal to dig into data and produce meaningful insights or even better solve a problem is in my opinion a differentiator and skill worth seeking.
This article is by no means comprehensive in covering SQL or BigQuery and I’d love to hear your opinions or suggestions for future topics. Feel free to share in the comments.
About Me
I work solving problems, driving operational excellence, and launching products. Along with being a DaaS focused Product Manager, I consult for organizations focused on maximizing value through product-focused growth and data value. Reach out to continue the conversation or work together.
