PyDev of the Week: Mike Bayer

This week we welcome Mike Bayer (@zzzeek) as our PyDev of the Week. Mike is the creator of the popular SQLAlchemy project. He has a fun Python blog and contributes to many Python projects. I've seen Mike present tutorials on SQLAlchemy at PyCon and he regularly does talks there as well (here's an example from 2014). Let's spend a few moments getting to him better!

Can you tell us a little about yourself (hobbies, education, etc):

I grew up in Long Island, the suburbs east of New York City, during the 1970s and 80s. I had my first exposure to computers in 1980 at age 12, and like everyone else who got into "home computers" at that time spent lots of time with the Basic programming language. Eventually I chose an Atari 800 as my platform in the mid-80s and I even managed to do some rudimental assembly language stuff with it. In high school I managed to get online in early pre-internet dialup forms like bulletin boards and Compuserve, I later learned Pascal in high school and in college I did major in computer engineering for part of the time, where I learned more procedural programming and data structure theory as well as languages like Modula III and apparently a little bit of Lisp as well, based on looking at my old notes recently. But in my college years, I really didn't want to be involved with computers at all so I eventually majored in music at Berklee College of Music, which I also dropped out of to just move to the city and be a drummer. In the city, my high typing speed and computer skills led me into office temp work doing word processing, which even at the lowest level paid far more than any starving musician could make, so to this day I hardly ever get to do drumming. In a lot of those jobs I ultimately ended up writing code to replace lots of the repetitive work they gave to temps and by that time, the "internet" suddenly wanted to hire everyone everywhere who could write just five lines of code so it was a natural move into the enormous late-90's internet bubble in NYC working for agencies.

Why did you start using Python?

I was doing lots of Perl at Major League Baseball, and after having spent many years doing OO work in Java I really longed for a scripting language that had good OO features. Python always seemed like it but I couldn't get past the whitespace thing. At MLB, we rolled out part of a CMS solution by giving the access to a CVS client called WinCVS, and we needed to do some scripting for it; the scripting language was Python, it forced me to work with Python long enough (20 minutes) to realize the whitespace thing was great, and the rest was history.

What other programming languages do you know and which is your favorite?

Python is definitely my all-time favorite, I've also worked a lot with Java, mostly with earlier versions, and I've also spent many years with Perl and of course Javascript as it's unavoidable. Those are the ones I have multiple years of professional experience with. Outside of those I've done a fair degree of C once in awhile, a very small amount of C++, as well as work with all the old languages in college and early jobs like Fortran, Rexx, Pascal, Modula III, Scheme, 6809 / 68000 assembly etc. none of which I'd have any idea how to use today.

What projects are you working on now?

I have this super awesome job at Red Hat, which is the first job I've ever had where the thing that we're producing is not "a website". I work with the Openstack product and the challenge I've been facing is figuring out how to get Openstack, which depending on architecture can spin up literally hundreds of Python processes, to handle sometimes thousands of connections to a database which in our case is typically a multi-master MySQL variant called Galera, in such a way that we aren't wasting resources, aren't running out of connections, and that will never go down if various database nodes or services suddenly become unavailable. It all has to be packaged so that it works that way automatically when a customer installs Red Hat's Openstack distribution for the first time.

As always, I'm also working on keeping SQLAlchemy moving forward, right now for the 1.1 release. Architecturally, documentation-wise, and feature-wise.

Which Python libraries are your favorite (core or 3rd party)?

The libraries I'm using most and have made deep investments in, include mock, argparse, py.test and sphinx. I have a deep appreciation for gevent as well. I also encourage people to use the curses library more; its style is necessarily a little old-timey but rich and colorful console applications are awesome.

What inspired you to create SQLAlchemy?

I've always wanted to have an "ultimate programming platform", and for years it seemed like I wanted to have a set of great libraries to use in Java, back when Java was new and there wasn't a lot around for it, but Java lost its shine soon enough. When I got into Python, it seemed a great place to finally build this platform, and getting basic web framework stuff going was my first goal, and then relational database access. I had already written a dozen relational database facades before so by the time I decided to do SQLAlchemy I had a lot of ideas for what it should have. There were patterns that I had worked out in various jobs that I wanted to present as a first class library, so that I would no longer have to keep writing database access layers at every new job.

Can you tell us what you've learned while working with the Python community to create packages like SQLAlchemy?

I'm amazed at how even though I had like ten years on the job experience when I started SQLAlchemy, I was still completely unsophisticated in every way; despite having been a tech manager at some jobs I still had no idea how to interact with the community, other open source developers, other open source projects, or users, or how to write real tests, how to write and maintain good APIs, anything. I had to figure it all out within my experience in the Python community, starting out with this terrible template engine called Myghty where I figured out all kinds of mistakes to not make again, and then with the first couple of years of SQLAlchemy versions where I also racked up a deep catalog of mistakes to not make again, both in the realm of the code being published as well as interactions with others.

The wisdom that saved SQLAlchemy from the fallout of this learning curve was that I had always intended for it to take ten years by itself to be really rock solid, which is why it took that much time for me to feel OK calling it 1.0. By not overselling it before it was appropriate and just waiting for it to mature very deeply and slowly and to gain a following in an organic way, the project didn't become as much of a target of derision and hasty decision-making as it definitely would have if say, people were given "SQLAlchemy 0.3" mugs at conferences in 2007. That version was outrageously bad. Things are much better now.

Thanks so much for doing the interview!