August 30, 2021

Retrospective

Friday was my last day at Twitter, bookending a series of events that began back in January of this year. I’d honestly never expected to work at a large tech company: I’m not a fan of the downright illogical interview practices ¹ that the large majority of them employ. But, here we are.

What went well?

I got to explore one of (if not the largest) production Scala code bases in the world. I have a (rather foolish) tendency to get hooked into a specific programming language, and I’ve pretty much been writing Scala exclusively for the past 2 years. The scale of code I saw at Twitter was pretty massive. The fact that most of it was written in Scala meant that I could really see how other developers wrote Scala.

The tooling at Twitter was also incredibly impressive. I contribute on-off to http4s, and I decided to work on it a bit yesterday morning. My MacBook Pro, which isn’t a slouch by any means with its 8-core 2.3 GHz processor and 16 GB of RAM, took a solid 5 minutes to index the entire repo and build it. The IDE that Twitter uses, on the other hand, was able to index a multi-gigabyte repo in a smaller amount of time. I guess developer time really is money, and companies really optimize their tools to mimimize the time that developers spend spinning their wheels.

There’s also a ton of really nice automation around developer workflows at Twitter. You can open pull requests pretty seamlessly from the command line (I guess you can do this too with the GitHub CLI). That said, there’s a bunch of stuff that “just works” for developers and makes their jobs a lot easier.

I also discovered that I have the capability to be a pretty autonomous developer. Most questions I had were answered by the following sequence of steps:

1. Copy + paste the relevant error message/search query into Slack ². (This usually solved my problem).
2. Copy + paste the relevant error message/search query into Confluence (basically corporate Wikipedia).
3. Copy + paste the relevant error message/search query into Google.
4. Ask someone on the team.

There are basically 3 buffer zones between my question, and my having to ping a team member for help (and potentially taking them out of a flow state). Honestly, I found the answers to most of my questions from steps 1 and 2.

Does this work for every developer? I really don’t think so. It’s common for more senior developers to spend less time actually writing code, and spend more time designing systems. The questions that come up during designing a system don’t have a clear-cut answer, and require them to collaborate with other developers in real-time (or near real-time). However, for my purposes as a low-level code monkey ³, this workflow proved pretty optimal.

My general tendency toward exhausing all possible ways of answering a question without needing to ask other folks for help probably stems from when I was callled an idiot by my older brother whenever I asked for help. Thanks, I guess?

What didn’t go so well?

Turns out that getting to know a completely new team virtually is hard. Last summer, I worked at Hootsuite with my old team. It basically felt like I never left. We made the same stupid jokes, and of course, my code was roasted in the same way it had been when I first worked with them in Summer 2019. This may have informed my perception of remote work as being “pretty easy.” I guess it was “easy” because I technically already knew my team. It’s true that I had a couple of social events with my team at Twitter, but nothing really measured up to actually physically being in the same room with them. I depend a lot on body language for social cues, and this was pretty difficult when I didn’t even have empirical evidence of my team having a lower body.

That’s not to say I didn’t like my team, they were very chill and I’d like to work with them again someday (in person).

What’s next?

I’ll be going back to school for the 2nd year of my Master’s program. I finished all the course requirements, so I’ll “just” be working on my thesis. Do I have a solid idea? No. Do I struggle even now to explain what “software engineering research” is? Absolutely. What could possibly go wrong? Maybe I’ll start using these newsletters to document some of the papers I’ve read throughout a week. We’ll see.

About two weeks from now I’ll be helping to lead TA training. This upcoming fall will be the first time in 5 years that I won’t be working as a TA. It still surprises me that this is the case, but I guess I knew that I wouldn’t be doing this forever. More on not-TAing in next week’s newsletter.

Until next time.