PodSearch

Under the Radar

52: Learning, Sometimes Willingly

 

00:00:00   Welcome to Under the Radar, a show about independent iOS app development.

00:00:03   I'm Mark O'Arment.

00:00:04   And I'm David Smith. Under the Radar is never longer than 30 minutes, so let's get started.

00:00:08   So today I wanted to talk about learning, and about learning in a professional context.

00:00:17   And in a weird way, it's learning when you're fairly established in a career and in a skill set.

00:00:24   And the reason I wanted to talk about this is because of some struggles I've been having

00:00:29   recently as I've been trying to learn Swift. So ever since Swift 3 was announced to WWDC,

00:00:36   it's been something that I've had in the back of my mind that, okay, now is finally the time that

00:00:44   I need to learn this. That for career and professional development reasons,

00:00:49   I can't just keep writing Objective-C, even though I'm most comfortable with that,

00:00:53   even though I know how everything works there, even though I may even have some

00:00:57   reservations about the way Swift works, that ultimately if I want to continue to make a

00:01:02   living on this platform, I'm going to need to learn Swift, and so I need to try and do that.

00:01:06   But the mechanics of actually learning something new, it turns out, not perhaps unsurprisingly,

00:01:13   is kind of difficult. And it's not, you know, learning Swift, I've found for myself,

00:01:19   isn't like, oh, it's, you know, Objective-C just dressed up differently. It's fundamentally a very

00:01:25   different approach to development. And this is the part where I kind of have a brief digression into

00:01:32   talking about my feelings, and I know there's a better show on Real AFM if you want to hear about

00:01:36   feelings, but we're going to have to borrow that for a moment. What I've found as I've been learning

00:01:42   Swift is I kind of feel really stupid, and that really is a rough way to feel in a professional

00:01:52   context where I look at something that, in general, I would say that I am an advanced iOS developer.

00:02:00   If you've ever flipped over the back of a programming book and they'll have that little

00:02:04   gauge on the back where it's like, "This is for beginners! This is intermediate! This is advanced!"

00:02:09   It's like, I would say that I'm an advanced developer. I've been doing this for eight years,

00:02:12   professionally, full-time, I've built some apps that have some very wide audiences,

00:02:17   I'm pretty good at this. And that confidence is really a complicated thing when that then gets

00:02:24   broken by trying to learn something that seems like, superficially, it should be doable, it should

00:02:32   be easy, it should be something that I can pick up. But what I've found with Swift as I've tried

00:02:37   to learn it is that it hasn't. That I end up feeling kind of stupid, and I read these blog

00:02:42   posts with titles like, I've pulled up a couple of ones that recently just hurt my head, where it was

00:02:48   "Enum, raw values, and failable initializers," or "optional non-escaping closures." And I read those,

00:02:56   and it makes me think of, if you've ever read the title of "PhD Theses," and you kind of look at

00:03:03   this thing that looks completely foreign and looks completely abstract to you, and I look at it,

00:03:10   it's like, "But I should understand what this is. I'm a professional programmer. I have a degree in

00:03:16   computer science, I have a master's degree in software engineering, I've been programming

00:03:20   professionally for something like 26 years. Why don't I understand this?" And I've been struggling

00:03:27   as I've been doing that with reconciling that feeling of, "I feel," and the best word I have

00:03:33   for it is "I feel stupid." I feel like, "Oh, why can't I get this?" And what I kind of wanted to

00:03:38   unpack on this show is talk a little bit about just in general learning things that are difficult.

00:03:43   And I also feel like whenever I've encountered these kinds of struggles in my own professional

00:03:48   career, and I've had a venue like a podcast to talk about them, it's always been encouraging

00:03:55   both for myself to kind of just get it out and put it to the side that I don't have to feel like,

00:03:59   "Oh, I feel," almost not ashamed, but "I feel bad that I'm not able to do this." And then I always

00:04:04   get feedback from people who say, "I feel the same way. Thank you for saying that." And so that's why

00:04:08   I kind of wanted to bring it up. And then hopefully, towards the end, we can talk a little

00:04:11   bit about strategies for working through it. But learning is tough. And I think especially as I get

00:04:16   older in my career, it's like the old dog's new tricks maybe kind of a thing, but it gets hard to

00:04:23   have that fresh mind to be a student still. I mean, I haven't been in an academic environment

00:04:29   for something like 10 years now. So whenever I have to sit down and be like, "Okay, let me open

00:04:35   up the Swift programming language guide in iBooks and try and read it and learn from it," that's an

00:04:40   experience that is kind of intimidating. Yeah, I mean, and in the case of Swift in particular,

00:04:46   it really kind of is exacerbated by the problem that Swift is a very complex language and that it

00:04:53   has a lot of very advanced features, like from a language design perspective. And the kind of posts

00:04:58   you're reading about, these are really about the evolution of the language, and these are by people

00:05:03   who are themselves language design nerds and the highest level of language designer that is working

00:05:11   on Swift. There's like cutting edge new language that has really advanced and complicated design.

00:05:16   If you think about other languages that you know, I know you use Ruby for web stuff, I use PHP for

00:05:24   web stuff, and we both know Objective-C. There really is not this kind of open discussion

00:05:30   in the world about ongoing substantial changes to Objective-C. And so we really haven't needed

00:05:38   to participate in that. Objective-C did most of its maturing, with some exceptions, but most of

00:05:44   its design and maturing before we were using it. So we just got to come up and just learn this

00:05:48   language, and there's lots of really weird things about it that really just don't really come up in

00:05:52   practice or that you just kind of picked up over time, and it isn't very intimidating as a result.

00:05:58   Same thing with PHP and Ruby for me at least. I started using PHP when mostly,

00:06:03   somewhat in version 4, most of my PHP experience was with PHP 5 and above, and that makes it of

00:06:10   course a lot easier to lose a lot of the legacy stuff, but also I came to it with already this

00:06:17   pretty developed language there. People make fun of it, but the reality is this pretty developed

00:06:22   language there, I didn't have to be a part of all these discussions with it early on or even now,

00:06:28   like now these discussions still happen, I just ignore them. I just check about once a year to

00:06:33   see what's new in PHPX, and that's fine, that's all I really need. And the language itself,

00:06:39   like when you're writing in PHP or Ruby, the language itself is simple enough that

00:06:44   basically it only gets complicated if you make it complicated in your code. And I think what we see

00:06:52   from Swift now is, the language first of all I think is more complicated in general than what

00:06:59   we're used to, regardless of how simple your code is, but we're also seeing these arguments happening

00:07:04   in real time in this very early stage of the language, where we're seeing people argue about

00:07:08   really obscure advanced behaviors that we in our Swift applications might never use, or might not

00:07:15   need to know about, or might not care about for a while until we become advanced with developers

00:07:19   like down the road. So I think part of your concern with Swift in particular is justified,

00:07:25   but part of it's also just because of the state the language is in developmentally,

00:07:29   and the circles we run in with people who are very smart arguing about very advanced things

00:07:34   about its language. >> Yeah, and I think one of the things that I've definitely run into a lot

00:07:37   with Swift that makes, that compounds this kind of, this feeling of inadequacy or whatever to

00:07:44   write it is, I feel like Swift is a kind of a language that has a certain amount of inherent

00:07:50   correctness to it. And by that I mean, it seems like a language that if you write Swift the right

00:07:59   way, it's like this beautiful, elegant poetry that just can incredibly encapsulate complex

00:08:08   interactions or designs in a really concise, clever, clear way. But if you don't,

00:08:15   it kind of is punishing to you. I found this, I mean, something that I still struggle with,

00:08:22   and I'm still only working on my first Swift project, and it's taking a lot longer than I

00:08:27   thought it would take, partly because I'm dealing with these kind of complicated feelings and

00:08:33   situations, but I feel like I'm constantly being punished by the compiler, where it's like I write

00:08:38   something that is sort of valid in the sense that it is, I'm clearly describing what I think I would

00:08:47   like my application to do, but Swift has all of these safeguards and mechanisms, and you have this

00:08:53   concept of optionality, and if you don't write it all out correctly, you get all these warnings and

00:08:58   compiler messages that it's like, "Oh, no, no, no, you're using a variable there. That variable

00:09:02   could or could not be nil. What are you going to do?" And if you aren't good at it, it feels

00:09:10   slightly punishing. So I really struggle with this tension between, there's these very sort of more

00:09:16   esoteric language features and structures that I keep feeling like, well, maybe if I just understood

00:09:23   how that works, I could avoid all of this problem and just kind of get into the flow of it.

00:09:29   And certainly some of it is just having more experience, but it's a tricky language, whereas

00:09:33   I feel like in Objective-C, you can write almost anything you want, and as long as it's syntactically

00:09:40   correct, it'll compile and run, and whether or not it works is up to you, whereas Swift has more

00:09:47   opinions about your code, which you could argue would make it better, right? There's fewer mistakes

00:09:53   that you are going to be able to write in Swift because it just won't let you. All these things

00:10:00   that in Objective-C would probably come up as, if you did the build and analyze on your project,

00:10:07   it would give you all these warnings like, "Oh, here you're using a variable that you never

00:10:11   initiated," or things like that. Swift just won't let you do that, period. But it can feel kind of

00:10:18   this punishing cycle that makes me feel like, "Oh, no, I need to be more academic. I need to be more

00:10:23   correct." But learning how to be more correct and be more academic is a rough chasm to cross,

00:10:31   especially coming from a world of Objective-C where that just wasn't the case. And you could

00:10:36   write Objective-C in that kind of way, I imagine, but that's not the way that I wrote Objective-C,

00:10:40   so it feels awkward as a result. - Yeah, I mean, to give one example, last night I wrote a division

00:10:50   statement, and one of the operands was a large integer, I think it was a 64-bit integer, and the

00:10:56   other one was a double, and I'm writing this in Objective-C. And I know that I should probably do

00:11:03   a cast on one of them to ensure that it does whether I wanted an integer division or a floating

00:11:10   point division. As a programmer, I should explicitly choose which one of those I want and explicitly

00:11:16   cast them so that it works, but I didn't because I'm like, "You know what? It actually doesn't

00:11:20   matter." If it does both as integers, it'll still give the result I want given the values I expect

00:11:28   these to have, so it doesn't matter. So I just didn't specify, and it'll do one or the other,

00:11:34   and I don't know which one because I don't know the precedent rules well enough, but it'll be

00:11:39   fine, and it'll work just fine. In Swift, I don't know Swift well enough to know whether it would

00:11:45   yell at me for that, but I think it would, right? >> It will. Absolutely, it will. I've run into

00:11:49   this many times when I try and do work in core graphics. So you have a CG floats and regular

00:11:55   floats and doubles, and even though they're sort of the same thing but you have to cast back and

00:12:00   forth between them if you're moving, I absolutely would say, "No, no, no, no. You need to tell me

00:12:05   exactly what you want to have happen here." >> Right, and so you can totally see the value

00:12:10   of that. That makes sense when you're writing lots of different kinds. Basically, my argument

00:12:15   in my mind when I didn't pick one of these was, "You know what? Either way, it'll be fine. Either

00:12:20   way, it'll do what I want it to do, so it doesn't matter." But that kind of thinking can often lead

00:12:26   to bugs down the road if you think that way or you make assumptions in places where it does matter

00:12:32   and where these things might be different or might do things you don't expect, or you might get

00:12:37   values in there that behave differently that cause really hard-to-find bugs that you didn't really

00:12:42   plan for. So Swift kind of forces you to plan for that, but it forces you to always plan for that

00:12:47   with every single thing you write. And I think the reality in the real world of software development

00:12:53   is that oftentimes you're writing software where not only does it not matter whether you pick the

00:12:58   right thing here, but you don't even have the time to spend on it to be that formal about it.

00:13:05   >>

00:13:11   That development feels harder, and the nature of learning something new and the nature of,

00:13:17   in this case, learn picking up Swift, for example, is it's always going to feel harder. And it almost

00:13:23   certainly is this kind of hill that you have to climb, that it's harder, harder, harder,

00:13:28   and then at a certain point you kind of fall down the other side, and it's like, "Oh, great,

00:13:31   now it's easy again." But climbing that hill is a really hard thing to do. I'm not really going to

00:13:38   get into the questions of, "Is it worth doing? Is it justified the time and effort?" But moreover,

00:13:44   what I've noticed to myself that I wanted to kind of unpack is, whenever I encounter something—and

00:13:49   in this case it's Swift, but just as easily it could be a new framework, it could be a new

00:13:55   platform, it could be a new thing like the Apple Watch or the iPad—whenever I encounter something

00:14:02   that I find difficult, I know for myself my instinct is, unfortunately, to start avoiding it.

00:14:09   It is amazing, and I'm probably not alone in this, that a developer's ability to find work that feels

00:14:18   vaguely productive that they can do instead of doing the thing that's hard, that they know they

00:14:24   should do but don't actually kind of want to do, it is amazing. The projects and the little tasks

00:14:31   and, "Oh, maybe if I write this little script to automate this thing that I'm doing once every six

00:14:35   months," that seems totally reasonable use of my time, when in reality all I'm doing is saying,

00:14:42   "I don't want to deal with this because of how it makes me feel," is the reality. If I unpack it

00:14:47   three levels, it's like, I don't like feeling doing difficult things, and so I'm instead not

00:14:53   going to do anything, and I'm just going to avoid the problem and hope that it goes away, I suppose,

00:14:58   somehow the code's going to write itself. But that pattern is something that I see in myself that I

00:15:03   really wish that I was able to change, and is something that is a real struggle, I feel like,

00:15:10   for really getting into that learning process, of really getting better at something and getting

00:15:15   over that hump, is forcing yourself to say, "No, I'm a grown-up, I can do this, I need to buckle

00:15:22   down and just work through the hard part to get to the part that I know will eventually become easy,

00:15:29   and hopefully be worthwhile at the end." - The response to this week by Braintree.

00:15:34   Go to braintreepayments.com/radar to learn more. Why make payment integration more difficult than

00:15:40   it has to be? Braintree's powerful full-stack payment platform allows you to accept nearly

00:15:45   any type of payment from any device with just one integration. It's flexible to your system's needs

00:15:51   and supports most languages. So whether you're using Java, Ruby, or Python, you'll always have

00:15:55   a range of server-side and client-side SDKs available. The Braintree code also supports

00:16:00   Android, iOS, and JavaScript clients, and it takes just 10 lines of code to implement.

00:16:06   Braintree makes payments and your job as a developer of these payments a whole lot easier.

00:16:11   Learn more at braintreepayments.com/radar. Thanks to Braintree for sponsoring our show.

00:16:16   - So the last area that seems like it might be a helpful thing to talk about is when you and I

00:16:23   are learning things, how we actually go about doing that, kind of unpacking the mechanics.

00:16:28   - Begrudgingly? - Yeah, other than begrudgingly,

00:16:31   how the actual tools and methods that we found to be most helpful. And I'll start off by saying,

00:16:37   one thing that I have always found to be the most helpful when I'm trying to learn something is to

00:16:44   have a reason to do it. If I have some kind of project that I'm motivated about,

00:16:50   that I'm interested in, something that will-- I can feel a sense of accomplishment while I do

00:16:56   things. I've never been somebody who can get a book, sit down, read it, and then have learned

00:17:04   something as a result. I have to be much more practical than that, and I have to have something

00:17:09   that I'm doing to build it. When I wanted to learn Objective-C, this is back eight years ago,

00:17:14   I guess, I made a tip calculator. I remember when I made it while I was on vacation with my family

00:17:20   at the beach, and I don't really like the beach so much, and so it was a thing for me to do back

00:17:26   in my room when other people were down at the beach. And that's how I learned Objective-C,

00:17:30   is I found this practical thing and I just sat there and I worked at it until it worked. But

00:17:36   I felt like it was nice that at the end of the day I could show myself, "Hey, I built something,

00:17:40   I felt this was cool." And for me, I found that to be always the most helpful. As soon as you can get

00:17:46   into Xcode, the sooner you can get into actually doing something rather than keeping it up in

00:17:52   the more esoteric realms, the better. For me, the best way to start learning is to just actually

00:17:59   start building something. And then beyond that, I find that the best way to really understand

00:18:07   something is to start trying to expose yourself tangentially to other people who are better at it

00:18:14   than you are. And back in the Objective-C days, I did this by going to a local NS Coder night,

00:18:20   where I used to go once a week, and I would go and listen and just kind of hang out with people

00:18:25   who were really good at Objective-C, people who had been Mac developers for years. And there's

00:18:30   something always kind of powerful about just learning from osmosis, where you just kind of

00:18:35   hang out with people and you have conversations about stuff, and you learn a lot from that. And I

00:18:41   find that that's a lot less scary. That was a lot less intimidating than sitting down with Aaron

00:18:47   Hillengast's book and being like, "Okay, chapter one, this is how this works. Chapter two, this is

00:18:52   how this works." You kind of build up that way. And then lastly, and this is something that I've

00:18:58   been starting to do with Swift, is trying to find alternative mediums that I can use. So I've started

00:19:04   to listen to Swift podcasts. And my favorite one for that is the Runtime podcast with Sam Sophos

00:19:10   and Caleb Davenport, which is a great-- they talk about Swift stuff, but they don't talk about it in

00:19:16   a way that is scary to me or academic. They're very practical about it, they're very pragmatic.

00:19:22   I like watching the Swift talk videos on OBJC, which is a really-- again, it's like a different

00:19:30   mechanism and a different medium to get that information into my brain. And I feel like

00:19:35   learning in general tends to have this process for me where I want to expose myself to a lot of

00:19:42   information in a slightly systematic and a slightly structured way, and then by exposing

00:19:49   myself to have a broader breadth of just vague bits and pieces, then when I encounter a situation

00:19:56   that I'm like, "Huh, this sounds like that thing that I remember so-and-so talking about," and I

00:20:01   can go and look it up and then pull that in, it's much easier for me to start building that vague

00:20:08   toolset in a way that-- in Objective-C, for example, I do that now by, "Huh, I remember

00:20:14   building an application three years ago that did this same thing. I wonder how I solved that

00:20:20   problem then." And I can go and open that project and find the function and look at it and be like,

00:20:26   "Yeah, yeah, that's totally the way to do it." But without having a broad base of existing code to

00:20:31   do it, I can create a proxy for that by just exposing myself as broadly as I can. What do

00:20:39   you do when you're trying to learn something new? What approaches do you take? Well, first, I love

00:20:43   that you learn Objective-C as a procrastination work item to avoid learning how to light the beach.

00:20:50   Yeah, that's true. That's amazing. And now I'm learning Swift to

00:20:53   avoid writing Objective-C, I guess. But yeah, I'm pretty much just like you. I really am

00:20:59   task-driven in the sense that I, too, need a project to make with technique or language or API

00:21:08   X. If I don't have a project in mind that I'm motivated to make exist in some way,

00:21:14   then I generally don't learn new things. And that's probably not a good thing. I should probably

00:21:19   fix that in my personality. But we are who we are. That's probably not going to happen. So yeah,

00:21:25   you know, I learned Objective-C a while back, before anybody knew who I was. I learned it to

00:21:33   make a couple of little hobby programs here to play with simple stuff like the Mac Speech Recognizer.

00:21:37   But then I really didn't know much of it until I was motivated to make an Instapaper app for the

00:21:46   newly announced iPhone SDK in 2008. And so that's what I did. And I learned it just as I went. And

00:21:54   along the way, I learned UIKit. I learned SQLite. I learned all sorts of stuff as needed along the

00:21:59   way. Same thing with web development. I didn't do anything really with learning stuff for the web,

00:22:05   besides just basically fooling around until I wanted to make my own site, and then make

00:22:08   web apps, and then things like that. And I think that's how I learned from there. More recently,

00:22:12   more specific things, I learned a lot about Core Audio. Because I had this feature in Overcast

00:22:19   that I wanted to exist, the Smart Speed feature, before it was even called Overcast. And it wasn't

00:22:25   easy or possible to do it without learning this new API and set of technologies. So I learned them

00:22:30   as I went. And I had this project, and I just kind of plowed through. Usually I don't do a lot of book

00:22:37   reading. Sometimes I'll occasionally read an academic paper to get a certain algorithm that

00:22:43   I might need. But usually that's not going on. Usually I don't do things that even need that kind

00:22:48   of advanced algorithm. As most of us, I think most of our work involves pretty mundane things,

00:22:54   just doing it in certain orders. And yeah, so I basically just learn things as I go and as needed.

00:23:00   And it's usually through lots of just trial and error, reading documentation, doing web

00:23:06   searches that usually let me on Stack Overflow. I mean, my God, do you remember how bad it was

00:23:09   before Stack Overflow? - It's a scary thing to remember. I don't know how we wrote anything.

00:23:15   - Yeah, it's like how to use computers before there was a mouse, right? How did we program

00:23:20   before there was Stack Overflow? But yeah, I mean, that's pretty much it. And one of the reasons why

00:23:27   I have trouble learning new things, just kind of for the sake of it, like learning Swift when I

00:23:32   already know Objective-C, is that it doesn't have that same kind of driving motivation behind it.

00:23:37   I'm not motivated to replace a language or a tool set that I already know with something that does

00:23:44   the same things, approximately. And it might do those things differently. But whatever it is that

00:23:50   a lot of people have that makes them curious and driven about new things and new frameworks and new

00:23:56   technologies and new languages, I don't have that in me. I'm not motivated to learn something simply

00:24:02   because it is a new way to do something that I'm already doing. To me, it's like, well, I don't

00:24:07   need to learn Ruby 'cause I already know PHP. And then PHP solves all my web backend needs so well

00:24:13   that I don't, that Ruby tends to solve that same set of problems, and I already have a tool that

00:24:18   does that. So I don't need to learn that. What I would rather do is learn a whole new kind of tool

00:24:24   with whatever my time and mental budget is for learning new things, I'd rather go for breadth of

00:24:32   types of tools or types of APIs rather than going really deep in one area. It's like, I'm gonna

00:24:38   learn all the web languages and then figure out which web language is the best web language.

00:24:41   Even though that's how I review headphones, but that is not how I learn programming languages and

00:24:48   stuff because once I have a certain problem solved, I'm not motivated to go try to re-solve it. I'd

00:24:55   rather get really good at that tool, as good as I can possibly be at that tool, become a real expert

00:25:00   at that, and then also develop entirely new tools that do entirely different things.

00:25:04   - Yeah, and I think that's an entirely reasonable approach, but it is an awkward thing. And it

00:25:09   sounds like I wonder if you've run into something that I've run, as I've been struggling with

00:25:13   learning, I've started to also, it makes me think in a weird way of how sometimes I joke that being

00:25:20   self-employed and being independent has made me kind of unemployable.

00:25:24   Because I've been working so long outside of the world of an actual office job, that I sometimes

00:25:34   worry that if I ever needed to or wanted to go back to that world, that I would struggle.

00:25:40   Genuinely, it would be difficult for me to do, not just like, "Ha ha, you have to fill in your

00:25:44   TPS report." It's like, no, no, it would actually be a hard thing to do at an effective level.

00:25:50   And it's making me wonder, as I've been struggling with learning too, is some of this is, I think for

00:25:57   a long time, I stopped, I kind of got to a point with my development where I stopped, I was like,

00:26:04   "Okay," I sort of like, "I know enough," and I just sort of stopped learning new stuff.

00:26:08   And that part of the skill and the actual practice of learning and of actually getting

00:26:13   better at something, I feel like I didn't do just for years, honestly. I was like, "I'm good enough

00:26:21   at Objective-C every year, something new will come out that I have to adapt to inside of it." But

00:26:25   by and large, I didn't have to exercise those muscles, I didn't have to do that work. And I

00:26:32   think as a result, it's making it harder now. And I'm trying to at this point, keep in mind that

00:26:39   if this is, you know, this is inevitably going to be a part of my career going forward. And while,

00:26:44   like you say, I'm the same way, I hate learning something for no reason. I'm not saying there's

00:26:49   no reason to learn Swift, but it's that feeling of, if I don't have a strong, intrinsic reason

00:26:55   that I just have to do this to push me, it's a really hard thing to do. But I'm also keeping in

00:27:02   the back of my mind that this is a skill like anything else that if I practice it, if I do more

00:27:08   of it, it will probably get easier. And the longer that I let the skill of learning, the skill of

00:27:15   getting better, you know, there was a time when I went to college, and while college was a different

00:27:21   kind of thing, I was really good at taking in information and then organizing it in my head and

00:27:28   putting it out on a test. Like I developed that skill to a point that now I kind of lost that

00:27:35   skill. And so I worry about letting it fall too fallow. And maybe there's something that I'm

00:27:40   trying to take for myself now of that, you know, this is never inevitably going to keep happening

00:27:46   in my career that new things are going to come around to learn. And if I want to be able to stay

00:27:51   current and relevant, I'm probably going to have to have a better sense of the skill of learning

00:27:56   and just keep practicing. And honestly, I'm sure that's going to take more discipline than I have,

00:28:01   and that's awkward. But if I'm at least not aware of that as a problem, I kind of worry that I'm

00:28:08   just going to keep getting more and more stuck in my ways and struggle to find my way out.

00:28:12   - You're making a frustratingly good case for me, Final Learning Swift.

00:28:16   - I know, right?

00:28:17   - Thanks a lot. No, I mean, you could look at it the other way, and you could say, like,

00:28:23   certain problems we've kind of moved up the stack from, and we don't need to relearn. Like,

00:28:27   we don't need to relearn different keyboard layouts. We figured out one, it's good enough,

00:28:31   and now we move on to higher level problems. You know, you figured out Objective-C forever ago,

00:28:37   and you haven't spent the last X years not learning it. You're not learning anything.

00:28:42   You spent the last X years learning APIs and frameworks and app development and structures

00:28:47   of your code and business side of things, all these other skills that you need. So it's not

00:28:52   necessarily that you're learning nothing new. It's that you're learning things at different

00:28:55   levels now and in different directions than changing the language itself. And that's not

00:29:00   to say that you should never learn a new language, but I think it's important to not discount,

00:29:05   you actually are doing lots of learning of new things, just not on that front. You've moved to

00:29:10   the side and moved up from there. And I think you're probably right, though, that we probably

00:29:16   should still learn Swift. - Yeah, because I think, and if anything, it's because it's difficult,

00:29:21   because it's hard, and because working our way through that, I think, will make us better

00:29:27   developers, and in a weird way, better people. It's a good thing to stretch ourselves.

00:29:32   - We face the adversity of learning Swift. - Yeah, exactly. And as difficult as that is,

00:29:38   and as foolish and stupid as it makes me feel sometimes, it's ultimately probably the right

00:29:43   thing to do. - All right, thanks for listening, everybody, and we'll talk to you next week.

00:29:48   - Bye.

00:29:49   Bye.