What I Like About My New Job

This is a recycled post from my tumblr weblog. I’ve since had three other jobs, but a lot of what I like still rings true 5 years later in 2020.

Please note I am contractually prohibited from saying what I don’t like about most of my prior employers so don’t expect any negative posts.

I’ve gone from developer at a large software corporation in the suburbs of Southern California to being a developer at a startup in SoMa in San Francisco. I’ve been here about three months now and this is a list of (some) of the things I like about my new job.

Continuous Integration: This is something that I took for granted almost a decade ago at a former employer and haven’t had since. When I make a change and push it to GitHub, a set of tests automatically spin up and I can’t merge to master until those tests pass. This is good, I have a self-service QA agent where I can iteratively work on an issue and finally do a PR when it’s ready.

Actual Decent Test Coverage: There’s a test suite built in to the code, not saved as an auxiliary repository. When the codebase has a decent set of tests it helps you make sure your changes don’t break anything, and it also works to make you feel guilty if you aren’t keeping the coverage levels up with your new code, creating a virtuous cycle of test writing.

Code Reviews that Actually Happen: The tooling for deploys is set up so that no code can be merged into the master branch until it gets a code review/thumbs up by at least one other non-author developer. Code can’t be checked in, period, unless it’s been hit by at least two sets of eyes.

You Can Ship a Feature Same-Day: Assuming the feature is small enough, you could sit down at 9:00 AM, implement a feature, write tests, get it code reviewed and have the code shipping by 5:00 PM to real live clients. It was frustrating waiting 16+ months to ship features/fixes at the last place, it’s refreshing to get immediate feedback on my work.

The CTO/Cofounder Still Writes Code: Certainly he doesn’t write the same volume of code he did when there were 4 developers, but the fact that the CTO still finds time to write code/add features to the product shows upper management actually cares about what’s under the hood of the product.

No Silos: There are functional teams, and there are specialists, but for the most part everyone works transparently. Meeting notes from each meeting go to an email alias everyone is subscribed to, all GitHub repos are accessible by every engineer, if you want to know how something works all you have to do is look.

Up-to-Date Documents: We use a Wiki and we’ve got people engaged enough and motivated enough to tend to it like a garden. No 5-year-old Word documents hiding as sharepoint attachments that require you to ask 5 people to see what’s no longer true/correct. If anyone finds a set of instructions confusing on a page, they go in and change it so they’re less confusing/more correct for the next person, which leads to the next point:

If Something’s Broken, You Don’t Need Permission to Fix It: We get used to little and big annoyances in every software product we use. When I first started I was a little timid about suggesting fixes, figuring things were the way they were for a reason. I’m learning now that I can fix annoyances with impunity—nobody gets mad if you make the software better, even if it’s in code you wouldn’t normally be responsible for. They’re thankful, in fact. We’ve just begun to formalize this in ‘Spring Cleaning:’ one day a month we just work on back burner/wish list items. And it’s fun.

If You Want to Do More, Do More: This is fairly straightforward: if you want to learn something new, go ahead and do it. If you want to be responsible for X, start working on X. No need for formal requests or transfers. As a riff on the above, if you want to do it, do it. This is a fantastic way to work and makes it possible to do professional development in all sorts of directions.

Public Transportation: This is more a living in the Bay Area thing. In Redlands my strategy for making a painless commute was to live as close as possible to work. Now my strategy is to just live near a train station. My commute from near SFO up to the Caltrain station in SF is about 25 minutes most mornings. In that time I can read or use my laptop, rather than feather my clutch in stop-and-go traffic and scream at other drivers. It’s nice.

Officially Sanctioned Social Events: Hearsay Social puts on little social events all the time. It’s the best way to learn what other people are up to and to form bonds outside of meetings and email. It’s really nice getting to know your coworkers in this manner and makes things smoother while actually working together.

Unofficially Sanctioned Social Events: A lot of people have common interests and like each other enough to organize small group activities. Some people do rock climbing or go to amusement parks or do a weekly board game night. It’s pretty great.

The People: As a San Francisco tech startup, the people skew a little younger than I’m used to, but everyone is smart and reasonable and easy to talk to. There’s no “watch out for that guy” warnings because there are no “that guy"s.

All in all I’m glad I came up and I’m happy with Hearsay Social.