You Don't *Have* to be a Developer

September 13, 2022

I originally wrote this post a short time into my first tech writing job on MongoDB's Server Docs team. I never ended up sharing it because, for a while, I wasn't sure if I would end up staying in the docs world or switching back into software development.

Less than a month ago, I got a new job running documentation at Gradle. My experience as a Developer Educator for MongoDB Realm Docs convinced me that documentation can scratch all of my developer itches -- building automation, infrastructure, and writing tutorials and code snippets.

I've added some thoughts at the end of the post and tightened up some language. But this post largely reflects my thoughts on working as a documentarian very early in my transition from software development. If you're currently pursuing a computer science degree, or attending a coding boot camp, or working as a developer, and it's not completely satisfying... maybe this will help.

I graduated from the University of Rochester with a B.S. in computer science and a B.A. in English in 2017. For over two years after graduation, I worked at Bloomberg as a software developer (called "FSD", or "Financial Software Developer") internally.

I spent half of that time working on a piece of internal-only software designed to make it easier to follow internal development best practices. This was stuff like jumpstarting continuous integration, providing project templates, and automating paperwork required to run services.

For the second half of my tenure at Bloomberg, I worked on a client-facing team that built both a UI and a middleware C++ layer for a report calculation engine. It was about as exciting as it sounds.

Overall, software development was a fun role. There were parts that I really liked, like digging deeply into unique, interesting optimization problems and algorithms. There also were parts I didn't like as much. That includes writing CRUD APIs or DAOs that felt like they should have been automatically generated by a script and "investigating" problems with such low impact, nobody truly cared if they were solved.

There were also parts that I felt just didn't properly gel with my personality, like most "social gatherings" and learning about financial instruments. Don't get me wrong -- there are aspects of finance that I find interesting, and parts that I think everyone should know. (Not necessarily the same parts)

"Time in the market trumps timing the market", "diversify your holdings", "make your money work for you"... these are tenets of personal finance that every responsible moneyholder ought to know. But learning about the inner workings of an obscure financial product that only analysts and professional investors will ever care about? Meh.

I guess there's always a silver lining, though: at least it beats working in advertising.

Anyway, software development was a mixed bag. Could I do it for my entire career? Absolutely. With the right team, I think software development could be rad. But despite the fact that my teammates at Bloomberg were all extremely kind and intelligent, I never really felt close enough to them to get to that point. At the end of the day, work was just work, and I didn't feel like anybody was paying enough attention (and I was never individually inspired enough) to justify putting in extra effort.

As a result, I never felt like software development scratched my creative itch the same way that college projects satisfied me.

At first, I thought that I just had to get used to my company and the subject matter of my work. I gave it a few months, but I still felt unfulfilled. Then I switched teams to try something different; maybe a larger team with younger team members and a tighter focus would fit me better?

After a year, it was... fine. I was doing well, but not great; at the end of the day, I didn't really feel like my work mattered. Eventually, I ended up browsing Hacker News "Who is Hiring" threads every month to see if the grass really was better on the other side. After all, many of my friends switched companies every couple of years; from what I've been told, it's the best way to increase your compensation when you're young. And one day a peculiar post caught my eye.

The role was "Technical Writer" for MongoDB's Server documentation group. I'd heard about technical writing before -- even thought about it as a career, though it seemed like internship opportunities were few and far between during college. But some friends had warned me away from it as a career, claiming that a lot of companies didn't really respect technical writers and you'd be better off as a developer if you had the chops to get hired as one. I still think that's true: on average, there are more opportunities to get hired as a developer and the roles pay better. But there are a few caveats to that statement that change the calculus:

  • some companies treat writers like engineers
  • technical experience (as a developer, not just education)
  • culture
  • pay isn't everything (but it's still good)
  • you have to find the right compromises for satisfying work

Note: Here ends my original writing. What follows is a reflection by my slightly-older-hopefully-wiser 2022 self.

Wow. I had a pretty good read on this career over two years ago. Two points really struck me:

As a result, I never felt like software development scratched my creative itch the same way that college projects satisfied me.

Now that I'm years into documentation writing and working my second role, this is refreshing to hear. When I wrote software, especially internal-facing software with a captive audience, I knew deep down that it didn't really matter if I did an awesome job or a bad job.

Writing documentation for open source (or open source adjacent... damn you SSPL) projects, I take pride in my work. I know that crappy documentation will make people sad, and possibly push them away from using the product. I know that great documentation can save people from hours of frustration and pain. It reminds me a great deal of TAing back in college -- sure, I could phone it in and not prepare for a workshop or a review session. But when the students suffer from your laziness, you tend not to be (too) lazy.

With the right team, I think software development could be rad. But despite the fact that my teammates at Bloomberg were all extremely kind and intelligent, I never really felt close enough to them to get to that point.

The Realm Docs/Developer Education/Education Engineering team at MongoDB is rad. Working with them was rad. I like them so much I'm keeping in touch with most of my teammates, and even some other folks from the MongoDB documentation org.

Some of it might be time-based -- you have to get comfortable with a team before you can enjoy camaraderie. But it's also personality-based -- if you work with people with common interests (or just interesting interests!), you'll inevitably learn from them and their interests will cross-pollinate into your own life. I listen to podcasts, read blogs, read books, try out hobbies, and listen to music recommended by my MongoDB coworkers. I consider them friends and role models.

TL;DR: If you're not thrilled at your current software developer job, go out and get another one. Or try something else in the industry that scratches itches that aren't currently satisfied. I know this probably seems obvious from the outside, but don't let good compensation and comfort cloud your gut instinct to find something better. You might regret it... but you probably won't.