As employees we are used to being judged by how hard we work and how well written our code is. This is a way in which a corporation is able to manage developers and measure their effectiveness. But in the real world, no client will ever care what the development process looks like. They only want to save time or gain some competitive advantage by using your software. Set your goal to consistently ship code and put everything else aside.

Users don’t care about the effort you make, the hours you spend programming or even the language you program in. The only thing that interests your users is the value they get from using your software. This fact is perhaps the biggest misunderstanding of programmers who try to build software products on their own.

It’s true that well planned, organized, documented and tested code means less bugs, faster development and better collaboration with other programmers, but that’s something that you will worry about when you’ll have a profitable product to support. When you are building a new product, especially the first versions, this shouldn’t be your main focus. What you have is an initial attempt to make a product that may be useful to someone or may not be useful at all. Do the best you can with producing high quality code but your main and only goal is to release something that works. You can allocate time to everything else in the future if what you’re building succeeds. Worrying about the maintenance of a product that doesn’t yet have any clients is useless.

Therefore you should focus on producing code as fast as possible while minimizing product development time. Below are some tips that work for me.

  1. Focus only on the next version you are going to release and the next functionality that has to be developed for this release. I always try to remember the one single thing that I need to complete before I ship code the next time. Other tasks like research, code improvements or “nice to have” features can be done as well when there’s time, but the focus should always be on whatever is required to release working code to production. It’s very easy to get distracted and end up working for months on all the wrong things without releasing anything.

  2. Choose the tasks that need to be done, not the tasks that you would like to be working on. Most of the important tasks that you need for a working product are not fun and not glamorous. You still have to do them even though you would prefer to work on some other feature that is only “nice to have” and not required, but would be fun to work on. If you need to figure out why your deployment fails even though everything should be working but you would actually prefer to integrate some fancy javascript framework that is trending on github, put the framework aside and start debugging your deployment. Choose Shipping Over Using The Latest Shiny Framework

  3. Have a super simple stripped down ticket management system - I only have three columns on my Trello board. Todo, doing and done. I make sure that my todo column has tasks that I actually plan to do in the near future. If I have a big feature that I’m working on, I try to separate it into smaller tasks. I also have only one item in my “doing” column at all times. I’ve realized that I can’t multitask and I can only focus on one item. This way when I get back to work in the evening or on the weekend, it is always very clear to me what my next task should be. I’ve noticed that if I have a lot of things to do and I’m having hard time deciding what to work on next, I often procrastinate and end up wasting time.

  4. Build the simplest and most basic version first and ship it. Choose all the functionality that would be the easiest and fastest to build and complete it as fast as you can. Usually, 80% of the functionality can be completed in 20% of the development time. Make sure you focus on these low hanging fruits instead of spending a lot of time on some complicated feature that will not be popular and is less likely to be used. Once you see that you have a basic working version, it will encourage you and give you momentum to work on more features. On the other hand, if you will find yourself working months on some never ending project and you still have nothing to show for it, you will get very frustrated and will most likely quit altogether.

  5. Separate planning from executing. Start by looking at the new feature you want to build and make a list of all the tasks you need to complete. Only when you thought it all through and came up with a work plan, start actually writing code and try to check off items from your list as fast as possible. I find it much easier to write code fast when I know that all the decisions were already made and I can safely focus on execution. It takes away the worry about catching yourself doing something wrong and having to redo what you did which makes the development faster.

Focus is the hardest and the most important thing for releasing software and you should be aware of the effort you need to put into being focused, consistent with what you’re working on and the priorities you set for yourself.