All else being equal, I’d rather work on back-end systems, in languages like Ruby, Python, or Go, than in HTML, CSS, and JS. Chasing those preferences for my entire career had allowed my CSS skills to fall about 10 years out of date.

When I finally needed them, professionally, I couldn’t adeuqately express my thoughts in code. I wasted energy fighting my tools and my mental model, which on the internet timeline was ancient.

I felt like I was hindering my team. I was.

you are gonna need it

I was 10 years behind, and I needed to catch up. It took several weeks of frustrating effort to get there. I could have diluted that discomfort ahead of time, at my own pace, instead of under a deadline.

Chasing our preferences tends to calcify our knowledge. Specialization is valuable, but over-specialization can be harmful to our teams.

we’re not “________ developers”

Primarily considering myself a “back-end developer” was a false economy. It prevented me from being able to work effectively with a significant part of our production system when the need arose.

A “front-end developer” can be even more effective if they understand the systems behind the APIs. For example, we can make better decisions about how, and how quickly, we should query an API endpoint when we know each request’s impact on CPU, memory, storage, network, and the interactions between services.

APIs conveniently hide the complexity of back-end systems. That doesn’t necessarily absolve us of the responsibility to use them wisely.

what would you say you do here

Languages, platforms, and tools fall into and out of fashion. We don’t have to tie our identities and marketability to any one of them. We can value ourselves primarily by our ability and willingness to adapt and learn. Organizations ought to, and many do.

Our job is to take things apart and put them back together, better. We’re translators, simplifiers, and conjurers.

That never goes out of style.