What Drives Efficiency

The last couple of months I’ve analysed my working to try to see which techniques I find useful on a day to day basis and which not. I’ve compiled a small list of things which I think are highly useful to get more done in your day to day business. It’s of course a list that is under constant development as I test and evaluate new ways of approaching problems. As of today this is how the list looks though:

1. Write a plan
2. Evaluate yesterday
3. Take breaks
4. Develop test driven
5. Identify and address unknowns first
6. Identify a short feedback loop
7. Explain your solution
8. Treat meetings as important

Write a Plan

After reading my emails and looking at the chat history I write a plan. I try to consciously take some extra time doing this, maybe five to ten minutes. I write down all the points that needs to be done during the day. I then identify which of these points are easy wins and which of them have a big impact. I then identify what I want to do when. Once I’m content with my plan I go to action.

Why do this? Because if your work is remotely similar to mine you’ll experience many disruptions during your day. Changing focus from one thing to another usually means that you have to take some time to get back to what your initial problem was. If you have a clear plan there is not energy needed to think of what you were doing. If you have a plan you also know how much extra time you have you can spend on other things and still not miss any of the crucial things you have to do like preparing meetings etc.

Evaluate Yesterday

As a first step in my plan I almost have to analyze yesterday. I try to look at what I did and try to think of what lessons I can take from the day. Was there something I could have done smarter? Why didn’t I? Was there something I did well? Why?

Why do this? There is a difference between mastering something and being accustomed to something. This difference comes in part from self analysis. You can work for 20 years with the same thing without mastering it. If you never look at what you’re doing well and what you could do better you’ll never learn to adjust how you can become better at what you’re doing.

Take breaks

Especially now that most people work from home it is easy to forget taking breaks. I put a timer on 45 minutes working, then 5 minutes break. Pomatez is a great app for doing this but I’m sure there are many other alternatives.

Why do this? I could sit for 3 hours straight, I would probably not even notice that I haven’t taken a break. But the brain gets slow after a while and the thoughts become less clear. By moving around a bit you improve your blood flow and can approach your problems with a fresh head again.

Develop Test Driven

Whenever I can I always write a test that is red first, then I make it green by implementing the logic. There is real happiness in seeing how every little if in your code has a test for it’s conditions.

Why do this? Most code is simple and you might wonder why you’d need any test. First, if you create tests you’ll naturally be pushed into splitting your code up into smaller modules. This will make your code easier to refactor in the future. Don’t believe me? Look at code written test driven and code that is not. You’ll likely find that creating tests for the second kind of code will be very tough because the logic is all in one place and just setting up the tests will be nightmare. Second reason is that this creates a short feedback loop. If you do any mistake, like forget a not statement or something like this, you’ll see it instantly with your test. The alternative is that you deploy to test, wait for 15 minutes and then through your manual testing discover there’s a problem. If such a mistake happens even once you’ll likely loose as much time fixing that mistake as it takes you to create these tests in the first place.

Identify and Address Unknowns First

If I’m calling an external API I make sure to see that I understand exactly how it works before I start the rest of my development. If there are open question I make sure to ask them as early as possible.

Why do this? Because sometimes your assumptions are incorrect and in the worst case these faulty assumptions change everything. You’d rather find out earlier than later.

Identify a Short Feedback Loop

When working with something that is new to me I try to find a way that I can verify that I’m on the right track quickly. Often this loop could be unit tests or integration tests. Sometimes they are not. I think for a while to see if there’s a smart way to verify that things are going the way I want them to.

Why? It’s like with the point above, you want to find out that your assumptions are correct and what you’re doing is taking you in the direction you want.

Explain Your Solution

I try to make sure that when I work with a more complex problem I get the chance to explain how I think about the problem and how I want to solve it to someone.

Why? Because every problem can be solved in a lot more ways than you’d think possible. And you can quickly get blinded to simpler approaches than your own if you don’t get a second opinion.

Treat Meetings as Something Important

I try to make sure that there’s always an agenda available and that I’m always read up on the topic that will be discussed. After the meeting there should be resulting action points and the conclusions of the meeting should be communicated to interested parties.

Why? In my opinion if you don’t do these things you might as well not have the meeting. A meeting without an outcome will be forgotten and hence more or less worthless after a week.