Nicholas Tietz-Sokolsky
Runner. Coffee nerd. Software engineer.

We are barraged by constant distractions, and they are degrading the quality of our work. Our digital society now is set up to allow us to focus for mere minutes at a time, since we are in an attention economy and the sole objective of companies is to capture more of our time. Facebook, Google, and Snapchat are all incentivized to get us to look at our phones many times a day.

People talk about disrupting industries when those industries appear to be in a stable but inefficient state. For example, the taxicab industry: there was little innovation going on in it, and it was stable, but it seemed like it was far from ideal. Along came Uber, intent to disrupt the industry - and disrupt it they did.

Estimating software projects is hard, if not impossible. This seems likely to be fundamental to the work, because we’re inventing new things and invention doesn’t happen on a fixed schedule. And yet, many teams still estimate how long their tasks will take to finish. Why should you do this, if you can’t do it accurately? You do it because it can help you reach your real goal of solving a problem as quickly as possible. But when you do it, you need to have really solid processes around estimating, or the estimates will be used and abused and can kill your team.

When you’re building or scaling a software engineering team, you naturally run into a choice at some point: will we all be in the same office, or will we do this “remote work” thing? There are a lot of factors that go into whether or not remote work will work for your team, like if you know how to work remote. Another consideration, to make it more complicated, is which form of remote work you want to consider.

I’ve been working remote since September 2016. There are a lot of engineers who have worked remote longer than I have; there are others who have more insight into how they work than I do; and there are plenty of people who simply don’t work in the same way I do. My intention in this post is to share how I work, the reasons why I work that way, and what I think others should try while finding the process that works best for them and their teams.