8 years at D2L and counting
Some years ago, a friend of mine told me I should check out the company he worked for. There was a position that was focused solely on SQL Server. At the time I didn’t think of myself as a database developer, I was a software developer with a knack for SQL. But I applied and it wasn’t long before I signed on.
It’s been over eight years and I still work for D2L, a vendor best known for its Learning Management System educational software.
I get to show up to a different job every day. The variety is amazing. Officially though I’ve only had positions with four distinct teams.
Job 1: In House Consultant
When I started at D2L my position was Senior Software Developer, but really I just wanted to be know as the database guy. The first couple years were about learning SQL Server and building reputation. A number of things helped with my reputation at D2L.
- A friend of mine, Richard, left D2L leaving a sort of gap behind. Richard was known by many as the developer to talk to for answers. After he left, people began wondering who to talk to and I saw that was an opportunity for me. I tried to fill those shoes, at least for database issues.
- Firefighting. Unfortunately, putting out a fire is more visible than preventing one in the first place. But I had enough opportunities to do both.
- The SQL Server technical community. You guys had my back. If I didn’t know an answer immediately, I could find out. You guys were a tremendous resource. See 3 Problem Solving Resources That Make You Look Like A Genius.
Eventually I felt some sort of obligation to give back to the database community and so I started this blog. The act of blogging can actually help clarify fuzzy ideas.
As D2L grew, so did the separation of duties. DBAs do DBA work and developers develop. But as a vendor, developers retain a lot of the control and responsibilities typically associated with DBAs. For example, at D2L, developers are responsible for indexing a table properly. It’s part of the product. We also have a large say in deployment, performance, scalability and concurrency.
So I had several years of fantastic on-the-job training facing new scalability challenges gradually. And as time went on, I worked on more preventative and proactive efforts.
Job 2: Business Intelligence
Then I chose to work with an analytics team. Everyone was talking about “Big Data” which was the new buzzword and I was excited about the opportunity to learn how to do it right.
It was a project based in part on Kimball’s approach to data warehousing. I worked with a great team and faced a number of challenges.
My reputation as the database guy still meant that I was getting asked to tackle problems on other teams. But I didn’t see them as interruptions. Eventually those “distractions” just showed me that I missed the world of relational data. So a year later, I changed jobs again.
Job 3: Project Argon*
So I joined a team called Argon. Our job was to overhaul the way we deliver and deploy our software. It was exciting and we enjoyed a lot of successes. One friend Scott MacLellan writes a lot more about what we did on his own blog. For example “Deploys Becoming Boring”
For my part I had fun writing
- A tool that asserted schema alignment for any given database for some expected version of our product.
- A tool that could efficiently cascade deletes along defined foreign keys in batches (giving up atomicity for that privilege).
I still found myself working as an internal consultant. Still helping out with production issues and still having a blast doing it.
*Fun fact, Argon is the third project in my career with a noble gas for a codename, the other two being Neon and Xenon
Job 4: Samurai Team
Then at the end of 2015 I changed jobs again. This is where it gets good. All that internal consulting I’ve been doing? That’s my full-time job now.
A couple months ago I joined a brand new team with an initial mandate to “make our product stable”. We’re given the autonomy to determine what that means and how best to carry it out. I’m focused on the database side of that and I’m having a great time.
It’s still mainly technical work, but anything that increases software stability is in scope.
- If internal training is needed, we can provide that. That’s in scope.
- If increased Devops is needed (blurring the lines or increasing collaboration between devs and DBAs) we do that too.
What’s fun and what’s effective don’t often overlap, but at the moment they do.
Continued Blog Writing!
And I get to write and draw about it as I have been for over five years! Speaking of which, I got some news January 1st:
