As part of a new series, we’re inviting alums of Analytics Engineers Club to write about how they’ve applied lessons learned to their work experience. First up is Sean Meehan, a data and analytics engineering consultant!
Note: Sean Meehan was part of a live cohort, but the asynchronous course offers the exact same content and curriculum.
My path into Analytics Engineering
An interesting phenomena of the analytics engineer is that they are often doing the work of one before they recognize they are one. For many (myself included), it’s not until they see their reflection via blog post, podcast, or some other knowledge medium of their choosing that they do a double take and ask themselves, hold up — is this me?
You see, one of the really neat things about the analytics engineer is that they come from a wide variety of backgrounds. Me? I was a mechanical engineer — I designed stuff like this:
When I designed that control dial on the far right, I was working for a startup where I had the ability to wear a lot of hats. I like to wear hats (especially if I haven’t cut my hair in awhile), so naturally, one day I decided to pick up this fashionable baseball cap and don it on my head.
And the rest is history. [End article]
Just kidding, but that is where this story begins.
As I progressed in my SQL learning, I found myself automating a lot of operational reports. In the beginning, it looked a bit like this:
- Write a query within the UI of my company’s ERP software
- Schedule a “data export” via this UI to run said query at such and such time every day1
- Take that CSV data export and feed it into a Google Sheets to “refresh” the operational metrics2 that are then calculated by other Google Sheets
I’m glossing over some details here, but you get the idea. In doing this sort of work, I pleased a lot of stakeholders and made some coworkers’ jobs much easier. Above all, we now had fresher data more often, what a concept!
Soon enough, I decided to leverage a handful of these small wins into a more full-time data role. In doing so, I found myself a part of the software team and out of my league.
After spending some time working within the constraints of a home-rolled data transformation architecture that my boss had constructed, I decided this tool I’d heard about called dbt might make more sense for us. Why maintain something, if there was a better option that existed for free? (I later came to learn that the appropriate term to describe this sort of software was “open source”.)
In the course of proving out dbt, I was given the “keys to the car” so to speak, and therein I became a data team of one… dbt had all of a sudden given me great power, but as the saying goes, “with great power comes great responsibility”3, and I wasn’t about to fool myself into believing I knew what I was doing just because I’d figured out how to
pip install dbt.
Deciding to join Analytics Engineers Club
As the now singular data person at the company, I found I didn’t have anyone to show me the ropes and teach me the ways of the modern data stack that dbt presides over. I also knew that it would be a lot easier to fix any bad habits I may have developed if I caught them early, but in order to catch them, I required assistance from someone who had been there, done that.
Around this time of self-education, I stumbled across a cohort based learning course dubbed Analytics Engineers Club (AEC) that was just getting off the ground. I remember listening to a podcast (linked earlier in this article) where one of the instructors, Claire, talked about her path into AE and thinking, “hey, some of her path sounds similar to mine!” It then occurred to me that by partaking in AEC, I may be able to accelerate my learning curve by leveraging the knowledge of those who had already experienced what I had yet to experience. Even more importantly, I saw the cohort setup of AEC as a way to network amongst peers within the larger data community. Coming into the data world as a mechanical engineer, I not only felt like an imposter, but I also felt like an outsider. In the end, I jumped at the chance and applied to the program as I saw AEC as an opportunity to further my learning, gain a bit of mentorship from two legends within data (i.e. Claire & Michael), and start to build out a network with like-minded peers.
So was it worth it? Well, I probably wouldn’t be writing blog post if it wasn’t… and I may have actually gone back to designing products and mechanical engineering 🤖
In short, it was very worth it — I learned what I needed to learn that I didn’t know I needed to learn (say that 5x fast). I also learned what I needed to unlearn/relearn.
As an example, the very first homework assignment (before the course even started) included a question like this:
For each customer, calculate how many orders they have placed, and when they placed their first order. Include these columns in your answer…
Piece of cake, I thought, and submitted the following query ❌:
These days, I cringe a bit at that query. While it produced the correct output, there were some definite flaws with it. In writing it at the time, I kind of knew it didn’t feel right (ie. “code smell”), but I didn’t know why.
Thankfully, on day one of the course, the why was quickly pointed out to me.
Here’s the better smelling (or perhaps odor-free?) version ✅:
I won’t steal the show and get into all the minutiae of what’s better about the second query (you should take the course for that 😉), but I will say that learning about proper query design (e.g. group then aggregate) on day one definitely provided me the confirmation that this course was what I had been looking for.
What about that imposter feeling?
For the most part, it’s gone… at least with respect to analytics engineering. I won’t attribute it all to AEC because I think a portion of getting over the imposter hurdle comes from just putting in the time, work, etc. to get exposed to different problems. That being said, I can say that AEC played a pivotal role in helping me overcome feeling like I didn’t quite belong (especially in interactions with stakeholders), encouraged me to tackle difficult problems head-on, and gave me immense direction on where to go next.
In completing the course, I was armed with a wealth of information (including, but not limited to):
- data modeling techniques and best practices
- knowing how to approach complex problems, and break them down in bite-size pieces
- navigating stakeholder conversations
- common gotchas to watch out for
- understanding materializations and using them to build an effective & efficient dbt project
- database theory, and why the different types of databases exist
- general software engineering principles that can be applied to both work & life
- finally getting git
On top of all that, being able to live vicariously through Claire and Michael’s experiences in the field (as well as the experiences of other students) was like being gifted a huge superpower that I still draw on today. And while the self-paced course may have less of this sort of interaction than the cohort program I took, there is still an active Slack community for students both new & old to participate in.
If you’ve made it this far, I hope you’ve found this helpful. My goal was not to write a sales pitch, but to try and provide some insight into how AEC helped me realize my journey into data, and also to say thanks.
Personally, I don’t typically take many courses because I find that I can teach myself a heck of a lot if I’m willing to put my mind to it (though I recognize this learning style doesn’t work for everyone). The courses I do find valuable are the ones that can teach me “how to think” and open up new doors — AEC fell in this bucket for me. Regardless of whether it falls into that bucket for you, I think the data community is a great one and I’m happy I found my way here.
1I’m just clicking buttons for this
2I did write a bit of Google Apps Script for this, and felt like a boss at the time
3https://youtu.be/guuYU74wU70?t=69 – if you want to watch some Spiderman