This post wasn’t written for you. It was written for me, future me that is. Yes, the me that one year ago had a 50-day github streak. The same me who said “ok, its the weekend I’ll take it easy with only a 7-hour work day…”.

You know where this story goes, I burnt out one. Then did it again. But it wasn’t always like that. There was a time when I worked on a project, delivered everything in record time all while spending time at the bar watching the world cup 3-times a day! Yes, you heard me, and no I did get beer and watch all games (I was not working while at the bar!).

How on earth did I do that? Could it be real? Maybe it was all a dream? Why am I working 60 hours a week and the client is still not happy? The more I work the less happy everyone gets. Then it dawned upon me. Tim Ferris wrote about it in his book the 4-hour-work week. It was time to give it a try.

I started by building a schedule, 9–5 was invented for a reason. For me it was 7–4 with 1-hour lunch break and I started working from home. My productivity went through the roof. By noon I would usually finish all the important tasks. Meetings were pushed to Fridays and it became my social day and segue into the weekend. This made scheduling easy.

I rarely worked passed 4pm and when I was done, I wouldn’t touch my laptop until the next morning. I started treating my recovery time as sacred. I made that clear to everyone that business could wait until the next day. After all I need to put in 100% the next morning.

What followed was an ability to step away from daily problems and see all the inefficiencies we developers ignore in our work. I would see wasteful behaviour like getting developers who are paid $150/hr to change copy and then revise it as the client change their mind. Empowering the client to change copy directly is easy to do and would save everyone time and money.

I saw how time starvation spreads like an infectious disease among individuals who are not disciplined enough to stop. Time starvation is the idea that there is not enough time in the day. In fact there is plenty if you use it right. Contrary to what your boss likes you to believe working overtime requires no more skill than being able to binge drink. It is an act of stupidity and immaturity.

I saw how the “lazy” city of Vancouver stacks up against the “work hard, play hard” city of New York and the Canadian copycat, Toronto. I used to think those work hard, ambitious people were heros. I was wrong. Now I think they are idiots. They are just silly teenagers competing who can work themselves into an early grave faster.

Below are a few tips that helped me. Maybe they will help you too.

1. Stop reading hacker news — there is nothing to find there. Most news is completely irrelevant to what you are working on. Even if someone mentions a magical new library to solve all your problems, you probably won’t be able to use it for a while and even then it will initially fall short of your expectations. If you do need it, you will find it once you encounter a problem that requires it, a simple google search will turn it up. Staying up-to-date is overrated, trust that you will find out about important stuff from friends or when you need that specific solution.
2. Stop physically going to meetings — there is little need for you to be somewhere in person. Even if it only takes 10 mins to get there, you still lost 20 minutes of your time. Simply jump on a Google Hangout or skype call.
3. Schedule interruptions/chores on the same day — try to schedule all meetings, chores and other important but non-urgent tasks to be done one day a week. For me it was Friday. Meetings, bank appointments, dentist, talking to a lawyer and so on were all things I didn’t need to worry about Mon-Thu. Therefore, Mon-Thu I produced results, Friday I cleaned up the mess that was left behind & socialized.
4. Timebox — make sure to put an upper limit on most tasks, don’t spend 2 hours on an email if you decided it should be finished in 30 minutes or less. This will force you to leave out less important things, which is good because no one wants to read those anyway. Same thing goes for development tasks, if you thought a login screen would take you at most a day and it has been 6 hours, start wrapping it up. Don’t just excuse yourself to take 2 days on it, it’s a slippery slope. You will sometimes go over, but you need to make it an exception not the norm. Remember, practice makes perfect. Keep trying to timebox correctly and learn the discipline of “good enough” and “time to stop”.
5. Work less — if you can’t get your job done in 80 hours a week, cut it by half to 40 hours. It will get done. You will be less tired and have a lot more perspective on things. You won’t excuse yourself with time wasting excuses like “it’s ok I’ll watch this YouTube video now, I’m working late anyway”. Or “sure I can chat 30-mins with my co-worker about her cats, we are both gonna be here late anyway”. Get in and get out at your scheduled time. You will start to see what doesn’t get done, what doesn’t need to get done and how things can be done faster.
6. Leave time for professional development — 20% of your time should be spent on improving future results and increasing efficiency. Invest in yourself and learn new skills that will make you work faster and even less hours. You will start to work less and produce more, an incredible paradox. At work I would first focus on getting the task done with minimal time spent learning, then invest a little more time after to see if I can do it better or faster the next day.
7. Do less — stop setting insane expectations for yourself. Remember, you are pretty amazing, otherwise you wouldn’t be reading this blog :). Be patient and leave work for the next day. All you need to do is make steady progress towards a solution everyday. Sure you could add that crazy animation with the butterfly curve (there is one!), but is that really worth an extra 3 hours overtime and then stressing out about the deadline.
8. Be less generic — we often assume our code would be extended and used for a different purpose. This isn’t usually the case. If you can support less cases, less customization, less parameters then you should. Get it working for a very specific use case. If others complain it is too specific, good now is the time to make it more generic. This is called refactoring (revolutionary I know…). Customization is a death trap ☠️ for time. If all you need is a cube, don’t build a Rubik’s cube. Keep it simple. See #7.
9. Manage expectations — you are the only one setting the pace. Remember, all your boss or project manager wants to see is steady progress towards the goal. If you feel you need to be faster, learn from those who seem to leave before everyone else and arrive late and still get all their work done. They know how to manage their time well. Don’t compare yourself to the workaholic co-worker who arrives early and stays late. Even if they appear to be accomplishing more than you, they will eventually burn out. Working long hours is not sustainable. See #7 and do the important stuff first and nothing else.
10. Nothing is urgent — things can often wait. If you are in the middle of something and someone interrupts with an urgent request, ask if you can review it later. Push it to End of Day or Friday, see #3 & #9. On Friday, review the task and if it takes too long, message that person, clarify the minimum change required and schedule a time to implement that you both agree on (next Friday? Or maybe never. Maybe it’s not wroth doing anymore). Doing this sets very clear expectations of when things are to be done. It will also help avoid getting unreasonable requests. 

If it is truly urgent (e.g. website is down), do a through introspection after fixing the issue. It should not have happen in the first place and you need to take action to stop it from happening again.

11. ABC — Always Be Closing issues. Close your github issues quickly and link to new issues with any cases not covered by the solution. Most of the time you can get to 80% on an issue quickly, the other 20% will take significantly more time and can be deferred to a future date. In fact, you will find no body cares about the last 20% most of the time. There are other things you can do that are more important.
12. Know your strengths — don’t let your ego and stubbornness get in the way, if you don’t know something, say it. If it pains you to learn it, ask for help. There is no shame in getting another team member to take care of it when it is clear they will do a better job. You can then move on to things you are good at. Stop fixing your weaknesses all the time. Focus on your strengths. For me, it’s DevOps. I simply suck at it and have no patience or desire to learn it. If I touch it, everyone loses, it takes me a long time, makes me unhappy and the client is unhappy with the lack of progress. To avoid it, I simply suggest leveraging heroku for deployments, another team member or hiring outside help.
13. If you can buy it, don’t build it — if someone else has done what you need and you can get it for free or pay a fixed price, always take that deal. The cost of developing the solution was higher than what they charge as they can spread the cost across many clients. Your cost will be yours and yours alone. It will also take you time, which you can spend on more important things.
14. Learning is not free — learning takes time, and time is money. Learning one thing means you don’t have time to learn another. Learning is fun, but be strategic about it. Pick what you spend your time on carefully based on what you think will benefit you and stop reading when you have enough information and get the job done. I once read the whole developer guide for Quake 3 and never ended up developing anything for the game. Useless. Remember, learn just in time (LJIT — be legit…). New information that is not actionable now or in the near future is wasted brain power.
15. Be confident in yourself — stop comparing yourself to others. You only need to compare to past you. People hire you to do work for a reason. Remember that and always speak from that position. Don’t be afraid to learn from others when it helps you improve. Remember that even LeBron James occasionally doubts himself. It helps no one if you act less confident. Sometimes clients have unrealistic expectations you cannot meet, it doesn’t make you a bad programmer. Perhaps you just need to see #9 again.
16. Don’t automated when you don’t need to — if something only needs to get done a handful of times but seems tedious, just do it. Don’t try to automated it if it will take more time than doing the task by hand. If you need to find 10 emails to send a message, don’t write a crawler just to do that. Simply go and manually extract those emails, put them in your mail client and hit send. It will take less time and you will be able to move on to other more important tasks.

Again, take the above with a grain of salt. It works for me, it might not for you.

Share the tips that help you save time in the comments below. If you enjoyed this post, hit the like button.