15 An Interview with John Sundell

John builds apps, games and developer tools. He also makes Swift by Sundell—a series of weekly articles and a podcast about Swift development, and co-hosts the Stacktrace podcast.

John Sundell

Connect with John

Twitter: @johnsundell and @swiftbysundell Website: swiftbysundell.com

Interview

You have switched from a large company, Spotify, to work as a freelancer. What are some of the non-obvious ways that working as a freelancer differs from working at a company?

Freelancing offers a lot more freedom, but with this freedom comes a lot more responsibility. You not only manage your own time, but you also manage your clients and the quality of the work that you do.

When you work in a company, there is usually a supporting structure around you. For example, there might be a manager who helps the team manage its time and tasks, or there might be testers to test the team’s newly built features. But when you work as a freelancer, many times you are responsible for those things. That means that you have to schedule when to work on your tasks in order to fulfill your agreement as to what you’ll build and when it should be delivered. You also have to deliver high-quality work, because that’s what clients will expect. Overall, being a freelancer is like running your own small business, and you need to make sure to deliver on your promises and to keep your customers happy.

What kind of qualities do you think it takes — professionally or personally — to work successfully as a freelancer?

I think it mostly comes down to being very organized. You need to manage your own time and to make sure that you spend your time on the right things—but you also need to maintain great relationships with the people and clients with whom you work. Managing expectations is a big part of that. People need to know when and what you are going to deliver, and they need to be able to trust that you’ll stick to your deadlines. The classic phrase “under-promise and over-deliver” is key here.

Being a successful freelancer has as much to do with business practices as it has to do with the code that you write. When I was a freelancer, I would often spend hours dealing with contracts, emailing clients, and attending meetings. However, while some people can be frustrated by having many meetings and doing administrative work, I don’t mind it at all. Whenever I’m sending invoices, doing administrative tasks, and responding to emails, it feels like I’m moving my business forward, and there’s something incredibly satisfying about that.

How did you know it was time to become a full-time freelancer, and how did it feel to make that transition? What was your catalyst?

I became a freelancer to have the ability to work remotely. While a lot of companies offer remote work, I felt like taking on my own clients and working on multiple different projects would be an excellent fit for me, since it wouldn’t tie me to any specific location or any strict working hours. I thought working on my own would enable me to travel a lot more, to work on things like open source and community initiatives, and give me the power to organize my time. That was all very appealing to me, so I decided to give it a try.

As a freelancer, one of the key aspects is to secure a steady flow of clients and projects. How did you achieve this? What would you recommend to a developer thinking of going freelancing?

Keeping a steady flow of clients can be incredibly difficult, and “client-hunting” is something that can take up a lot of your time if you’re not careful. Before I made the transition to become a freelancer, I made sure that I had one long-term project lined up already. That project gave me 30 hours of work per week, which was great since it gave me the flexibility to do other things on the side—while still giving me a steady flow of income from day one.

Having that initial client was key for me, and it heavily reduced the stress-factor of going freelance. So my greatest advice for anyone who’s looking to become a freelancer is to do something like that—to find a first project before making that jump. If you’re lucky, you might even be able to convince your current employer to convert your employee contract into some form of freelancing arrangement.

You are also working remotely and advocating strongly for remote work. Remote work seems to be a trend that has come to stay: Not only do developers have more freedom and flexibility, but companies also benefit from a wider hiring pool. Any tips for companies thinking of going remote or trying to implement it?

To make remote work successful in a company, one of the most important things is to treat the whole company as if it were remote. Even if you’re just hiring one or two people who are going to work remotely, pretend like everyone on the team is working remotely, too. If people are coming to the office every day, whenever there is a meeting, ask everyone to call into that meeting separately from their computers. Try not to put the whole team—except for one remote person—in a single room and ask that one person to dial in. That person will feel like an outsider who doesn’t have the same level of influence as the people who are in the office every day.

Use small little tweaks like that: everyone dialing into meetings, all the conversations about code happening on GitHub or Slack (or whichever other tools that you use) instead of discussing those things ad hoc at someone’s desk. All of that can make remote working not only possible, but also enjoyable. However, making such changes can be a bit awkward at first. Someone might wonder, “Why can’t I just go talk to my coworker who is right there? Why do I need to get on a Hangout?” I think after you overcome that awkwardness—which is usually just something you have to get used to—these remote-friendly routines really help.

As you say, making a company remote-friendly opens up a wider pool from which you can recruit, and it gives everyone on the team a lot more flexibility, even if they go into the office every single day. If you set up the proper working environment, then everyone, even people in the office, can work remotely whenever they want. Guess what? If you’re going on vacation, you could extend that vacation by a couple of weeks and work from there. It gives everyone a lot of freedom. Establishing remote-friendly routines can not only make a big difference for the individuals who are already working remotely, but it could also accelerate an office-based company’s transition to a fully remote company very quickly.

“I use a system to organize tasks that I call ‘Quick Wins.’ I try to split all of my tasks up into pieces that are as small as possible.”

In your independent work, how do you start your day and stay productive?

I use a system to organize tasks that I call “Quick Wins.” I try to split all of my tasks up into pieces that are as small as possible—whether I’m building a new feature, sending an email, or scheduling something. These small tasks then go into my “Quick Wins” list and every morning I try to do at least one Quick Win just to get started with the day. That gives me a sense of success at the beginning of the day, which then makes it so much easier to move on to bigger and more complicated tasks.

I start almost all of my productivity work—like organizing my time, ideas, and schedule—by using Apple Notes. I use Notes for everything: for all of my different TODO lists, for ideas, for article drafts, and for preparing my next podcast episode. The reason I still stick with this app even though there are so many more purpose-built ones—like Apple’s own Reminders app and other ones more geared towards TODO lists—is that I love the freedom of being able to make a note and then add TODO lists inline. I also like being able to take my iPad and my Apple pencil and draw and place images within a note or list. I basically “dump” a lot of thoughts into this application every single day, and then organize them afterwards.

I do most of my development in Xcode. Xcode has a feature called playgrounds, which lets you write Swift code in a way that continuously executes it to show you the the latest results, and I use this feature all the time. I do a lot of prototyping, I write a lot of sample code, and even when I’m doing something like building a new piece of UI, I like to do that using playgrounds. It gives me a very quick feedback loop, and I like the lightweight nature of this way of coding.

How do you manage your time and distribute it among your personal projects?

When I left Spotify at the end of 2016, I made a deal with myself: from now on, I’m going to dedicate 20% of my time to working for the Swift community—whether that’s by writing articles, contributing to open source projects, or something else.

That might not sound like a lot of hours per week, but over time, it adds up. Like always, if you try to make the most use of your time, then even a small amount of hours can have a big impact eventually. Whenever I start a new project—whether that’s for my business, for the community, or just for fun—I always make sure to set aside dedicated time for it. That way, I prevent myself from overworking, while also being able to juggle multiple projects at once.

So I did that 80/20 split between working as a freelancer and working on my website, articles, podcast and open source projects for about two years—and now, since the first of January 2019, I’ve been able to make Swift by Sundell and my work for the Swift community my full-time job, which honestly still feels a bit unreal and incredibly exciting.

For me, it has really taught me that even if something starts out as an experiment, or as a hobby project, if you dedicate enough time to it, and if you keep working on it through all the ups and downs—amazing things can happen, even things you didn’t plan for or dream about.

What would you recommend to people who are new to engaging this community? Where should they start? Any tips?

My biggest recommendation would be to start small. Sometimes, when we think about these things—starting a blog, starting a podcast, making a YouTube video, or whatever it might be—we might think that the thing we’re making must be big and revolutionary, something that’ll have a big impact on the community. However, most projects don’t have that kind of impact when they’re started—and it’s not really necessary. The important thing is just to get started, however small the first step might be.

For example, my first article was only 500 words. In my first podcast episode, I was the only one talking for half an hour. That was it: no guests, nothing, just me. And my first conference talk was just a 20-minute lightning talk.

The key is to remove that constraint that you need to make something big. An article can be short, a podcast episode can be simple, a YouTube video can just be you talking over a deck of slides, a talk can simply be about sharing something you’ve learned recently. The main thing is to focus on sharing something that you are passionate about.

I don’t recommend starting to share things just because someone told you that you need to write an article in order to become a Senior Developer. I don’t think that’s true, and I don’t think everyone needs to become a blogger or a podcaster. But if you do have something that you want to share, like a cool feature that you built, or some hard technical problem that you solved, try to do that in the simplest possible way. Don’t try to build a huge audience or to become the next big blog, because that kind of thing takes so much time and effort.

Building up a big website with lots of content takes years, so I don’t think anyone should have that as a goal or expectation when they’re going into it. It should be more about building what are you passionate about, sharing what you’d like to share, and doing so in the simplest way possible.

As an independent contractor, what do you do to keep yourself updated with the latest development trends?

I’m a bit old-fashioned when it comes to things like that. I read a lot of documentation, but I feel that documentation is something that a lot of developers, especially people who are learning development now, are dismissing. They tend to go directly to a blog, to YouTube or Stack Overflow. That said—there’s nothing wrong with that. I mean, I’m writing a blog, so I do like that people read blogs!

However, the documentation from platform vendors, such as Apple and Google, is usually of really high quality, especially when it comes to the high-level concepts of a tool or framework.

There is usually great documentation on everything from the UI layer and the various UI libraries that each platform offers, to things like audio and graphics frameworks, and I try to read almost all of it. If a new framework comes out during WWDC, I will take a look at the documentation, I will read through it, and then I will try it out by building a few experimental things. For example, I will open up a playground, import the framework, and try to write some code that uses it just to familiarize myself with the API, and to figure out how it works.

When it comes to understanding trends in particular, I mostly focus on talking to other developers, to hear what they are interested in right now, and what challenges they are solving on a day-to-day basis. For that, I use social media like Twitter, attend conferences, try to go to as many meetups here in my local city as I possibly can and, in general, try to stay in touch with the community as much as I can. These connections give me a lot of input in terms of what people are interested in and where the industry as a whole is going.

What is a current industry trend that you think is wrong?

I think big companies monetizing user data is one of the biggest threats that we’re facing in the technology industry right now. Big companies that are harvesting user data without users knowing about it, and then using it to manipulate people or content for profit—or for creepy advertising that’s following users around, tracking every move. I personally think that those kind of practices are morally wrong, and we, as an industry, are obligated to move in a direction that is more transparent, that is more responsible, and that is more user-friendly.

It also seems like the general public is becoming more aware of where their data is, how companies are using it, and how the data is being exploited. Those are definitely steps in the right direction. As individual developers, we have a lot of power and responsibility here, because all of those creepy analytics tools that are analyzing user behavior and tracking people in invasive ways, those are all algorithms implemented by developers—like you and me.

If you, as a developer, get assigned a task that you morally object to—then consider pushing back on it. Initially doing so might not be very productive because management might just find someone else to do it, but if you keep arguing your case about why user privacy matters—then that can have a big impact in the long run.

In terms of other sources, what podcasts or books have had a lasting impact on you or how you work?

Right now, I work a lot with website, article and podcast production. I run my own site, and so I am very inspired by other people who do the same thing. For instance, I like to listen to people like John Gruber, Myke Hurley and Stephen Hackett, and Chris Eidhof—people who have done much of the same thing that I’m doing—building a business around websites and podcasts.

I particularly like John Gruber’s podcast The Talk Show. It’s not only a great show, but I also enjoy it from a sort of meta angle—how he deals with sponsors, how he organizes the show and his website, etc. That’s all very inspiring for me.

What is something you wish someone had told you when you started software development that you learned the hard way?

Not to have too many strong opinions. Keep an open mind. It’s very common for people who are at the beginning of their career to have strong opinions about the techniques or methods that they like—and that they feel compelled to defend those opinions. I’ve completely moved away from that and wish I had learned to do so earlier. Very specific techniques or patterns rarely matter in the long run, and there are so many different ways to solve a given problem, and all of them have pros and cons.

You have to learn to pick your battles. Ask yourself: is this specific pattern, or tool, or code style, really that important? If you think about it, the answer is probably no. You probably want to spend your time having more productive discussions. Also, once you stop having those really strong opinions, you open up your mind to learning more about alternative solutions. Something that at first might not seem like a good solution may turn out really great, and might even become something that you’ll learn a lot from.

What is an effective strategy to overcome this issue?

I think the best way to combat that kind of mindset is to try different things. If you’re feeling that you could become a bit more open-minded, just challenge yourself to try something new. Even if it might not seem like something you’ll like in the beginning, try it. I’d love for the industry in general to encourage that kind of thinking—especially when it comes to scenarios like deciding how to implement a given feature, or choosing which architectural approach that a team should take. Welcome as many different opinions as possible, build prototypes to try different things out, and encourage people to be open minded—don’t just stick to one solution.

John’s Recommendations

• The Talk Show podcast | John Gruber
• Accidental Tech podcast | Marco Arment, Casey Liss and John Siracusa
• Connected podcast | Federico Viticci, Myke Hurley and Stephen Hackett