Last month I left my job as a Software Developer at Taxi for Email. I held the position for nearly 2 years and sincerely hope that I managed to give the company close to what it gave me. In this post, I will try to sum up some of the things I learnt during my time there. Working at Taxi was my first software job so some of this might be a bit obvious or naive - well, I’ll write it out anyway if only to straighten out these points in my own head and draw a mental line under the lessons learnt.

Disclaimer: these are some conclusions that I drew from my experience, not stone-set truth. I hope this discussion sparks a conversation in someone else’s head and leads them to compare mental notes.

Finally, for the sanity of everyone involved I’m breaking this post into two parts.

Let’s go!

Shipping and Scrum

Shipping is hard. Even when working on small personal projects I often struggle to ship. I might accidentally spend too much time choosing a framework or being too perfectionistic about little details that barely matter. Worse, I might scrap the whole thing and start again because I suddenly decide the idea is not good enough. Special circumstances aside, all these reasons are BAD for not shipping. At the workplace, where there are typically several parties involved in making a product, each with their processes and ideas, these reasons are joined by many more. Yet, at Taxi shipping was rarely a problem. Why is that? Could it be because of Scrum, the popular software development framework used at the company?

Before trying to answer that question let’s see where delays in shipping come from most often. From my experience a lot of them are for one of the four reasons:

  • Bad communication between team members, e.g. not knowing what other team members are doing, misinterpreting the spec or the problem. This is often the root of other problems on this list.

  • Poor estimation. Estimating software development is really hard. Someone being too optimistic / not thinking through all required tasks to complete the job / not allowing time for error is all it takes for the project to derail.

  • Poor prioritisation. Often caused by the first point, poor prioritisation is another common reason for delaying shipping. It’s especially a problem for personal projects where business goals don’t push you as much, and it’s easier to focus at the wrong things.

  • Not having a clear idea of what a ‘done’ product should look like. Here is another common scenario. When getting closer to the finishing line, suddenly there is a lot of disagreement over details. The product gets delayed, changes are made sporadically at the last moment and the result is poor. Even for a personal project, where only one person is involved, that detail that was left out during planning can turn out to be a crucial technical difficulty, and the whole project will need to be reworked as a result.

Now let’s come back to Scrum. The benefit of the framework is that it addresses all of the points above, and it does it explicitly. Daily stand-ups make sure everyone is on the same page and knows what others are doing. Estimation and prioritisation are also important in Scrum; There are various rituals that help you improve those, such as retrospective, sprint planning, Fibonacci sequences and optional sacrifice of a small furry animal to scrum gods others. Finally, there is a “definition of done” that outlines what a finished product should look like. I can’t say that Taxi’s ability to ship is wholly due to Scrum, but it probably helped.

I started writing this section and realised I have quite a lot of things to say about Scrum, both positive and negative. This will probably become its own post, but for now, I’ll say this. Shipping is hard. Scrum helps you ship. It’s not a silver bullet and might even make things worse for some types of projects. One point that Scrum addressed particularly well is time. There is a lot of value in shipping fast, or even simply on time. Scrum makes it the main focus. It relentlessly reminds you that the main goal is to ship. Not to dick about with what the most perfect framework is, because we all are going to die soon.

Make friends and be positive…

…at the risk of this sounding like a LinkedIn post. I’m yet to find a case where a workplace would benefit from conflict. Working with the same people day in and day out can be tough - it’s even tougher if you hate them. The stakes of genuinely getting off on the wrong foot with a colleague are just too high; you’d have to see them every day at work, why make it miserable for yourself? On the contrary, making an effort to cultivate good relationships will go a long way and make it more enjoyable to come to work. This is something I had to learn - in my life outside work I simply don’t talk to people I don’t like or just don’t click with. At work, this is sometimes not good enough, as you have to spend time with some colleagues. Basically, at work, I’m willing to put more effort to try and like someone.

There are days, admittedly, when I think to myself, “doesn’t matter, I’ll just suck it up at work and power through, I have my friends and family outside”. I quickly call myself out on this thought and remind myself just how big a portion of my life I spend at work. It makes much more sense to try and make the best of your time there.

All this sounds like working at Taxi was a constant struggle - it wasn’t! But, as I mentioned before, working with the same people for a long time can be hard, and anyone can have bad days. I learnt to think twice before taking out my bad mood on my colleagues or blaming them for it.

Read the second part here