Productivity

Welcome to my new Meta blog! Here I will write about topics that are not directly related to Swift, but instead more about working as a software developer in general. While it won't be a weekly thing (like my main Swift blog), through this I'm hoping to be able to share more of my thoughts and experiences and that it will lead to even more interesting conversations with a larger group of people.

The first topic I'd like to tackle on this new blog is something that a lot of people ask me about - productivity and how to get more out of the time you spend on your work.

I love to work on many different things:

Reading the above list, you might get the impression that I either work all the time, am super stressed, or just crazy. Well, I'm a little bit crazy, but the biggest reason that I can work on so many things is not that I have some form of special power - it's just that I've practiced and actively worked on increasing my productivity over many years.

In this post I'd like to share what I've found to be 7 key things that increase my productivity. Hopefully some of them can apply to the way you work as well, and can help you get more out of your time.

Let's dive in! 😀

1. Take measure

As programmers, we know that in order to optimize some piece of code, the first thing we need to do is to measure its current performance. I think the exact same principle applies to optimizing productivity as well - if we don't have some form of benchmark that we want to improve, how do we know if our efforts are actually making things better?

However, this can be easier said than done. With code, things are quite simple - get the current timestamp, run your code, then measure the delta time. With things like productivity it's a bit trickier.

What I usually do is to take a loose count of how many hours or days I spend on specific tasks. I'm not going to recommend that you start tracking every single hour of your day (although some people find that useful), but I do recommend keeping some form of simple records of what you spend your work time on. It can be as simple as writing down approximately how many hours you spent on a given task, or how many tasks you were able to finish during a given day.

For example, since I've now been doing this type of record keeping for a while, I know that it takes me on average 2-3 hours to write one of my weekly blog posts, and it takes me 5 hours to launch a new open source project (setting up things like a README and Continuous Integration). I can now use this data to plan my days a lot easier 👍.

2. Know when and what you want to work on

Planning is key for me. If I have a clear plan for what I want to achieve each week, it gives me motivation to hit my goals. When making plans, I think it's super important not only to consider the what, but also the when. If you have ambitious plans, but no time to work on them, things can get really frustrating and stressful.

What I do, is that I use the data from tip #1 to inform my plans and goals. I do my best to know my own limits and how much time I can normally dedicate to working on my various projects. I also usually try to make my goals as simple and easy to achieve as possible - I never want to have any doubts as to whether or not I'll have enough time do complete all my weekly tasks.

Like many things in our lives as programmers, this is something you can spend a lot of time setting up systems for, so it's easy to fall into the classic over engineering trap. While you can totally use things like project management software, advanced productivity apps, or make really complex plans - I suggest starting out simple.

Personally, my weekly plans are simple notes on my iPhone. I just make a list of goals and for each task I put down how much time I think it'll take and what day of the week I'm planning to work on it.

3. Set limits

When working on many different projects it's easy to start getting stressed or feeling like there's too many things going on. To avoid this, I have 3 principles that I try to follow:

  1. What I make doesn't have to be perfect. It's better to make something than nothing at all, and it's better to share things early to get feedback than spending years trying to perfect something.
  2. I won't be able to do everything. Setting constraints is key. I want my projects to be focused, rather than growing too much in scope and becoming a "catch all".
  3. I do one thing at a time. Rather than trying to achieve all of my goals at once I focus on completing one at a time. Sometimes external pressure can make this hard, but I try to stick to it as much as possible - I've found that it enables me to move way faster.

To give you a concrete example - here's how I manage my "social channels". Talking with other developers and interacting with the community is probably my favorite thing about being a developer. I love hearing new ideas, getting feedback, discussing problems and answering questions. So to be able to do so as much as possible, I've set some limits for myself:

  • I mostly stick to Twitter, GitHub, my blog and a small number of Slack groups for communicating with others.
  • I sometimes enter Slack groups temporarily (for example for a conference), but I leave it as soon as the conference is over.
  • I cross-post all my posts to Medium (because a lot of people like to read them there), but I don't take any questions there. Instead, I encourage people to reach out either through my blog or on Twitter.
  • I have notifications disabled for everything except Twitter and the Hyper Slack, but I often turn on Do not Disturb on my phone to mute all notifications when I want to focus.
  • I only read emails once per day.

What limits that will be appropriate for you, your team and your projects is of course very much up to you, where you work and what you want to make. Try different things out and measure the results!

4. Use Quick Wins

One thing that is super important to me and my productivity is constantly getting a sense of accomplishment. I never want to feel like I'm wasting my time, and I don't want to get stuck on what seems like an endless task.

For this, I use Quick Wins, which is the idea that every once in a while - I just pick up a task (any task!) that will be quick and easy to implement. It can be fixing a small bug that has always annoyed you, writing a unit test for an untested part of your code, documenting an API that really needs it, or reviewing a Pull Request - anything really.

I often try to start every day with a Quick Win, which gives me energy in the morning (which I often desperately need 😅) and makes me feel good about already having done something in the early hours of the day. I also usually work on a Quick Win right after finishing a long or boring task, to give me some new energy.

I manage my potential Quick Wins the same way as my weekly goals - with a simple note on my phone. Every time I find something in my code or in one of my projects that I think could be a quick win, I write it down.

5. Manage distractions

Distractions are everywhere these days. Rather than constantly combating distractions to try to make them completely go away (which, let's face it - is pretty unrealistic), I focus on trying to manage them in a nice way.

Here are some of the ways that I manage distractions when working:

  • I listen to music that puts me in a focusable state of mind - like this awesome 80s electronic music playlist or TPR's amazing Final Fantasy piano covers.
  • I use full screen mode on my computer to focus on the task at hand when coding.
  • I work on one single task at a time. This has taken a lot of training, but I avoid checking things like GitHub notifications while coding or jumping between different tasks.
  • I silence all non-essential notifications when working (for example, turning on Do not Disturb on my phone). Important here is to not isolate yourself too much, as that might be really frustrating for your coworkers.

Again, what will work for you will be very individual. Just like how I suggested to measure time and what you get done, I also suggest trying to measure how often you get distracted. For example, increment a counter every time you go to GitHub or Twitter while in the middle of coding, you might get really shocked by the value of that counter at the end of the day 😱.

6. Relax

Productivity is not about working all the time. Quite the opposite, it's about learning how to get the most out of the time you have allocated to work, and not working and relaxing is a huge part of that.

I love coding, blogging and podcasting. I love making things and talking to other people who are also making things. I love preparing talks and going to conferences. But I also love a lot of non-work related things as well; like hanging out with my girlfriend and friends, traveling, cooking, playing music, playing video games, biking, and a lot more.

Just as it's important to have a solid plan for when and what you are going to work on, it's equally important to have a plan for when you will take time to relax. I never try to achieve more by working more hours, rather I try to achieve more by working less. You'd be surprised how much more you can get done by working fewer hours, but focusing more during those hours. Just measure it and you'll see 😉.

I take several breaks during each day to do something completely different than sitting in front of a computer. It can be taking a quick walk, playing a song on my guitar or calling a friend. My personal rule of thumb is to never work more than 3 or 4 hours straight without a break in between.

7. Experiment

My final tip is to experiment a lot with the way you work, to find what makes you the most productive. These things tend to change a lot both depending on what you work on, but also over time. Keep experimenting and keep trying new things - sometimes a subtle tweak to your workflow can make a huge impact!

Also experiment on new projects. Try new formats and working with new people. It may inspire you to become more productive, learn new techniques and master new skills. Always have an open mind, don't dismiss something before you've tried it, and be willing to constantly change.

Not all of your experiments will turn out to be successful - but in one way they actually will. Even if an experiment "fails" and it turns out that it didn't in fact make you more productive - that's something you can learn from when making other tweaks to the way you work in the future.

Conclusion

Wow, this turned out to be quite a long post 😅. I hope you liked it, and that it has given you some insights into how I work and how I'm able to keep working on so many different projects.

Like in programming, there are no silver bullets when it comes to productivity. Everyone is different and everyone prefers to work in different ways, so rather than trying to apply all of my 7 tips at once, I recommend cherry-picking what you find to be the most applicable to your preferred way of working, and taking it from there.

What do you think? Do you have any other tips for increased productivity? Feel free to share them, either in the comments section below or on Twitter @johnsundell. Also let me know what you think of this new Meta blog and if you have any specific topics you'd like me to write about in the future.

Thanks for reading! 🚀