How to start learning a new API or framework

Recorded March 28th 2020 – watch the full episode on YouTube.

When you’re learning something new, do you create a new Xcode app or start a Swift playground?

John Sundell: That's a great question, and I think it all comes down to what I’m learning. And also how you prefer to learn.

So for me personally, I love Swift playgrounds and it's my go to tool for learning new things or experimenting in general, prototyping whatever it might be. I tend to start with a playground, but sometimes it's not enough. Sometimes you want to have that app context or you want to build something real with it.

For example, again going back to SwiftUI, because I think it's a good example and something a lot of people are learning right now. I started learning SwiftUI the day it came out, just like yourself. You even wrote a book about it the day it came out, which was very, very funny, but a lot of people started when it came out and I did too. I opened up a playground. I started playing around with it and I learned the API, but it wasn't until I actually built a real app using it, an app that I'm using everyday myself. I built an internal little tool for myself that I'm using every day now, and it was not until I did that, that I fully understood SwiftUI.

“I love Swift playgrounds and it's my go to tool for learning new things or experimenting in general, prototyping whatever it might be.”

And I think that is an important distinction to make as well, is that you can learn. Sometimes you can learn the API, you can learn what the classes are, you can learn how they work, but once you start putting things into practice and use it in real projects, that's when you discover the trade offs. That's when you discover the rough edges, if you will, or it might not be rough edges in the tool. It might also be gaps in your own knowledge and things you need to go back and rediscover.

So I would say in general, playgrounds for learning new APIs, things like that for experimentation, but for fully understanding a technology, I really want to build something real with it, whether it's just a small little app, whether it's just a throwaway project, whether it's a prototype, or whether it's something real.

Paul Hudson: It's that ability to say, “I get this thing on paper. I'm going to try it out,” and when you do, you realize, “well, actually this bit here isn't quite what I'd expected, what I hoped for,” because SwiftUI, it's amazing. I love what it does. I love the way it makes me think. I love the way it ties me down to write code in a certain way, because I can't just hack around anymore. It's got to be much more strict, which is good for my brain in the longterm, but at the same time, there are some things it just can't do, and you're off in UIKit land repeatedly, and as your app grows in size, you reach for more and more and more UIKit. You want collection views. You want text views. You want attributed strings, for example. None of those things are in SwiftUI.

“Sometimes you can learn the API, you can learn what the classes are, you can learn how they work, but once you start putting things into practice and use it in real projects, that's when you discover the trade offs.”

So you reach for your UIKit or MapKit or whatever you want to reach for, and that's a trade off that you wouldn't otherwise necessarily have seen. You want to change the separator intersect on your table view. It's trivial in UIKit, but SwiftUI just isn't there with the maturity or the complexity yet. It will eventually, but right now it isn't, and you might not realize that if you just read your articles or my books about it. You might go, “yeah, SwiftUI is amazing.” Until you start actually following along, trying yourself, you won't realize, “okay, I can't do that,” or, “whoa, that's surprisingly hard to do this and it was trivial in UIKit.”

“It's definitely a recommendation I always give is to try things yourself, and it also is something I always think about.”

John Sundell: It's definitely a recommendation I always give is to try things yourself, and it also is something I always think about. We mentioned writing articles and things, then I know where we're going to talk about that more in a bit, but that's something I always keep in mind as well when I'm writing, is that the way I tend to write is not this classic kind of tutorial style where you have the first thing in the article is fire up a new Xcode project, and then you can write this and this will happen, and you can write this and this will happen. I am not saying that those ways of writing are bad, and there's a lot of great sites that follow that kind of pattern or that kind of way of writing.

But I've always wanted to write more in a kind of exploratory way, where it's more like, here is a way of looking at things, here's a pattern. Now you can go off and try it yourself and you can discover how you want to apply it, or you might discover something new entirely, or you might agree with me, you might disagree with me. That doesn't really matter. For me, the goal is more to inspire. If I can inspire people after reading one of my articles to open up a playground, for example, and start hacking away on something, then I consider my mission accomplished.

Paul Hudson: The disagreeing thing's really important. I saw a tweet this morning to Erica Sadun and I about one of our recent Swift Over Coffee episodes, and we were talking about how much we like Swift's new argument parser, how it's really beautiful Swift 5.1 with the property wrappers and flexibility, and he was saying, “I disagree with you. I don't like the way it is. It's not POSIX-friendly here, here, and here.” Well I wrote back saying, “And that's cool. That's great. If we all thought the same thing, it'd be a very boring world indeed, because it's okay. Here are our views. You have your views and that's perfectly normal. We haven't got to all see exactly the same way on stuff.”

"A common trap to fall into is that you feel this need to convince everybody of your way of thinking."

John Sundell: Exactly, and this is a trap that I feel also that a lot of beginner writers are falling into, and I definitely fell into this myself, and it can also be applied to conference talks and any form of kind of sharing or any form of discussion you want to start. A common trap to fall into is that you feel this need to convince everybody of your way of thinking.

I talked about earlier how I was, as a more junior developer, very keen to convince people of my way of thinking, and I'm very happy that I've dropped that, and now I definitely don't look at my writing that way. I'm not a dependency injection salesman. I don’t get a commission every time someone writes a unit test. I'm not in the business of convincing you of X, Y, and Z.

“The goal is to inspire and to inform, also, to some extent, but more just to kind of spark something, whether that is an agreement, a disagreement, or just a curiosity.”

I am in the business of just writing about it because I like it and I'm passionate about it and I want to share it, and then what you do with it. If you read one of my articles and you say, “well, I don't want to use that,” that's great. I don't think that's a failure at all. I think that's just as much a success as if you read it and say, “I want to use that.”

The goal is to inspire and to inform, also, to some extent, but more just to kind of spark something, whether that is an agreement, a disagreement, or just a curiosity. Whatever you're sparking, that's kind of the goal for me, not necessarily to convince someone, because I just feel like that's kind of a backwards way of approaching something.

Paul Hudson: What room is there for a more sort of playful learning with ARKit or SceneKit or Core ML or Create ML? What part does that play, do you think?

John Sundell: I think that's incredibly important. I have this thing that I like to call coding for curiosity, and that is incredibly important. You're learning something because you think you might use that in the future. As much as it's important to set aside time for that, I think it's also important to set aside time for just exploratory things, and it doesn't have to be something that you think has "business value."

It can just be something that you want to do because you're interested. You think it sounds like fun, it sounds like something fun to explore, because so much of our job comes down to creativity. We have to be creative to solve problems. We have to be creative to come up with solutions. We also have to be creative in terms of creating user interfaces or different code patterns that work well.

"I have this thing that I like to call coding for curiosity, and that is incredibly important."

There's so much creativity in our jobs, and I think you can't really be creative if all you're doing is trying to just produce the highest amount of value all the time, optimize all your time as much as possible, because you're just going to kill your sense of your sense of imagination. You're just going to optimize it away, and that's something that I always keep in mind is that for me, especially now, as an independent person who has to make sure I have a good balance between doing things that pay the bills and doing things that are fun, doing things that bring value to the community, even if it might not pay the bills.

I have to balance all those things, and it's very important for me to not just focus on things that have a direct impact on my business, but something that can be just fun and creative and inspire me, because guess what? If I keep inspiring myself and I keep doing things that are fun as well, I will also discover a lot of things might make business sense in the future.

“Sometimes it can also pay off in the future, that exploration, but I think the most important part is just to have that time to kind of reignite your imagination, because we need this fuel in order to be able to solve things creatively during our day to day job.”

And I have a great example. Just yesterday, I was writing a prototype in SwiftUI. It wasn't that I was building this product and I was building this thing that I'm going to ship. I was just playing around with it, and I was playing around with it for three hours, just building different types of UIs, and I was building different blur views and putting a text field in that blur view and seeing how that would work, and I was just playing around with it, and just during those three hours, I got five different ideas for articles, just by doing that.

Sometimes it can also pay off in the future, that exploration, but I think the most important part is just to have that time to kind of reignite your imagination, because we need this fuel in order to be able to solve things creatively during our day to day job.

Paul Hudson: What are you proud of having unlearned?

John Sundell: I think it comes down to what I was talking about earlier when I was going from being like more of a junior to a senior developer, when I felt like I had to unlearn this need to push my ideas or to convince others of my ideas and to learn to more. Listen to other people and to also sometimes just try to discard my own opinion about something and just go for what the team wanted or what the team needed or just what was practical at that moment.

I used to, before I was a full time developer, this is a little fun fact about me, after I left high school, I was working with marketing for a while and I was working, I was doing some sales and things like that. So I got pretty good at just like convincing people of stuff. And that's something that I had to kind of unlearn because at some point I was maybe pushing my own, again, pushing my on opinion too much and not giving other people who might not be as good of talking about certain things, but they might still have great ideas. So I really had to kind of unlearn that behavior and try to listen more to what the other people had to say.

Sponsor Hacking with Swift and reach the world's largest Swift community!