To be productive, you have to be constant. To be constant, you have to be organized. To be organized, you have to be happy about what are you doing. This are three simple rules that I try to apply to my work. The first two are quite straightforward and they don’t really need explanations. The third one, however, is more delicate. What do we mean with “to be happy about what we are doing”? Why this is connected with “to be organized”? Well, the answer is positive feedback. When I’m happy with what I’m doing I’m able to stick to the workflow I’m using. At the same time, a good workflow means less time spent debugging, less trivial bugs committed, less troubles during deployment, in other words: an happier developer!

This positive feedback loop can really increase your productivity. The real problem is, how can we find this magic smooth workflow? I don’t know. I cannot tell you the magic solution to every developer problems. You have to find this by yourselves. The only thing I can do now is telling you my actual workflow. This may be a good starting point for some of you. :)

Treat your project as if it were the coolest project in the world

Even if you are writing a terrible toy side project or a random collection of line of code, you have to consider your project as if it is the most exciting software in the world. This provides two main benefits: first, no one is excited to work on something useless, so a bit of sugar can really improve your unconscious effort and focus; second, it increase the chance that someone get interested in the project. We have to be honest: a project with a fun and pleasant presentation page catches much more interest than… nothing.

It does not require much effort either! On GitHub you have just to write a nice README file, add some images, put some code examples and you already have a nice presentation for your work.

Use Continuous Integration software as much as possible

Continuous Integration is the practice of automatically compile and integrate code branches after every commit or every day. Why me, a lonely programmer, I need this? Well, first it is a matter of attitude. As I said before you should think as if you have thousand of users and contributors. however the most important reason is that this ensure that your code work: it works after each commit and it works on a sandbox environment that is different from your development machine and, more important, it is replicable. Continuous integration helps you into providing a good and replicable build system. If your code compile on the CI platform than any user should be able to compile and run your code (it has just to copy the CI initialization and build script). In short: using CI allow you to catch a large class of bugs and errors in the code just after the commit action.

For GitHub project Travis-CI is one of the most famous and used continuous integration tools I’ve seen. It is easy to setup, works well with testing and coverage and adds also a nice badge on your README. :)

Test Everything, Test Often

Test-Driven Development and extensive unit testing in general have pros and cons, however I think that there are way more advantages than drawbacks. This is even more important if you are using a dynamic language such as Python or JavaScript, in which there is no compilation step that can help you catching errors.

Many developers have one problem with unit testing: writing them. Usually, when there is pressure and deadlines, unit testing is the first thing that will be cut off. However this is wrong. Writing an unit test for a class does not take more than 20 minutes, at worst! On the other hand, catching a subtle bug in your code can take a full day. So, at the end, you are not wasting 20 minutes, you are investing them. For me, to be constant in writing tests was one of the most successful way to improve my coding productivity.

Plus: if you are using a continuous integration solution you can run all your test automatically after each commit (and for each pull request)!

Also code coverage is very important (especially in dynamic languages).  You know you can automatize code coverage as well? Coverall.io is one of the most known solution for this task and it is completely integrated with Travis-CI.

Code as if you are not the maintainer

Another good solution to keep you organized during software development is to code as if you are not the owner of the repository. Even if you are the only one coding on your code you have to be dual: there is the owner you, who review pull requests and keep the list of tasks, and the _coder you _who implements new features and propose the changes into upstream.

This help you in several way: 1) it forces you to be organized 2) it force you to be precise in commit history 3) it forces you to not bypass the previously described “quality checks” 4) you get used into working into other open source projects 5) you get used to work with external contributors.

So many benefits for just a small amount mental overhead!

In the end

These are just three small habits I try to apply. Obviously, I’m not able to always apply all of them, but when I can, I can see the results!

So, I hope you can find this a bit inspirational and try to find your programming good habits!