About 18 months ago, I decided that it was time to look for my next job. I had only been at my employer at the time for about 2 years, and had helped them through a couple of tough things they had hired me for. I had also learned a lot about devops and maintaining a more frequent release cycle, containers, Kubernetes, and coding DBAs out of most off-shift work. At the time, I found myself gravitating towards Db2 work and away from other RDBMS platforms, largely because I didn’t have the time or mentorship to learn the relational databases I could work on (MariaDB on RDS, MS SQL Server on RDS, and DocumentDB) to a deep enough level. The workload to spend much time on them also just wasn’t there. Db2 was so comfortable and easy. Oddly, it makes me really uncomfortable to be too far into my comfort zone, so I knew it was time to change something to get me back out of my comfort zone. As has usually been true for me in changing jobs, my choice to move was based more in the work being done than organizational factors.
When I was looking for a job there were a couple of directions I was looking to go. I wanted to either change RDBMSes (which I wasn’t sure was even possible at a senior level and maintaining my income) or to change tracks entirely to technical writing – which I’ve done for years, but generally haven’t been paid to do. I recognized that if DBA work was available on Db2 wherever I landed, I would be drawn to it like a moth to a flame, and that no one in the industry was paying all that much money to write about Db2 or train people on Db2. There were several exciting opportunities in very different directions. I could have maintained my salary and been a technical writer. Ultimately I ended up choosing what turned out to be just an outstanding opportunity at Shopify.
I was brought in to Shopify a year ago with the knowledge that I did not know MySQL enough to jump right in, but with the understanding that I would work on learning and getting to a nice deep expertise on MySQL. Having fairly deep knowledge of Db2 was hugely helpful. Knowing things about how Db2 structures pages, for example, led me to quickly understand this in MySQL and reason through performance and other questions. In addition to learning MySQL, I’ve spent time learning Rails and how a database platform team (or group of teams) really runs. The scale of our database environments is really bigger than anything I saw on Db2, despite working with some large retailers over the years. The direction and speed of technical and organizational changes is also faster than I ever could have imagined, for better or worse.
My mentor for MySQL here has been absolutely amazing. If he doesn’t know the answer to my endless questions, we jump on a pairing session that can take the form of experimentation, or the form of digging deep into the MySQL code to find the details. I can’t imagine making this kind of transition without someone like him as a guide. The time and leeway I’ve been granted to learn have been awesome.
A few things I’ve learned over the last year…
Database problems everywhere are fairly similar
Developers blame performance problems on the database, and have a lot of questions for database experts. They largely don’t understand deadlocks or isolation levels, and spend little time on performance or database optimization until it’s a full-on emergency. The technical nuances of the answers to developers’ questions are different, but the general track and the need for education that meets them where they are is pretty universal. There are some exceptionally smart developers at Shopify and most of them are curious as heck, and hungry to learn, no matter what their level.
I learn best by teaching
I have spent so much time over the years writing and presenting about Db2 that both writing and presenting have become important ways for me to learn about a topic. This fits in very nicely to my current role, as I present every week or two on whatever database topic is currently hot. I learn a lot from those presentations and the discussions they spark.
It’s good to be wrong
I’ve known many of the answers or who to ask for many years in the Db2 world. They just come naturally, as does reasoning in the way that Db2 works. I’ve been wrong more often in the last year than in the preceding decade, and that’s OK. It is good to be wrong, in a way. I’ve learned from it every time, and I’ve gotten better at MySQL because of it. The culture here of stark, honest code reviews out in the open was initially disquieting, but in the long run is great. My career had taught me that, particularly as a woman in tech, I needed to spend time establishing credibility. Being a consultant taught me to avoid admitting when I didn’t know something or didn’t have experience on something. I’m a better engineer for the opposite approach. I’m getting good at variations on “I’m not sure. Does anyone else on the call know that one?”.
Managing bugs is surprisingly similar between Db2 and MySQL
While I still miss discovering a true bug, and getting a special build from IBM in a few weeks, the process for most non-urgent things is somewhat similar. You have to reproduce the scenario, understand why it’s happening (perhaps a bit deeper for MySQL by digging into the actual code), submit a bug report or feature request, and politic with the right people to get a fix rolled into the code, often months or years later.
Learning MySQL has taught me a lot about Db2
I can’t tell you how many times in the last year I’ve come to understand how MySQL does something, and then gone “Db2 doesn’t do that! … does it?”. Alternatively, while explaining how Db2 does the same thing, I see the gaps in my knowledge of Db2 and wonder “Huh, I wonder how Db2 really does that?”. I’m more and more convinced that the RDBMS organizations choose should be based on the one that fits their organizational structure best, not one that fits a purpose best. Every RDBMS out there has made choices, some intentional and some by mistake. Most of the time neither choice is really better – they just have different trade offs.
I still miss a few things about Db2
If you’re working with Db2 you should really value the genius of the Db2 optimizer and the tools around it. I miss Db2’s explain. I miss db2advis and the explain and advise tables. I miss the more cost-based paradigm (as compared to MySQL 5.7). I miss some of the monitoring available in Db2. I don’t miss the lack of information when searching for information on a topic, though judging the veracity of a random search result for MySQL is a challenge in itself. I miss CTE’s, but that will change as I get more of a chance to work with MySQL 8.0. I miss the community a bit, and I look forward to getting more involved in the MySQL community. I’ll be going to Percona Live in Denver in May.
I’ve abandoned the Master’s degree I was working on in data analytics. I deeply value and use things I learned as a part of that journey, but my love is really relational databases, and I expect to spend the rest of my career working with them.
A year in, I feel valued. I feel like I’m doing work that matters, even while still not up to the full potential I see for myself on MySQL and at Shopify. I haven’t felt tempted to cruise job offerings or pull on contacts to return to Db2. Time will tell if I’ve become addicted to learning new platforms and how deep will be deep enough for me on MySQL.