The Engineering Leader

Tim Condon on Server Side Swift with Vapor

Steve Westgarth Season 1 Episode 14

This week my guest is Tim Condon, a member of the Vapor core team and server side swift team lead at raywenderlich.com.

In this episode we discuss all things Server Side Swift including the new concurrency features coming to Vapor with the introduction of Async Await. We also discuss whether Vapor really is production ready and what organisations can do to help engineers protect themselves from the dangers introduced by package dependencies.

Steve Westgarth:

My name is Steve Westgarth. And this is the engineering leader. Hello, and welcome to the engineering leader, a weekly podcast where I talk to folks working within the software engineering community, helping us to collectively raise the bar and build better software product for our customers. For the first time this week, the engineering leader is also being published on YouTube. So hello to anyone who is listening via our YouTube channel. Let me start by telling you a secret. You also write bad code. If you disagree, you may as well switch off. For those of you new to the engineering leader. This podcast is all about sharing best practice and insight. Over the last few weeks, I've really enjoyed talking to some awesome people and have had some great conversations. We've met folks working on iOS and Android, people working within healthcare tech. And we've also chatted about approaches to building really high performing teams. If you're enjoying listening to the show, please let me know. You can find me on Twitter at Steve Westgarth or just search for Steve Westgarth on LinkedIn. It would also really help me if you could share a link to the podcast so other leaders just like you can find the show and help us to collectively grow together. Now without further ado, let's go to this week's guest. This week I'm joined by Tim Condon. Tim is a software engineer and a member of the vapour core team. He founded broken hands a company specialising in server side swift consultancy and training and delivers talks and workshops around the world. He has also the service sites with Team Lead and Ray wonderlic.com. The organiser of the server side swift conference vapour, London, and vapour dub dub DC meetups. Tim, thank you so much for joining the engineering leader today.

Tim Condon:

Thanks for having me, it's great to be

Steve Westgarth:

you know what, it's really great to talk to you again, it kind of feels like a while since we've had a proper a proper catch up and seeing what's going on. Obviously, we've known each other for a few years. And I guess vapour has always been your thing. So what's happening in vape, what

Tim Condon:

Yes, vapour has always been my thing. So vapour is kind of undergoing some kind of, it's in the middle of a big change. So we're shifting from using kind of old school futures and promises to sort of new concurrency model and kind of everything that that encompasses. So we released the async await to release the initial async await API's, back in October when Mac OS 12 was released. And we're kind of evolving on that and seeing how that goes. So it's really nice, because it means that the kind of barrier to entry for learning server side Swift is massively reduced. Because of instead of, instead of having to learn a whole new asynchronous framework and tools, you can just use Swift concurrency like you use on any other sort of platform. So that's really great. And then alongside that, we're also doing kind of big rebranding efforts to kind of bring us into the kind of the modern world. So we've had very similar designs and Docs and that kind of stuff for the last few years now. It's really time to kind of lift those up, make them consistent, and kind of help onboard people a lot easier.

Steve Westgarth:

So I guess some people would argue that introducing concurrency to a language in 2022 kind of feels quite late. If you compare that to two other frameworks maybe react or something, JavaScript has had that for years, even dotnet has had async await your probably for four or five years. Do you think that held vapour back at all?

Tim Condon:

Probably has held it back a little bit. Yeah. The hardest part of learning vapour and any other server side swift framework really has always been learning how to use futures and promises. It's kind of a, it is a big learning curve. And there's kind of weird quirks around the differences between flat map and map and flat map throwing. And so that's always been a little bit of a stumbling block for new people. And yeah, it probably has kind of given people a bit more things to think about and when they're learning. So it's been there, but we haven't really had an option because swift hasn't had a concurrency model. So we've had to wait for that. But I really can't we have because the way it's turned out has been phenomenal.

Steve Westgarth:

Definitely. I'm very conscious. We've jumped straight in and we've started talking around what the latest things are in vapour and I'm also conscious that some of the audience might not actually know what vapour is. So let's rewind a little bit and start talking about what is vapour and what does it really mean for server side Swift.

Tim Condon:

Yeah, okay, let's go back then. So vapour is a framework for building server applications, web apps, API's, rest API's, etc. Using the Swift programming language, so it's kind of similar kind of level to Laravel Ruby on Rails, that kind of thing. And it provides a nice high level abstraction for building kind of any kind of server apps that you need for a back end. So vape has been around since 2016, just after Swift was open sourced and released on Linux. And we've been through four major releases since then. So we're currently a vapour for, which has been out for the last year and a half, maybe even two years. And so we've kind of built up quite a big user base, and some really nice API's for building applications that feel like you're writing Swift code, as opposed to writing a web framework, and the language just happens to be swift.

Steve Westgarth:

And I guess you've been central to quite a lot of that build out. I mean, you've told me several times have you literally wrote the book. So what inspired you to to get involved with vapour and the vapour community and to go so all in on the framework?

Tim Condon:

Yes, I've been involved with vapour since pretty much the summer of 2016. And when it first came out, I think was February 2016, was the first commit. So at the time, I was working as a mobile developer, writing apps in Kotlin, Java, Objective C and Swift. I was also doing some Python stuff, for back end, a little bit of Ruby, and some JavaScript stuff. And I was kind of getting fed up of all these different languages. Like I wanted to kind of specialise in something, and really kind of learn something. And a lot of the other languages that I was using at the time, had their weird quirks. And I liked having type safety. I liked having a compiler to catch things before you ship them. And that kind of static typing really kind of appealed to me. So as I was learning Swift, I kind of came across vapour got some traction quite early on. So I started looking into it, and then decided to put one of my websites over, which was a blog. So like any other good engineer, I wrote a blogging engine from scratch, using vapour as the kind of framework to power at all. And that's became one of the bigger open source projects using vapour and became a bit of a demonstration project for all the different features of vapour hat. And that got me involved in the community got me involved in kind of contributing back to the framework itself. I was writing articles about it. I got I ended up writing a book and doing a video series for free wonderlic.com, which is a big tutorial site for iOS and mobile developers. And since then, I've just got more and more involved. And then that led to me going full time consulting, and then joined the core team. About a year ago now. Yeah. Last year.

Steve Westgarth:

And I guess, I mean, that was a big shift, right? Because I mean, at the time, you you decided to make the shift to vapour and you say, you are working as a mobile engineer. So I think you were working at the BBC at the time. And I guess your that was, you know, quite a solid job, you know, you kind of your had a good career prospects, you know, a good opportunity to can stay within quite large corporation and, and invest very much in mobile development. I mean, that must have been a big shift for you to say, hey, you know what, I'm gonna go all out and go consulting on this new framework that, you know, may or may not take off.

Tim Condon:

Yeah, I mean, it is a risky move. The BBC is obviously a very stable place to be for the most part. And it's a fantastic place to learn and grow. Because you're working on apps and code bases that are used by hundreds of millions of people, like our instal, bases for some of our apps are enormous. And the scale that we work at is difficult to match in most other companies, you have to go to kind of want the really big tech companies to see that at scale. So there is a huge amount of learning there and some work some work on some really great projects. And what some really great people, but I've been there for four years or so I felt like I'd learnt a huge amount. And I am not the kind of person who deals very well with red tape and politics. And like any company of any kind of significant size. There's red tape and politics. So I was kind of getting to the point where I was using this framework, I'm getting really into it. I had some interest for doing consultancy work on the side and just decided to take the plunge. I initially I went down to four days a week at the BBC, which gave me kind of think of that doing that for six to nine months or so. Which kind of gave me the opportunity to try doing full time server side Swift, or at least one day a week. Try seeing like what the appetite was fresh out there for consulting and training and some contract work, and also allowed me along with the book to build up a bit of a financial buffer so that I could say, when I go full time it gives, I had like, a year's worth of living expenses that I could stretch out. So if I didn't get any work for a year, I could still pay the bills or pay my mortgage, still live kind of a relatively normal life without having to start eating pasture every night. So that kind of gave me the confidence to try that out. And also in tech, we're incredibly lucky. Like the market is very much in favour of engineers. And if it all went wrong, and deeper disappeared, and I got no work, I could always go and find another job. I was fairly confident that if I had to go and find another job in a month, I could probably pick something that's quite quite. So we're very lucky in that aspect.

Steve Westgarth:

And then that obviously spawned broken hands, which is your company where you go consulting? So what are you trying to do with broken hands? And who do you work with and and what what what have you achieved? So broken hands

Tim Condon:

is it's kind of a way of me. Providing my knowledge and expertise I've built up over the last six years now working on vapour and as a way of me of kind of evangelising server side Swift. So I wear many different hats. I run training courses for companies. So it could be that they have an iOS team that they want to build a specific back end like a BFF for their iOS app. So I run a training course and teach them how to use vapour. I've also run training courses for companies that are kind of more in with server side Swift, so all their back end is built with vapour. And they're recruiting back end engineers who have learned go and Ruby and Java. And so I'll teach them swift and then vapour. So that's kind of the training aspect. I do some consultancy stuff as well. So I advise a few companies on how to deploy server side swift applications, how to kind of scale Swift, how to talk to senior management about it, or I'll talk to senior management myself. So I will talk with CTOs and VPs and kind of, I guess, allay any fears that they have about Swift, kind of go through some of the details go through vapour and how he kind of handles security incidences and kind of make sure they're comfortable with using Swift on the server. And then the final part is helping companies build out sub swift projects and libraries and frameworks. So I have a few people who work for me. And we work on client projects, either building working alongside their dev team, or building them solutions for during service with Swift. So it might be they want to use server side, Swift might be that they have a team that's using server side Swift, and they need some help. Or in some situations as well. It might be they just want a back end. And I know them through networking. And so I'll build them the back end of that just happens to be swift.

Steve Westgarth:

Wow. And I mean, it sounds as if that's been quite successful. You've obviously done that with quite a few companies. Now. It sounds as if quite a few companies are actually taking the plunge and, and moving into vapour which is really phenomenal to see.

Tim Condon:

Yeah, it's the conversations have definitely changed over the last three or four years. It's definitely gone from how can I be sure that this is ready for production? To more? How can I use this in my company. These days, there's less of a concern about whether Swift is around for the kind of long duration, about whether it's ready for production in invertebrates, and more about kind of the suitability for their particular use cases. So it might be that they have a pretty unique use case that involves a lot of dynamic stuff. And all they want to do some kind of AI stuff and swift probably isn't the right tool for that service. Or it might be they want to write some really high performance stuff. And their current code is kind of consuming tonnes of memory. And Swift is a great use case for that.

Steve Westgarth:

I guess. I guess building that conference is still difficult though, because you know, although you're right, I think swift apps use around for the long term. But vapour is just a framework. And if you look back in 2019 And you know what IBM decided to pull out of Swift as an open source language? I guess that your that sent shockwaves throughout the vapour community and you're in right across you everybody would work with Swift and server side swift especially. And I mean, actually, the software development community I guess, stepped up in order to save Cateura so yeah, how do you how do you really build that confidence to say that you know, vapour vapour is here to stay?

Tim Condon:

So yeah, so when Cateura kind of had its funding pulled? It was it was, it was blowed the kind of I'm sorry, Swift ecosystem, but it wasn't from the inside, it wasn't as bad as what the outside view was. We Cateura was kind of going down a kind of a different route to vapour vapour was kind of going all in on the kind of server ecosystems are building on top of all the API's Apple were providing. So I think like swift Neo, and really trying to integrate into that environment, Cateura were kind of more of a enterprise feel they were moving a bit slower because they had enterprise customers. And they were trying to have, they're doing the kind of typical enterprise thing of building layers and layers of abstractions. So they weren't integrating directly with the ecosystem. So they were very different approaches. And also Cateura was obviously backed by IBM, which is a huge, huge corporation. And as soon as as soon as IBM decided that opening fund funding, that was equatorial was essentially dead, dead in the water until the community sector, paper has always been a community project, it's been a community driven framework. We have 10s, and 10s of maintainers, we have hundreds and hundreds of contributors. So if it were to be the case, let's say I stepped away from vapour or any of the other cool teams that breathe in vapour. There are plenty of people there to kind of step up and take that role over. And we're not beholden to one company, we have lots of different sponsors, we have lots of different people working for us. So if one company decides that server side, Swift is no longer for them, it's kind of like we're more diversified, really, with our risk. So we can kind of take that and move and evolve and find others to fill that role.

Steve Westgarth:

And I mean, that's really great to see. And when we have seen examples in the mobile community, where you have had your particular frameworks or particular technologies backed by individual companies, and those companies have pulled away I mean, I remember a few years ago, with with powers, for example, which was predominately backed by Facebook, and Facebook decided, no, we're stopping support for powers. And that caused a huge amount of issues for your great number of companies and individuals. So I mean, I guess you're you're protecting that within within vapour is, the more the software development community needs to do in order to protect itself and isolate itself from from those sorts of issues?

Tim Condon:

Yeah, I think like, the first thing a software developer community needs to do is be very careful about dependencies that it takes. And that goes for any kind of language in any kind of software in any kind of platform. No, GS is a very good example of how things can go wrong very quickly, in terms of like malicious packages being inserted into dependency chain. And that causes huge problems. But then No, Jess has a huge community, and they can move very quickly to fix that. So that's kind of one way and that the software developer, developer community should be careful in the way they take dependencies. I think there's definitely a habit certainly for smaller companies, all kind of startups and Junior, more junior developers to kind of try and find a dependency to solve their problem. And it might not, might not be the best thing, it might be better to just write it yourself. And you should always be very conscious about pulling in a dependency. And that includes things like paper as well. And make sure you're comfortable with what that dependency does. And what would happen if that dependency no longer worked. So we have to be very careful and so swift world in that any dependencies that we put in, if there are security issues, we need to make sure that we can step in and fix them if the maintainer of an individual package can't. So as any developer should, they should make sure they can take that that role if they need to. So it's making sure you're kind of comfortable with what the dependencies do and whether you actually need them or not.

Steve Westgarth:

It is something that the companies have a huge issues with. I mean, so I speak as the global head of engineering for for GSK. And you know, we've got a growing development team, and we're very dependent upon developers, you're doing the right thing and understanding their their space. And when you're looking at things like you're introducing dependencies and getting in new packages, or whatever, there is quite a lot of trust has got to be placed in individual development teams to say that they are actually doing their appropriate due diligence and making sure that what we're bringing into the code base is is the right thing to do. And it's not going to cause us any issues. You've worked with lots of developers before, you know, what strategies have you used as a leader to help people to make sure that you know, they are doing a proper due diligence.

Tim Condon:

So there's a number of things you can do. The first is obviously take a look at the codebase. Does it look well written? Generally by looking at a code base, you can see if it's a project that's worth using quite quite quickly, does it have tests that have good test coverage? Does it have CI? Is the code well maintained? Is it well documented? Does it read Well, can you take a look at the code and actually look at what it's doing? Or is it all obscure variable names that you can kind of understand what's going on. So you definitely kind of need to look into that and see what what's going on. The other thing that should really do as well as tribes abstract away your dependencies to a degree, there are some cases where this isn't possible. But there are other cases where you should definitely do it. So if you're pulling in, say, a networking library to make network requests, you should definitely abstract that behind a protocol or an interface. Because not only will that make writing tests much easier, and reduce kind of your dependencies on your tests, it means that if that project was disappear, then all your code doesn't know about that dependency, it's only that kind of one interface that knows about that dependency. And that makes it much easier to switch to a different networking library. If that networking library disappears, and it makes it easier to test. So that's kind of definitely a good thing that people should do. And the other thing that I think people should do, or certainly companies should do, at least is kind of throw support more behind open source projects, I think we're definitely seeing a bit of change of winds over the last year or so. And the log for J naught logfile, G, nothing yet go for J. That kind of vulnerability issue. And the focus on support that companies were providing for that is definitely shining a light on how open source is funded, and how companies are supporting packages that we're using. So if you're a company that's using a package, and you're entirely dependent on it, are you helping support that project, whether that's engineering time, whether that's submitting pull requests back, whether that's financial support, there's lots of ways that companies can help support the projects that they're using.

Steve Westgarth:

And I think there is a huge benefit in that open ecosystem, I think your large corporates are starting to understand it more and starting to kind of get the idea of why the open source community is such a powerful thing. I mean, after all, it will be impossible for one company to develop absolutely everything they want to use, and we're much stronger together than we are yours as an individual entity. When you've been talking to senior managers in your consultancy role, how how do you how do you explain that to them? I think,

Tim Condon:

generally, money is the easiest way. You can say to them, if you want to build a framework for writing backends, it's going to cost you 10s of 1000s of man hours to build them right that if you support an open source framework that's already written and suits your needs, you can save significant amounts by using the work that people have already done. But that doesn't mean that you can't just take it for free and forget about it. Plenty of big companies that use open source projects end up having to either fork them or tweak them to suit their needs. And most of those things can be upstreams. And so it might be a new feature. It might be bug fixes, it might be tweaking configuration, it might be making the docs a bit better. A lot of those are valuable to send back. So it's kind of ensuring that senior managers know that open source goes two ways. And I think most of the people I've spoken to are kind of fairly aware of that and are happy for their engineering teams to spend a bit of time contributing back. And recognising that it's effectively working for the greater good, because if no company contributed back, then they wouldn't have a framework to build.

Steve Westgarth:

Yet it's so important. And I think it's it's something which which really does yo it is getting traction, but it's still needs. It still needs more evangelism to continue to promote your kind of what you're all of those benefits. Just want to bring the conversation back to server side Swift. And I mean, I guess, you know, over the last few years, we've obviously seen your huge development in the space. And I guess you I was reading one of your blogs actually. And then maybe one of the pivotal moments in the last couple of years was the point that Ted krummenacher Your produced his roadmap for server side Swift. Just wondering if you can talk a little bit to the roadmap and kind of your weight where you think in the server side Swift is is heading to and what what's next in the in the area?

Tim Condon:

Yeah, so I should probably clarify that that roadmap was actually the roadmap for swift in general, and the roadmap to Swift six, but pretty much every point on that was heavily focused on suicide or at least heavy beneficial to suicide. So swift itself has kind of been going on a bit of a journey. So we've had like the last four or five iterations of Swift have been kind of nice and incremental. We've had some big changes with the kind of the great renaming swift three codable and swift for swift five has introduced a lot of new language features. Um, but kind of migrating to Swift six is going to be a big challenge that's going to really kind of take swift to the next level. So the focus on Swift six predominantly is going to be around data safety and concurrency. So in Swift 5.5 async await was released. And that provides the current concurrency model for swift, using the async await keywords, similar in the way that C sharp works and JavaScript books, at least at very high level, under the hood is very different. Swift, 5.6 and 5.7 have started to introduce more kind of concepts for protecting data that's read across different threads, and in different concurrent environments. So there's a thing called sendible, which is basically a way of marking your data as essentially thread safe so that it can be accessed from any asynchronous context without being worried without worrying about it, affecting something in a different thread. And those kinds of things, will give you compiler errors if you try and make data accesses across different threads, which is huge. No other language, no other mainstream language has a really has anything like that. And so you'll be able to your compiler will be able to tell you if you have race conditions in your code, which is huge. And that's going to really kind of solidify the safety of Swift. And there's some other things that Swift is introducing, like distributed actors. So Swift 5.5, introduced the concept of an actor, which is kind of part of the sendible journey actor as a way of isolating access to a class or an object across threads. So any anything inside that object can access its own properties synchronously and absolutely fine. But anything outside that object needs to access it asynchronously, because it might be coming from a different thread and might have to queue up and kind of wait for these different queries to come in. So there's concepts now of distributed actors, which is doing that effectively across processes, and across computer instances. So you could have an instance that's running in California, and instances running in New York and instances running in Europe. And all three of those will be synchronised with their data accesses. And that's guaranteed by the compiler, which is phenomenal. It's something that like Lang has kind of played about with, but Swift is really kind of pushing the boundaries of what can be done, which is awesome. And those kinds of things are really useful for so swift.

Steve Westgarth:

So I've also noticed that swift now has a BS code extension. How important do you think that is for the future of Swift beyond iOS?

Tim Condon:

So I think it's definitely an important step. I wouldn't say it's a game changer. Swift has been available on other platforms, like Linux, since 2016. So it's been supporting different variants of Linux since 2016. And more and more variants have been added over the years. And it has been running on Windows for last couple of years, fairly well. And there's a few edge cases that need to be sorted out. But it's getting there. So I think having an extension that for VS code that shows that the language can be written on other platforms is a very important step for kind of convincing people that isn't just an app learning language. The extension itself is phenomenal. I've been using it for the last few months, since it was released, essentially. And it does a very, very good job of making swift development. Easy. It supports everything you'd expect. It's very similar. It's has all the same features Xcode, because it uses the same underlying engines. It also integrates well with other Visual Studio Code extensions. So one of them is the remote development experience, which allows you to quickly spin up your Swift application in a Linux application or Linux environments using Docker. That if you want to just try out and see does it work on this branch of Linux with this version of Swift, it's a single command you're running, you can debug and you can run your code and you can put breakpoints and you can step in and that makes it really, really powerful, something that kind of No, that it currently has. So I think the the extension is a very important step. I think. Swift and specifically server side, swift and vapour do a pretty terrible job of selling themselves as a language and a framework for multiple platforms. I think vapour is currently doing its kind of rebranding as I mentioned, and part of that is going to be doing a better job of evangelising ourselves and In a better job of showcasing all the companies using vapour, and talking about the different projects and products that use vapour a very high scale. And I think swift can do the same. Swift recently announced that the website was getting open sourced, so swift at all will be open sourced. So I hope as part of that, that will allow us to enable us to put swift on the server on the kind of very front page. So I'd love to see you go to Swift org. And it comes up with Swift and then there's a link for the client and the link for the server, and right on the front page, so anyone go into that thing will immediately see that it's used for across different applications. So it's an interesting time. And I think I'm really excited to see where it goes. And

Steve Westgarth:

you mentioned evangelism there and how important that is to to the vaping. Community. I noticed recently that you really started going to you're pushing that on the various blogs and trying to get people involved in in evangelising about the framework. Why is that so important? And how can people get involved?

Tim Condon:

Yeah, so like, kind of like any other open source projects, we're generally reliant on word of mouth. So whether that's people writing blog posts about us, whether that's people doing conference talks about us, whether it's doing video tutorials on YouTube, about us. That's the way we get our kind of examples out there and showcases out there and kind of get heard by people. So we, the vapour core team announced a kind of a big programme of changes a few months ago. And part of that is the rebranding, part of that is improving the docs, part of that is setting ourselves and one part of that is going to be a vapour Vangelis programme. So we want to kind of recognise the people that are out there, spending their own time talking at conferences about vapour, doing video tutorials about vapour writing lots and lots of blog posts about vapour and just kind of give them a bit of recognition really, because, like I said, Open Source works both ways. And they're doing a great job selling vapour and kind of getting people interested in it and showcasing how to use it. So we want to kind of just give back a little bit. So that will be will kind of give them a bit of swags we have a bit T shirts and stickers, which again, helps if they're doing video tutorials, because it kind of allows us to kind of advertise ourselves a little bit, and give them a bit of recognition. And we can kind of link to them on our website and showcase and kind of give them support. So if they're talking at conferences, I've done hundreds of conference talks these days. So I can give them advice, kind of talk through them kind of go through the slides, kind of give them some pointers and tips for talking at conferences, just to kind of give them that kind of feedback and encouragement and recognition for kind of what they do for vapour.

Steve Westgarth:

And awesome. And talking to conferences. You did organise the server side swift conference back in 2019. Now obviously, welcome to pandemic and in person events haven't really been a thing. But is that something that we can expect to come back anytime soon? Yes.

Tim Condon:

So we had first set asides with conferences 2018. The second one was 2019, and then obviously Coronavirus, but stopped that, but we are planning on being back. I'm hoping this year end of this year, we're just kind of trying to get some things in places and signed off before we announce anything. So if there's something we're actively playing, I'm hoping we can have a 2022 edition. And stay tuned for some interesting news about that. I

Steve Westgarth:

can't wait to see that. And then talking about conferences, you know. So again, I'm very passionate about in person events. And I also about your talking about his conferences. And I think you're for my own career, it's been something which is has been really powerful to actually get up in front of an audience into to talk about what I'm into and what I'm working on. And all of those things. It's something I actively encourage your members of my team to do. You'll be getting other conferences to do networking, or you're maybe even to go up on the stage and actually give a conference talk and they are right. What made you think that you really wanted to get up on stage and talk your what was it? What was it that really pulled you into that?

Tim Condon:

That's a very good question. I like I always enjoyed kind of public speaking. And being able to sell something I'm passionate about and talk about and kind of demonstrate is very appealing, I think it really kind of focuses your knowledge. So if you're gonna get up on stage in front of a few 100 people and talk about a subject, it really kind of makes you make sure that you know about that subject. And it's a great way of kind of broadcasting information and knowledge. YouTube videos are great, but people can kind of skip through them and kind of fast forward or just ignore them. blog posts are good, but people can skim them but a kind of a conference talk is a really good way of engaging with people and kind of talking to people and you kind of Have that almost immediate feedback because you can kind of tell from what the audience is doing. And if they're interested in, you can kind of tweak your talk and change the level of his app, if you get different conferences, or if you see that it's just grabbing people's heads. Or if people are bored, you can kind of tweak it and go into more depth or kind of go to higher level or slightly slower pace. And so it's a really unique way of talking to people. And yes, the networking conferences are the best place to meet people and talk to people. And personally, it's a great way for me to catch up with old friends and talk to people using vapour. Because I always get people coming up to me in talking about vapour and asking questions, and kind of getting that face to face time that you wouldn't really get for a framework that's has used all around the world. And from a professional point of view, conferences are fantastic for networking. They generate tonnes of business for me, because I can go and talk about a subject or be there and know about people talking about subjects or run workshops. And that just drives kind of business for me, it gets people thinking about it gets people knowing that I do training courses or consultancy work, it gets my face out there. And people kind of know that I know what I'm talking about. And that just brings people to me to ask about running training courses, or, or we have this one problem, or we're thinking about doing this, could you come in and talk to us for a day or so. So from a professional point of view, they're, they're great for generating business.

Steve Westgarth:

And so if there was an engineer listening, who was thinking, hey, you know what, I really want to have to take that step. And maybe you'll get up on the stage where we give a conference talk or, or you know, maybe maybe get involved in that aspect of the community, what what advice would you give them?

Tim Condon:

The first thing I would say is work out what you're interested in, stoked about. Because if you're not interested in the subject you're talking about, it comes across very obviously on stage. The second thing I would say is that people who are thinking about giving talks are trying to give talks, assume that they have to give a very, very technical talk about something very, very new and very, very exciting. And give the most amazing talk that will blow everyone away, that no one else can know about. Talk about. And it really doesn't have to be like that, you can give a talk about something like a problem that you've had and how you fix that. Or you can give something kind of more holistic about how you're running engineering teams, or about how you can ensure they have good design, or there's tonnes of topics that you can talk about that don't have to be, here's how to debug CLS, just reading by just reading assembly code. People want a variety of topics, and they want to find something that people that they're interested. And just like speakers, conference, attendees not gonna be interested in everything. So if the talks are all, here's how to build a swift UI application, than the conference attendees is gonna get fairly bored. If it's kind of differences and different talks that apply to them, then they're gonna get interested. So if you have a unique perspective on something, whether that's solving a problem, or overcoming something at work, or a new solution you found or any framework you found, just give a talk about it. I think also a good thing to start at meetups as well, there are loads of meetups around the UK and around the world. And they're a quick, great way to get into talking. Because instead of talking 200 people in on a stage, you'll be talking 1020 people in a room in the meeting room, and it's a lot more relaxed. And it's great way to practice talks, and I like to try and give every talk I give a conference at a meet up first. Because you kind of learn so much from that first one through the front of real people.

Steve Westgarth:

Absolutely. And I think it's something that, you know, people get very nervous about maybe getting on stage for the first time or, or getting in front of people just to kind of talk about something, I think, as you say, you know, it doesn't really kind of focus the mind to make sure you really know your subject matter. And know what you're talking about, which is yours is really important. But I mean, so rewarding. I don't know if you would agree with that. But I think yeah, oh, yes. Yeah. I think the software development community I mean, so so engaged in a welcoming as well. I mean, you're you almost have don't see that in any other community. You're anywhere that I've seen anyway, you're a community of people who are literally willing to welcome you with open arms and give back so much advice.

Tim Condon:

Yeah, that's definitely and that goes. So if you're talking at a conference, where you've got to remember is that most of the people in the audience would never dare stepping on stage. And they only have admiration for you going up on stage and talking about something you're interested in. So far, you've even said your first words, you're already kind of impressing people by getting up on stage. And as you said, like the iOS community and the Swift community that I've experienced. I've been incredibly welcoming. I was at a conference last week, Swift heroes in Turin and a couple of people had technical difficulties on stage and the attendees just clapped when they got them sorted and were really supportive. So I'd say to people thinking about getting in, don't worry about it. Like, everyone makes mistakes. I've had plenty of conference talks that have gone horribly, horribly wrong. But people have been nothing but supportive. And the fact that you're getting up there is better than most people.

Steve Westgarth:

Absolutely. So talking of learning, I noticed that Swift is participating in Google Summer, Summer of Code this year. And how important is those sorts of activities for the community?

Tim Condon:

So Google Summer of Code is a project run by Google to enable students to contribute to projects techspot has taken by every year, I think, so we've seen some really interesting topics come out of that. So one of the ones that I've been using is the Swift tracing stuff. And that's a library for tracing or distributed tracing, sorry. So that's a library for tracing requests across different micro services in a way that works across all different frameworks and projects. So for library implements, Swift distributed tracing, it doesn't matter what tracing back end you use and how many projects you use. They all use tracing them, the tracing links up, and you can see requests across different micro services. So there's been some really cool projects that come out of that, and really useful projects that will be used. And some of the ones that have been purchased here include the Kafka, Kafka client, I think, some work on backtraces, for crashes. So they're a really good opportunity for people wanting to get into Swift and swift on the server to work a dedicated problem with really good mentors for a few months and ship something that's actually really useful and used by lots of people. So it's a great thing for the community on the language.

Steve Westgarth:

Absolutely. And I guess you're just turning our attention back to Swift and to your apple and kind of what's new and kind of what's coming downstream. You mentioned swift UI, which is I guess, one of the the game changing things that has come out in the in the Apple ecosystem in the last couple of years. You're aware, where do you think we're at now your W, WWDC is up, you're coming up in a couple of months time. You're Where do you reckon we're going as a community and what's next?

Tim Condon:

So it's interesting, because the server side swift world is all open source. So we pretty much know what's coming up. And nothing's really much of a surprise to us. We know what's going to be in Swift, five, and seven, what's coming sort of six, and the kind of the, the high level goals. So I think from a kind of an iOS point of view, I think there's some work to be done around swift UI and kind of filling in any of the holes that are that require companies or developers to have to go back to UI kit or app kit, I think that's an important part. I think a some kind of data framework would be really good. So currently, there's core data for iOS and Mac OS. But it's not a very nice experience to use that from Swift. So some kind of Swift, specific framework for data will be really great to see in a similar way that swift UI came along, it was the Swift, specific framework for writing UIs. I would love to see focused on tooling and improving things like X code and the compiler speeds and the compiler messages and improving source code and getting an autocomplete more stable and adding more refactoring tools. So those kind of the improving developer experience would be a really great thing to see.

Steve Westgarth:

And you mentioned, you already know kind of watch coming down downhill and vapour how much of those announcements from Apple will impact upon the beta roadmap?

Tim Condon:

Probably none, I'd say. So we know that the goals for 5.7 which is improving, checking around sendible, and stuff like that. And we know from the roadmap what the top level goals for swift six are, whether that's after 5.7, or whether there's a 5.8 and 5.95 to 10, we don't know. So kind of that's the way that things will affect it. We are in the very early stages of planning vapour five. And our aim is to release that with Swift six. So swift six comes out in September, which I doubt it folks, I think, Swift 5.7, September. But if you came out in September, that would dictate the kind of pace that we'd have to happen. If it comes out in two years time. Then we either have to make a decision and release early or wait and continue evolving vapour for. So those are the kinds of things that will affect vapour, I think, but we kind of know what the technical aspects are going to be.

Steve Westgarth:

And how important do you think it is for you to align some of those announcements with your Apple's announcements and kind of what's happening on dub dub and those things?

Tim Condon:

I think it's a good opportunity for us to kind of jump on the marketing bandwagon and the interest bank bandwagon because there'll be a lot of people kind of following the news and seeing what's going on. And it allows us to give a proper, I think, in terms of aligning with Apple's PR is, there's never a good idea because things are so secretive, right up until they're announced. So if we're trying to predict what's going to happen, you might struggle over the Trump protect debts. So I think we're now at the stage where vapour stable enough in its own thing, that we don't have to worry about trying to make sure we're aligned with Apple, we can kind of do our own stuff. And that's worked out pretty well over the last couple of years. So I'm happy to kind of keep doing that.

Steve Westgarth:

And I guess pre pandemic, you know, particularly around dub dub, you would have had vapour meetups and all sorts of things out in the US, I guess, obviously, the pandemic, we've seen dub dub kind of move online, and you're, obviously there's been less opportunity for community and kind of getting together. How have you how have you combat that within the regular community?

Tim Condon:

Yeah, it's, it's a hard question. And there's no real right answer there. I think doctor, being online is fantastic for a lot of people, because it enables them to attend and they would never be able to attend before going to dub dub is not cheap. I mean, the tickets themselves are$1,600. And that's before you've accounted flights and then staying at hotels in San Jose, where everything popped up because it stopped a week. So I don't know if there was a right answer. I think the online stuff which we're going to put up there will be online again this year. I think there's more that can be done to fostering an online community. I think I would personally love to see face to face stuff back in some form. Just in terms of meetups, I think vape has been pretty lucky in that we've always been a very widely distributed community. So from the very early days, we were always distributed across the world, we're used to running events and stuff, distributed them online. And whether that's like watching dub dub together and talking about the chats, whether that's kind of just helping each other and hang out in some of our random channels to kind of get to know each other better. So we've kind of you've been there, but I would say that nothing kind of beats face to face time. Yeah. So it's hard to replicate that. And I don't know what the right answer is, I just hope that we get the chance to kind of have that central meet up place for everyone, by Western swift and related with Dr. Dre yet again. Otherwise, the substance of conference will have to take that place, which he did do pretty well a couple of years ago, to be fair, that's the kind of the one place where everyone from sub sites before all comes together. So we have people from Amazon and Apple and MongoDB, and other huge companies who are using services worth attending. And we get to attending and talking. And you get to kind of network and talk to them. And we've had some really cool things spin out from that. So hoping more of that.

Steve Westgarth:

can absolutely and I guess you know, so now I'm also keen to explore with you before we wrap up is you're you're in a really interesting position because you're you're running a small company, but you're also engaging with some some huge enterprises. And I know you referenced earlier on your party your reasons for doing that some of the red tape and politics you can attend to get your within within large organisations but but I guess there are also problems with with running a small company because you are your Managing Director, your salesperson, you're responsible for your own income, your own destiny, and that kind of all all rests on your shoulders. Your How do you find that? Is that is that a pressurised environment to kind of be in yoga? Is that something you would recommend to others to kind of look as a model to kind of to, to use for themselves to turn into their own careers or your What are your thoughts?

Tim Condon:

Yeah, it's a good question. It's definitely a pressurised environment. I, at a high level, I'm responsible for my company, and my team working for my company. I'm responsible for vapour and essentially everyone using it. I'm also responsible for the swift team at Ray wonderlic.com. And making sure everyone in that team is happy and working and productive and has no issues. So there's a lot that I have my hands a lot of pies. And there's a lot of stress that comes with that. I think something that I'm not particularly good at and I should be better at and trying to make better effort is those such off. There are very few instances where things are immediate and need immediate attention. And they're kind of world that we live in now with smartphones and notifications and the streams of emails and direct messages and slack and discord because things need immediate attention. And so learning to kind of take a break and switch off and say, Oh, look at that on Monday. It doesn't matter. It's quite hard thing and something I'm trying to work on and focusing on stuff outside of work as well. I've done the whole working 80 hours a week for six months in a row, seven days a week. And you can do it for a little bit, and then you'll burn out. And you will be very unproductive for many, many months. So having making sure that if you do want to do it, you set the time aside for you to do stuff, whether that's other hobbies, whether that's meeting up with friends, being social, going to gigs, sitting in the garden, going on bike rides, playing guitar, doing something other than the coding that interests you, I highly recommend, I think in terms of actually doing it, it is highly rewarding. I love being in control of my work and what I do. I love being able to dictate the hours I work, it's the flexibility is phenomenal. If I want to take a few days off and go travelling, I can do that. If I want to stop work at 2pm and take my dog out for a walk, I can do that without having to have a middle management kind of bearing down on me worrying about whether I'm productive enough for that day. So there are definitely benefits and trade offs. And you just have to work out if it's right for you. But for me, it's fantastic. Like I love it. I love the being kind of at the forefront and working out what I can do and dictating that. And learning to deal with the stress and worrying if I can pay people or not.

Steve Westgarth:

And I guess that that is you're really powerful. The fact you literally are at the forefront of tech, you're particularly in the server side swift space. I mean, that must be really rewarding, right?

Tim Condon:

Yeah, it's like it's unique. There's very few places in computer science and software engineering and swift even that you can be one of the people kind of leading that charge for that particular niche. So I'm very lucky to have found my niche and found a niche that I enjoy. And I've been lucky enough to be able to capitalise on that and really kind of take it by the horns and drive it where I want it to go.

Steve Westgarth:

Brilliant. Well, Tim, thank you so much. It's been a pleasure talking to you today. I wish you great success with the next releases of vapour and I'm sure we'll get you back on to the podcast at some point in the future to talk more about vapour and server side swift Thank you very much it was great catching up with Tim and learning more about what's happening with Swift on the server. If you're interested in finding out more about vapour, I would highly recommend Tim's book server side swift with vapour which is available on Amazon. That's it for this week. If you're listening to the podcast and will be interested in coming on to the show as a guest. I would love to hear from you. Just drop me a note on LinkedIn. In the meantime, remember, you also write bad code. If you disagree. You might as well switch off my name is Steve Westgarth and this is the engineering leader

People on this episode