In 2015, I wrote about my next steps in Artsy’s engineering career ladder. I laid out the steps that I would be focusing on, like multiplying effectiveness of cross-team work and having an obvious technical impact on the team’s strategic trajectory. I’ve made progress on these points, to varying degrees, but that’s not what I want to talk about.

Back then, after listing all the things I wanted to focus on, I casually mention some other items that I’d skipped.

There are other, more technical things like “own a large scale and impact service” …

In hindsight, I maybe treated these “technical things” as though they were inevitable and would just happen on their own. But just like the community-oriented qualifications, technical skills are things that I need to consciously practice to improve at. To some extent, I might have neglected them.

I mean, don’t get me wrong. I made occasional contributions (mostly in Ruby), I built new open source tools (mostly in Ruby), I even rewrote my website (in Ruby). I stayed in my comfort zone – heck, I didn’t even learn Rails!

That changed about a year ago, when I talked to my manager about breaking outside of the iOS developer box. I told him that I wanted to contribute to mission-critical backend systems, to help build web frontends written in new languages, to experiment with unproven technologies and evaluate their applications at Artsy.

It’s been a slow process. I haven’t just been learning new things, I’ve also been helping other team members contribute to Artsy’s iOS code. I can’t just leave the iOS codebases – I have responsibilities. I was doing things like pairing on our Scala codebase, which was totally new to me, while also pairing on our iOS codebases, which I helped write.

My progress was stunted at times by setbacks in my depression treatment. Sometimes I would take one step forward and two steps back. That sucked. I made progress where I could and tried to accept that developing new skills takes time.

Contributions to non-iOS codebases were minor at first: arduous pull requests that changed some button’s text or added some field to a model object. Simple stuff. I was making contributions, but each one was a challenge.

Recently, things have been different. I started making contributions to a few distinct projects a week. Then a few distinct projects a day. I sought out exposure to building new-to-me kinds of software, with new-to-me practices and new-to-me conventions. It was hard. It sucked. It ruled. I doubted myself a lot.

On the upside, learning language after framework after methodology helped develop my intuition and pattern-recognition. I can more quickly recognize the similarities and differences between different types of software. Now, I can jump into a new project and pretty quickly make meaningful contributions.

It. Feels. Amazing.

Take this week: I released a new version of Artsy’s main iOS app, helped profile and limit GraphQL request complexity, tuned server logging, worked on a new feature in a Rails app, undertook a refactor in a Scala backend – all while keeping on top of my responsibilities in the open source community. Cool!

So what? Well.

There’s perspective that comes with experience in different programming languages. Not just languages: systems, communities, and contexts. For example, when I step into another programming community, I have the opportunity to look back and see the iOS developer community from a distance. Sometimes I really like what I see. Sometimes I don’t. I try to bring that perspective back with me and improve things. Perspective makes you do that.

The more I learn, the more I realize I have to learn. I make progress only to learn that the goal – my vision of an idealized developer – is even further away than I thought. Like Zeno, I’ll never make it to a finish line. I don’t think that feeling will ever change, but I’m learning to accept the fact that the finish line doesn’t exist: the journey is the reward.