Zev Averbach, Frustrated spreadsheet jockey to software developer at 36

Q: Tell me about your journey as a spreadsheet jockey into Data Engineering?

A: First of all, it's hilarious that I accidentally found your questions for this interview by Googling myself. 😊

I've always been a frustrated software user, and that frustration led me to be a "power user" (keyboard shortcuts etc) of my most used applications, as well as a "visual coder" using desktop automation like Alfred and Keyboard Maestro (Mac).

Now that I've met data analysts and finance people that use Excel all day, I don't think I'd claim to have been a true "spreadsheet jockey" in comparison to them. However, hitting up against the limitations of spreadsheets for running my transcription business -- specifically for bookkeeping -- created a new frustration for me:

As the business grew I was spending more and more time copying entries from Google Sheets to the Freshbooks web app for invoicing purposes. I tried to automate that process, but I was doing it using desktop automation, which was finicky and still more time-consuming than I wanted.

The other big frustration was assigning transcription work: My days were punctuated with the task of assigning and re-assigning transcription projects using dropdown menus in a web app someone had built for me previously.

I tried to get devs to automate those two things -- invoicing and assignment of work -- but I wasn't successful, and had been waiting a couple of years for this to come through.

The short version of my journey is that I learned to code and ended up building these automations as my first "real world" projects.

The medium version is that it turned out to be really fun to write software, and that I've written quite a bit more since then, both for myself and my company as well as for others (open source and contract work). Then I got a job as a data engineer solely based on my Python skills, and have been writing and maintaining a pile of Airflow DAGs, as well as the code that generates many of them, for the past couple years.

Q: Why should a "spreadsheet jockey" add something like Python to their toolbelt?

A: To simply make their life a lot easier. Sure, heavy spreadsheet users have probably hit up against the size and performance limitations of their tool, and Python- or Scala-based tools are definitely viable solutions to that. But for me the power of imperative programming, of translating steps A to Z that you normally perform in a spreadsheet into human- and machine-readable language, is a magic you can't ignore once you know about it.

On the ground, this magic translates into massive productivity gains, and frees you up to do higher-level thinking and experimentation which you don't normally have time for.

Q: What tips do you have for others trying to expand their skillset later in life with limited time and resources for learning?

A: That's a hard one because I actually had abundant time and sufficient resources for learning and noodling around with Python and, later on, JS. I know someone like Danny Thompson would say -- or at least model -- "sleep less, work when your kids are sleeping," etc., but I'm not totally sure that's doable for many. Personally, I'm pretty sensitive to sleep deprivation.

So here's a path that could work for a subset of the "later in life coding learners" which resembles mine at least a little: Find ways to make your job more productive using Python or JS. If there's something mind-numbing and/or repetitive which you'd like to not do anymore, make that the project you build as you're learning to code. Automate the Boring Stuff is a great jumping-off point.

If you can't think of anything to automate, you're probably not looking hard enough. 😆 But if you think harder and still can't come up with anything, email me!

Q: How do you fight imposter syndrome after a mid-career switch?

A: I have no answer for this, as I still fight the syndrome on a daily basis! Anecdotally this doesn't really go away, even for CS majors with successful startup acquisitions, etc. My current theory for why this could be is the largely solitudinous nature of writing software. I don't think coding has to be a solo activity, but it's just worked out that way for most of us. As you know, Waylon, I really enjoy pair programming, especially as a way to teach and learn, but I also think it's a great way to fight the syndrome. This is partly because you'll inevitably discover that everyone's knowledge is uneven and that there's always something you as a novice can teach a more experienced dev.

To put it in simpler terms, how can you even know whether you're an imposter if you work in a one-person silo all day?

Q: Where can we find you online?

A: That'd be here!