Maybe you're a business analyst who's sick of not being able to level up your Power BI reports. Or maybe your New Year's resolution is that this is the year you'll finally buckle down and master SQL.
And now, with the end of January staring you in the face, you realize that this resolution is headed towards the same sad fate—one does not simply scale Mount SQL.
Is it because you lack the will? Maybe. But if you've tried and failed before, it's more likely that like many analysts and other power users, you found that getting started with SQL is intimidating.
In this article, I won't explain how to learn the nuts and bolts of SQL; there are plenty of sites that can help you with that. Instead, I'm going to focus on how to approach learning SQL if you've struggled to do so in the past.
Follow the simple strategies outlined in this article and you'll be well on your way to gaining a comfortable mastery over SQL that will help your career and your startup thrive.
Before we dive into how to learn SQL, let's first get rid of an assumption underlying a lot of articles on the subject. Although most of them exude a "you go girl!" attitude, they also imply that learning SQL should be easy.
So if staring at a blob of SQL code makes you feel like an idiot, is there something wrong with you?
No. As someone with over 30 years of experience writing code and teaching analysts and other non-coders how to learn SQL and many other programming languages, I can confidently tell you, it's not you, it's SQL.
As someone with over 30 years of experience writing code and teaching analysts and other non-coders how to learn SQL, I can confidently tell you, it's not you, it's SQL.
Here are just a few reasons why many people understandably find learning SQL hard or intimidating:
When SQL was first being developed, its creators hoped that "with a little practice, users could learn to read queries…almost as though they were English prose." And for some people, that's exactly what reading SQL is like. But for many of us, when we first get started SQL looks a lot more like Latin.
If you're learning to master Excel, you can usually do it in bite sized pieces. To solve a new problem, you learn one or two new functions or tricks and possibly a little bit more about the table of data you're working with.
But with SQL, at the same time that you are trying to wrap your head around the difference between left and right outer joins, you're probably also having to grok what data is in which table, how the complex tables in a database work together, making sense of oddly named fields, etc.
Learning a new language, understanding how the data fits together, and writing queries that return something meaningful? That's an awful lot to tackle at once.
One of the advantages developers have when they learn a new language is that they are spending most of their day writing code.
But if you are an analyst, you may only get to spend small chunks of time here and there focusing on SQL. If SQL looks at all weird to you and you are struggling to figure out a data model, only having small chunks of time can make it difficult or impossible to write enough SQL code to let go of your SQL anxieties.
So if you've tried learning SQL before and got bogged down, don't beat up on yourself. For many folks, it ain't easy.
If learning SQL can be tricky, what can you do about it? Here are some simple strategies that can make a big difference:
The simplest way to make mastering SQL more manageable is to break it down into tiny steps.
For example, odds are the reason you want to learn SQL is because there are specific problems you want to solve. So, make a list of those problems—a "problem backlog" of questions you want to answer or techniques you want to learn or master—and choose one to start with. Then break that problem down into smaller steps and work your way through them, checking off steps as you finish them.
That way, at any one time you only have to wrap your head around one specific problem.
If you are trying to learn SQL while juggling a bazillion other tasks, it's easy to feel like you can't afford to spend a few minutes to come up with a list and break it down into small steps. But this tiny amount of structure can really pay off.
This strategy also makes it easier to commit to carving out a little time every week or two to work on your SQL skills. It's hard to go from being intimidated to feeling comfortable with SQL if you only occasionally use SQL. But if you can structure your SQL learning into small, manageable chunks, you're more likely to find the time to keep chipping away at it.
It's easy to fall into a rabbit hole, spending hours fruitlessly banging your head against a problem whose SQL solution you can't find.
Don't do that. Do what smart developers do when they get stuck: Google the heck of it.
Similarly, if you are having trouble making sense of the data model of, say, Shopify, odds are Google can help you find useful blog posts or other materials that are posted online (e.g., Panoply's guide to Advanced Analytics and Reporting for Shopify).
If searching for an answer doesn't help you out, then ask online.
Some data analysts are nervous about asking for SQL help because sites like Stack Overflow can be intimidating. Sometimes folks on these sites can be kind of jerky—assume they’re still recovering from the trauma of being a nerd in high school. But Slack communities like Chartio's Data School can be really helpful when you're getting started.
That said, if you spend a little time writing up a) what problem you are trying to solve, b) the SQL code you have written, and c) what you have done so far to try to solve it, you can often get extremely useful help. The same is true for online communities for Salesforce, etc.: spend a little time explaining where you are having trouble with their data model, and odds are you'll get useful advice.
Some developers love helping beginners, others can get irritated—especially if the person asking is completely disorganized and hasn't spent any time trying to think through the problem. But if you are genuinely stuck and you can show that you've been trying to solve it yourself, most developers will try to be helpful.
And if you are truly unsure of where to get started? Pick an especially nice developer, and don't ask them to solve the problem for you. Instead, ask them to point you in the right direction. For example, you could ask them what's the right geeky term for the problem you're trying to solve—because with Google, that's often half the battle—and a few tips on how to start finding the solution.
An added bonus of taking a few minutes to figure out how to explain where and why you are stuck: it might help you figure out the solution. It's amazing how often I've been able to solve a problem on my own literally as I'm describing it to a friendly developer.
The hardest part about getting comfortable with SQL isn't learning the lingo and tips, it's remembering what you learned a few months ago. There's a simple way to solve that problem: create a "cookbook."
If you're committed to learning SQL this year, take a minute right now to open up Google Docs or Word and create a document called "My SQL Cookbook" (or something more creative or ironic). Every time you learn something new, either about SQL or about some janky part of a data model you're using, write a quick note in your cookbook. If it's relevant, also include some sample SQL.
Then every once in a while, spend an hour cleaning up and reorganizing your cookbook so it's easier to use.
Writing down what you've learned has two advantages:
If you're more adventurous, you might decide to build a slightly more elaborate cookbook—e.g., create a free website or blog or set up a repo in GitHub. But however you do it, get started today.
Here's a trick that can make a big difference in getting comfortable working with SQL: when you finish writing some SQL that you’re likely to reuse but is a bit complicated, carve out 10-15 minutes in the next day or so to clean up the code.
Why? Odds are that sometime in the next few weeks or months, you're going to run into a problem that you can solve by repurposing this SQL. Or perhaps this is SQL that you're planning to run for a report every month, and every once in a while you're going to need to tweak it. If you're coming back to SQL that you threw together months ago, not only will it take longer to work with, but it can also end up eroding your confidence—especially if you end up making an embarrassing mistake because you didn't understand your own code.
So take just a few minutes to add a few comments, pick a better name for a column you created, etc. Your future self will thank you.
As I mentioned above, one of the reasons why analysts have trouble getting comfortable with SQL is that some of the data models they work with are complex. As a result, every time you want to crank out a report or solve a problem, you've got to work with a bunch of joins, aggregations, etc. That can make working with SQL pretty intimidating—you're always one small typo away from making a serious mistake. It's also hard to feel confident you know what you're doing when you are constantly reusing complicated SQL.
So if there's a set of complex data you're going to keep coming back to, don't work in raw SQL. Hide the weird stuff.
If you're allowed to create them, views are an excellent way to hide the weird stuff. Many analysts are intimidated by the idea of creating them, but once you've created 2 or 3, you'll discover that they are really easy to make...and they only take a couple of lines of code:
CREATE VIEW wordpress_posts AS ( --[A messy bunch of SQL] );
That's it!
You may come across developers at your startup or online who think views will cost you cost too much speed. But as Microsoft SQL expert Brent Ozar demonstrates, most of the time when people complain about the speed of views it's because the code in the views is poorly written, not because views themselves are inherently bad.
And even if you are facing a circumstance where using views would slow down your code a bit, you aren't a developer writing SQL that will be executed tens or hundreds of thousands of times a day. You'll probably run your code once a week—or just once. Speed of development, not speed of execution is your top priority.
Working with data you dumped from Google Analytics is one thing. Mucking around with data in your startup's product database is a different story. Even assuming the db owner would let you, you don't want to be running SQL in a production database. The last thing you want to do is to write some code that inadvertently slows down the whole database when you execute it.
This danger can seriously slow down your ability to learn SQL. You may end up too worried about breaking things to experiment enough to get comfortable. And there's a good chance that every time you want to obtain a copy of the data you need, you have to wait until the database's owner has time to get it for you.
One of the best ways to get around this problem is asking whoever's in charge of the database to set up a nightly dump of the relevant data into a "sandbox"—either a database or a series of tables that are stored on a server where you can't cause problems when you experiment with your SQL. Alternatively, you could have them connect your db to Panoply and work with a copy of your data there.
A sandbox can also be a good solution for the database's owner; they set it up once and then they don't have to spend time on a bunch of requests from you in the future.
It's okay if you've been intimidated in the past when you've tried to learn SQL. If you want to overcome your fears, try out a few of the above strategies, see which ones work best for you, and keep carving out time to use them to make progress.
The real trick is pushing through, putting in a little work every week or two. Set yourself on that path, and by the end of the year, you may well find yourself at the summit of Mount SQL