Q&A with Katie Kodes, Salesforce and Python Integrations Programmer
My favourite finding in doing this Analysts Assemble series has been just how humble and genuinely helpful the data science community is. And this week’s guest is certainly no exception.
I’d first read Katie’s excellent article on SQL Joins on Dev.to and when fellow Dev blogger Helen Anderson recommended I speak to her for this series, I jumped at the opportunity.
Katie takes us through her introduction to the world of programming, getting involved with the Salesforce eco-system and how she recommends people lift themselves, and others, up through building their overall skill-sets:
Tell us a bit about yourself, how did you get into the data space and what does your data journey look like so far?
Let’s get a few things out of the way. I’m white. I’m able-bodied. I speak English natively. I have no immigration worries. My childhood environments were safe and educational. I’m university-educated and had professional computer programmers as adult role models growing up.
As a teenager, my family paid for the roof over my head, not the other way around. That enabled me to look at summer job descriptions first, wages second. The job I had as the Great Recession of 2007/2008 began remained unscathed and provided my career incredible refuge.
I call myself a “late bloomer” into programming, but the soil I was planted in is a huge part of my story!
But jumping ahead to my first full-time jobs, I started learning a lot about databases through data entry roles that I applied for as a “fast & accurate typist.” At one job, people got so tired of writing query reports for me that they taught me how to build my own.
That’s how I learned about joining tables and avoiding “cross-joins.” Programming was much more engaging at the office than it had ever been in my few attempts to study it in a classroom.
I only recently thought about it, but the fact that all the programmers who delegated work and trained me were women — and that all their bosses were female programmers/architects — and that they weren’t all white or computer scientists — might have normalized programming as a career path in ways that being friends with hobbyist teenage boy coders previously hadn’t.
Eventually, when I felt “stuck”, I took night classes to formalize my studies, which advanced my foundation for further learning enormously.
Landing a database query reporting job on a team that had just purchased Salesforce made me an #AccidentalAdmin. Trying to automate away #WhyAdminsDrink problems turned me into an #Admineloper as I learned to write Salesforce Apex triggers and Python scripts.
As I’ve gone deeper into “Extract, Transform, Load” (ETL) integrations, I’ve returned to my traditional database roots and started working with a team of Oracle and SQL Server developers, DBAs, and integration specialists. We’re inventing my job description as needs arise, but so far it’s going to involve:
-
keeping “runbooks” of things that need to be done when we upgrade a database
-
helping with deduplication (which came immediately after I offloaded my old deduplication responsibilities to someone else — you just can’t run from that job, can you?)
-
working with 3rd-party vendors to troubleshoot and fix their integration products when upgrades make them fail in production
-
coding!
What’s a typical day look like for you in your current data role? Which tools and languages do you use? Big team/small team/lone wolf? Office based/remote?
I try to exercise as often as I can, because computer work is brutal to your hands, eyes, and back. Recently, I’ve been able to use a pool and discovered treading water is great for your upper body AND timing meetup talk ideas. (Does anything speed up 30 minutes better than needing 40?)
As to the rest of the workday, I was lone-wolf as the “computer person” on a team of end users until joining my current team, which is small and office-based. I’ve veered toward the “integrations programming” side of data, not “analytics” or “statistics” or “visualization.” None of my coding projects typically take more than a week, and a lot of my work involves supporting them afterwards. Here are a few examples of requests I see:
– “Hey Katie, I loaded bad data into database A, and now the daily sync to database B you wrote filled database B with the bad data. What’s the proper sequence of cleanup tasks, and can you help me perform them in bulk?”
– “Hey Katie, we stopped requiring a snail-mail address on our ‘request info’ form, so the automation you wrote us to remind us to send everyone a brochure is often irrelevant. Can you change it to only create a reminder if they asked for paper mail?”
Tools:
– I use point-and-click tools with Salesforce as much as I can, but occasionally write Python scripts to clean data on my hard drive or over an API, and I write Salesforce database triggers in their Java-like language called “Apex.”
– With Oracle and SQL Server databases, most of what I do is in SQL and PL/SQL or T-SQL.
– Enterprise-level ETL tools for scheduling inter-database communications often involve what I like to call “point-and-click programming.”
Integration work is pretty “MacGyver”-ey. You access data with the tools your company invested in, and you cobble solutions together as effectively and efficiently as they allow.
You’ve had a great response to your own blog and your articles on Dev.to. How important do you think it is for data professionals, at all stages of their career, to share publicly what they are doing and learning?
I have priceless colleagues who don’t seem to share what they know far beyond the water cooler.
But don’t be afraid to scratch that itch if you have it, any time you have an “aha!” or “???” moment.
As Jessica Kerr and Julia Evans pointed out in episode 16 of the “Greater than Code” podcast, people who just learned a topic often explain it best to people who are trying to learn it.
Meetups (including in-company user groups) and local conferences are a very forgiving setting for stumbling through public speaking. Blogs and Twitter are great ways to practice writing concisely.
You can always start a new blog as you “level up” your writing and speaking experience to consolidate your “best-of” moments and move on from your “newbie” days.
Where do you see your own data career going next? Building on your technical skills or moving into a more management-based role?
At the moment, technical skills interest me far more than managing people, as much as I love being around them.
But never say never!
If you had a list of “best-kept-secrets” (websites, books, coaches) you’d recommend, which would you recommend?
Alan, you gave me so much decision anxiety when you asked this question. I got stuck for days until I had added all the books at my office desk to the “resources” section of my website so they’d know I love them, too.
Other people will cover the big ones like FreeCodeCamp and Dev.to, so let me share two unusual dusty old books:
-
“Ones and Zeros : Understanding Boolean Algebra, Digital Circuits, and the Logic of Sets” was a random library find that absorbed me nightly. I’ve always loved conditional logic, but this book really threw down the gauntlet and asked me, “Oh, so you think you can AND/OR?”
-
“Introduction to Unix and Shell Programming” (Venkateshmurthy). This is published in India and can be hard to find in some countries, but it’s worth the effort. After many failed efforts, this was the friendly, thorough explanation that finally taught me Unix.
What is the number one piece of advice you give to aspiring data scientists?
One? Just one? Can I pick two? Please?
1. Master the art of concisely reframing your “shortcomings” so you’re in charge of the narrative. I hate to make a “case study” out of another person’s struggle rather than my own, but I think an issue that foreign students sometimes face makes a great example.
Friends I’ve known often struggled to find work permitted by their student visas, either because companies “don’t offer internships” (in American English, that has a pretty narrow connotation in the world of short-term work) or presume it costs money to hire visa-holders (true with “work visas,” but free of charge for the limited work permissions included in a “student visa”).
I’ve suggested working the following into cover letters and networking encounters: “My student visa allows me to work in the US for a few years at no cost to employers, so I’m looking for short-term opportunities during summers and after I graduate to take advantage of that.”
Humans, including employers, seem to make up reasons they can’t do things out of fear of the unknown. Apply your “explain it like I’m five” and “elevator speech” skills to whatever you’re terrified someone will “judge” you about. Offer your story first and don’t leave people gaps to fill with their own imaginations!
2. Ask yourself what you love about data.
– Storytelling?
– Asking questions and exploring the unknown?
– Math and statistics?
– Programming?
Even if you’re just interested for the money (that’s okay — everyone has to eat!), what aspect of “data” scares you the least to try to make a living with? What seems to suit you?
Specialize in that as you start, to quickly ramp up into an employable niche.
“Know what you don’t know,” though, and stay big-picture informed about what “data scientists” with other specialties are doing as time marches on. It’ll help you decide what new developments in your specialty are really relevant, and it’ll help you decide whether you’re interested in adding a new specialty.