Mastering your day as a programmer
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.
How do you program? I feel like there is a lot of advice out there, but most of it focuses on the micro level rather than on the macro level. That’s why I decided to think about what makes one an efficient programmer on a macro level.
Think long-term
Spend time on improving skills that help you become more productive in the long run. For example, it’s a fact that git is the version control system of choice. And there is no reason why this should change tomorrow. Or in 5 year’s time. That in turn means that you need to know the ins and outs of git. Period. It will make you so much more productive in the long run. I started knowing almost nothing about git. But I used Google heavily whenever I wanted to do something with git I thought it must be capable of but I had no idea how. I created a file with git commands and an explanation for it to learn.
Same thing with all tools that you rely on heavily. Become a super user of the tools you use everyday (most notably the IDE you are using) to give your productivity a boost. Make sure you follow up on the major changes that come with new releases of your tools. Know the keyboard shortcuts. And so on. You get the point. If you find this difficult, follow the “Editor XYZ Tips” on twitter or your social media platform of choice.
Solving a problem often does not only help you solving this very problem. It also gives you experience that you can transfer to other projects. Hence, it may make sense to spend some more time on a piece of code simply because it makes you a better coder. Whenever you think ok, I did it, but I am sure there must be a better way, it’s probably time to remember this paragraph.
Take breaks
It sounds like a contradiction but I feel like taking breaks is among the most productive things you can do. This does not only apply to programming, but also other work. I think taking breaks becomes more important the more complex the task at hand is. Taking a five minute break every 90 minutes sounds reasonable to me.
Zoom in, zoom out
This is related to taking breaks. However, you don’t need to take a break to benefit from the zoom-out-effect, but if you do take one, it happens automatically. The thing I am talking about is moving from a low-level perspective to a high-level perspective. This is crucial as we programmers tend to get stuck with a problem and then try to solve the problem inside the box, although the obvious solution is outside the box. Zooming out is highly effective if you are stuck. But you first need to realize that you are stuck. It can also happen that you programmed something that creates a lot of unnecessary complexity / redundancy downstream, and that it eats you up. If you feel like that, it’s probably time to zoom out.
Break down your tasks into pieces
Another arguably straightforward piece of advice. Instead of starting to work on a
problem right away, it often makes sense to break it down into smaller portions.
These should be as self-contained as possible. Start out with the sub-task that
has the fewest dependencies. When you are done, document and commit your work.
I often left the office thinking “oh I am going to commit this tomorrow” and I
forgot. By lunchtime the next day, I ended up with a convoluted git diff
.
This sucks. Also, documenting at the end of a two-month project sounds like
trouble, so make sure you keep documentation up-to-date during the development phase.
Work in a team
An African proverb goes as follows:
If you want to go fast, go alone. If you want to go further, go together.
No one is perfect. And I personally also don’t enjoy working alone. Having someone who reviews your code, asks the dumb questions and challenges you is in your best interest.
Live a healthy life
I am not going to tell you how to achieve this. Just two things: Drinking enough water during the day is essential to achieve good performance and exercising certainly does not hurt it either.
Create a productive environment
I get distracted easily if people around me chat. For that reason, I often listen to music while at work. I can listen to the very same song for a whole day and it does not bore me. Rather, it’s the contrary. On the other hand, I can’t listen to random songs all day long because they take away too much of my attention. Anyways the point I am trying to make is that you should create an environment that lets you concentrate on your task. This involves other things such as:
- enough fresh air in the room you are working.
- the right amount of light.
- the right temperature.
- and so on.
Catalize your thoughts through writing
Another strategy if you don’t feel like making any progress is to take a few minutes and write things down.
Write about your problems. It’s more precise than thinking.
Francoise Chollet, creator of keras
Writing forces you to express concisely what the problem is, why your solution does not work and what it may take for a solution to work. It forces you to abstract from the irrelevant, focusing on what the key drivers of your problem are.
I hope reading this blog post will help you mastering your day. And those to come. Feel free to comment below if I missed an important point. I may add it later to the post if you permit.
R-bloggers.com offers daily e-mail updates about R news and tutorials about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.