Hello! Let’s talk about 2017 in julia’s programming/work life, not in the world-at-large.

things that went well at work

• I worked on a project (with a few other people on my team) that I was proud of! We shipped our first Kubernetes cluster. I wrote a blog post about the project on the company blog: Learning how to operate Kubernetes reliably.
• wrote a few kubernetes pull requests that got merged (this is a pretty minor accomplishment but I don’t do a lot of open source so it was a step in a direction I’m excited about)
• I mentored an intern for the first time!! And I think it went really well! (not least because the intern I got to work with was awesome)
• I stayed on the same team (modulo some reorgs), and I really like my team! We’re in charge of orchestration systems like Kubernetes & Jenkins.
• I got promoted at the beginning of the year. That was cool because I felt like I’d improved a lot and so it was nice to see that recognized.
• I got a new manager at the beginning of the year (Jay!) and I like working with him a lot.

One thing I really like about my current team is – because we do a lot of reliablity/security work, there’s a lot of focus on understanding our systems. In my current job I have a lot of space to take the time to really dig into weird stuff and figure out why it’s happening, which makes me happy. (taking the time to figure out weird things out is a lot of what that “operating Kubernetes” blog post was about).

I think maybe 2017 was the best year at work so far? I learned a lot about operations & reliability & networking & infrastructure security & containers & how to get organizational projects done, and I feel like I was able to work on some things that are important to me.

inclusion projects

It’s been a goal of mine for a long time to do projects that improve inclusion at work. This is the first year where I feel like I made some significant progress on this. (though in 2016 I wrote this infrastructure engineer job description which was also a small inclusion project!) This section is kinda long but here goes.

By “inclusion”, I basically mean – make sure that everyone’s work is recognized equally and that everyone has the same opportunities. My view is that it’s kind of everyone’s job to help build an inclusive company, so I want to sometimes make contributions in this area!

One thing I’ve found really hard is – what does “working on inclusion” actually mean? How do you do a project that results in better inclusion at your company?

I’ve come to realize that there’s a lot of inclusion work that people generally agree is a good idea (like “make our engineering ladders more objective”), but that nobody has found the time to actually do yet (see: lara hogan’s why can’t they just?). Organizational projects take a lot of time! I have some time! So if I can find a way to effectively spend my time on inclusion-themed projects, I can make a difference!

I did 2 inclusion-y projects in this direction this year: one big, one small.

Big thing: I worked on revamping our engineering career ladder, in an attempt to make it more clear and objective. I wrote the new ladder, created a lot of concrete examples, talked to more than 30 people in engineering to get their feedback, and used their feedback to improve it.

This was really hard and it took a long time (2-3 months of working on it part-time) but I think it turned out well (the new ladder is definitely more objective!) and I’m happy I spent time on it. It gave me a lot of sympathy for why this kind of change is hard to make, but also made me feel like I was empowered to make changes if I was willing to put the work in.

I did this project in collaboration with a manager who is really good at figuring out how to make organizational change. I think we were a good team – I had time to spend writing & revising the ladder (which he had less of), and he knew how to navigate the process for making the new ladder official (which I had no idea how to do).

Smaller thing (in the same area): I worked a bit on marketing internally this idea of a “Brag Document”. Basically this is a document where you write down all your accomplishments at your job so far. I think this is useful because:

• it’s a good way to reflect and see what’s going well
• it makes it easier for your manager to make the case that you should be promoted
• if you have a new manager, it tells them what you’ve been doing in your career so far (otherwise they might never find out!)
• it makes it easier to write a self-review during performance review season (perf review is tied to compensation, so it’s very useful to make sure that you actually explain what your accomplishments were)

This isn’t a revolutionary idea (“keep track of your accomplishments” is something a lot of people do!!) but I think publicizing the idea is useful because not everyone thinks to do it!

Concrete work I did on this: I helped run a workshop to get some folks to write these documents, and gave a lightning talk to all of infrastructure about why I think it can be useful to write a document like this. I don’t know how useful this will turn out to be, but we’ll see!

(Of course I didn’t do either of these things by myself, and lots of people work in these areas independently of me. I got to work with some managers (will & jay, my current manager) who helped me a lot to figure out what it means to work on inclusion. And the fact that working on projects like this is something that’s actively rewarded/encouraged by leadership is of course a huge part of what makes it possible/sustainable to do.)

what’s a tech lead?

For the second half of 2017 I’ve been a “tech lead” on my team, and I’ve been trying to figure out what that… means. It definitely doesn’t mean I’m in charge of making all of the decisions – everyone on the team makes decisions, and I certainly don’t have all the answers! :). So what does it mean? Some things that I’ve been focusing on:

• make sure new folks on the team have the information/support they need to get stuff done
• make sure the projects we’re working on have a manageable scope and that we understand clearly why we’re doing them
• communicate with people outside of our team about what our team is doing

I think I still have a lot to learn about this role, but those 3 things are all things that I think are important, that take time, and are things that I can do. So that’s good!

“make sure that when there are incidents we actually fully understand exactly why they happened” is also a thing I pay a lot of attention to, though I think everybody else does too.

Someone internally did a survey of things different “tech leads” inside infrastructure do, and discovered that different people have very different styles, and there isn’t any single way to do it.

zines

Enough work things!

I released 4 zines this year. (see https://jvns.ca/zines): 3 regular zines and one collection of the comics I made last year. That is 4 times as many as last year!

I’m working on a zine about perf right now, so there will be at least one zine next year. I continued to give out zines at every conference talk I give which I’m very happy about.

talks

talks from this year:

• keynoted PyCon Canada (“so you want to be a wizard”)
• keynoted SRECon (“so you want to be a wizard”)
• keynoted QCon Shanghai (“so you want to be a wizard”)
• spoke at Monitorama (“linux debugging tools you’ll love”)
• attended netdev, on linux kernel networking (I didn’t speak, but mentioning it just because I think I learned more from it than from any of the 4 conferences I spoke at. Food for thought.)

Basically I wrote one keynote-y talk (So you want to be a wizard) and gave it 3 times. I think the version from PyCon Canada in November was maybe my favourite, I’m excited for the video to be up. It was fun to get to go to Shanghai!

speaking plans for 2018:

• go to StarCon next week (“so you want to be a wizard”, for the last time)
• speak at Deconstruct in May, which I’ll write a new talk for (likely about building open source projects & what I did on sabbatical, which is still unknown because it hasn’t happened yet)
• maybe give one talk in an interesting new country in October/November?
• maybe go to a Ruby conference, since I’m working on Ruby tooling right now and haven’t met many of folks in the Ruby community?
• maybe apply to Strange Loop again (I spoke there in 2014 & 2016, so in keeping with the theme of strange loop in even years…? =))

One vague idea for talks & writing in 2018 is – in 2017 I talked about how to learn. I have talked a lot here about how to learn. I sort of feel like maybe I’ve covered that? Maybe in 2018 I will talk about how to build new things that did not exist before. I still feel like I have a lot of room to get better at building, especially building-in-the-open outside of work.

blogging

I wrote 77 posts in 2017. Blogging themes in 2017 included:

• kubernetes (since I spent like half the year working on it). for instance this post about how the scheduler works that i wrote when fixing a bug in the scheduler
• linux networking (related to Kubernetes, and some of my team’s other work)
• operations & reliability (what can developers learn from being on call?)
• linux profiling & tracing (as usual)
• Rust (leading up to working in Rust for the next 3 months)
• random things about cool things on the internet (like Binder)

There’s an ongoing issue where I write about linux profiling & tracing tools a lot but I don’t actually work with those things that often in my day-to-day work. This is weird. I’m excited to spend some time writing a profiler in the next few months to change that temporarily.

sabbatical

In 2017 I did a cool thing for myself – I planned a sabbatical for myself in the first quarter of this year, to work on Ruby profiling tools. It officially starts tomorrow!

I feel really happy with past-julia’s foresight in planning some time off to do a new interesting thing. And it’s a good reminder that cool interesting opportunities don’t just happen, I need to do work to plan them and figure out how to make them work in my life.