I started writing iOS applications in 2009. By 2012, I had immersed myself deeply enough in the world of iOS development that I had co-authored a book on Objective-C. I took a great deal of professional pride in crafting delightful user experiences in iOS applications, and thought I would carry on this kind of work for a long time. (You can read the whole story here).
Let me put it to you this way: at companies with both iOS and web developers, those two groups often don’t overlap. Or even interact all that much. They don’t share programming languages, they don’t share developer tooling, sometimes they are on entirely different teams from one another. They are distinct teams with distinct cultures.
In my work at Artsy, I no longer feel that distinction.
You might think this sounds awful – that I only see the downsides of both platforms. And yeah, that’s actually something I’ve had to deal with. But it’s not all bad: dual perspectives help me share the best that each world has to offer with the other. It’s why Artsy’s entire engineering team now has a healthy, conservative policy about adopting new dependencies. It’s why our web engineers, even if they’ve never done iOS development before, can pitch in on iOS work when we have a tight deadline.
This “we all have so much to learn from each other” idea is kind of my whole… it’s my whole thing. Like, if I had to distill the drive of my professional practice into a single sentence, it would be: “We all have so much to learn from each other.” I care about this a lot. In 2014, back when Swift was still in beta, my first ever talk on Swift was a call to action: we Swift developers need to steal the best ideas from other programming language communities. Moya was one of those ideas.
And so when I saw SE-250, a request from the Swift community to have
Apple Swift develop an “official” Swift style guide and tooling to enforce it, despite existing community options, a distinction crystallized in my mind. It kind of hit me, actually. A huge difference between the cultures of the two communities.
I did try to be value-neutral in my wording, though I admit that it’s not obvious from what I wrote that I do see value in both approaches. And this tweet definitely generalizes both communities – there are folks with these attitudes in both camps. I followed up with this note:
This is really key: pointing out a difference exists isn’t the same thing as asserting “this is good” or “this is bad”; it’s just “this exists.” I’m endlessly fascinated by these differences and I’ve learned that you can only really learn from a difference if you approach it with an open mind and genuine curiosity. (This skill, of being interested while staying neutral, is something I learned in cognitive behavioural therapy.)
My absolute favourite reply came from Reginald Braithwaite, who compared the difference between native iOS and JS to the difference between renting and owning your home:
The reason I love this response is because I think there are benefits to both renting and owning your home. I like renting, actually, because it keeps me mobile – I can pick up and move from one city or neighbourhood to wherever I want. It’s not for everyone, but it’s right for me at this point in my life. (And I couldn’t afford to buy a house in Manhattan anyway, so.)
Not to mix metaphors too much, but I was reminded of this Steve Jobs WWDC Fireside Chat (25:02) from 1997. Jobs also used the metaphor of a building to describe how software gets developed:
(With Apple’s tools), you can build an app you couldn’t build on any (other) platform. And, to me, this is the most exciting. (…) Because it’s all about managing complexity. You’re developers, you know that. It’s all about managing complexity. It’s like scaffolding, right? You erect some scaffolding, and if you keep going up and up and up, and eventually the scaffolding collapses under its own weight. That’s what building software is. It’s “how much scaffolding can you erect before the whole thing collapses under its own weight?” (…) We all know that. It’s about managing complexity.
(Apple’s) tools allow you to not have to worry about 90% of the stuff you’ve worried about, so you can erect your five stories of scaffolding, but you’re starting on story number twenty three instead of story number six. You can get a lot higher. (Emphasis added)
Jobs is saying that a team can only really build an app that’s so complex, but they can start building from a higher starting point to build a building/app that nets out to be higher/better. Those starting stories of the building are Apple’s tools and platforms. When I first saw this video a few years ago, so much of Apple’s behaviour “clicked” for me.
Apple sees themselves as landlords. Remember: no value judgement (I’ve had some bad landlords, too). They see their role as a provider of foundations, upon which software can be built; Apple benefits because better software built on their platform increases the value of that platform. Developers benefit because they can make better software on those foundations.
It’s important for me to re-iterate that neither one of these is “better.” They are different languages, with different goals and different constraints. Any comparison between the two is necessarily apples-to-oranges. And while I enjoy getting to use them both, that comes with its own costs. We’re all on our own paths, and that’s totally okay.
Go ahead and hit “Send” to get started. (Note: if you prefer, you can read the source code with this conversation’s script on GitHub. Scroll about halfway down.)
This isn’t a compressive list, and my opinions are constantly evolving. I try to be aware of my biases and blindspots, and I try not to assume that my experiences apply universally. These observations are obviously based on my experience of moving between iOS and web, which isn’t typical.
What’s important is that when you see a difference between what you know and what someone else knows, you approach that with an open mind. Don’t jump to conclusions. Be curious about differences and always look for something you can learn.
In the beginner’s mind there are many possibilities, in the expert’s mind there are few. —Shunryu Suzuki, Zen Mind, Beginner’s Mind, 1970
If you’re an expert in one thing, it’s going to feel uncomfortable to branch out and become a beginner again. It was terrifying for me. But if you push through that discomfort, you can gain valuable perspective that will only help you be a better professional.