Last year on 25th of December I decided that I will code every day starting from then. The reasoning behind that was “I will learn new things and become a more proficient programmer”. I decided to use GitHub for that because it has a cool contribution overview. I was able to code for 316 days and for me it’s a great result. It was a deliberate decision to stop this experiment after so long and I am going to tell you why.

Good parts

Ok, let’s talk about the good things first.

JS soup

One of my goals was to learn JS. I was not using much modern JS at work so this was an opportunity to become better at it.

I started some small projects written entirely in JS. I wrote my own router for Node server, simple JSON persistence service, and a bunch of more stupid ones. Those made me used to Node and dynamic nature of JS. It’s not a state of the art code but it did its job. Asynchronicity in Node kicked my butt a few times.

The best projects were those based on React. I can say that I learned how to simplify web development and bring more value to the client. All thanks to this library, it’s philosophy and simplicity. My team is using React right know and from my point of view, the world is a better place (no more over-engineered model-view-let-the-magic-happen crap - I could live with it before, but I don’t really want to).

Job

The next good thing is that I got a few job opportunities. Only because of commits on GitHub. It was a surprise, but a really cool one. Some of the offers were pretty interesting and that leads me to the conclusion that GitHub may be a way to get a job.

Habits

In the book The Power of Habit Charles Duhigg describes how powerful habits can be. They change your brain. Developing good habits makes your life easier. Sticking to the bad ones can ruin it. I saw this power myself. After a few weeks, it was a no-brainer for me to sit down and code. It became an addiction hard to break up with. Starting this year I’m trying to put more habits into my life. Exercising and reading seem to be a good choice.

Small cool things

Feels kind of cool when you tell people that you had been coding for 300 days.

This cool Halloween contribution overview is my creation:

Halloween contribution overview

Bad parts

Despite all the good things, this is the main part of this post.

Meaningless commits

It was common to commit tiny and meaningless changes just to not break the chain. Of course, before every commit you need to think about the code, so it has its purpose. Even though, it’s hard to commit when you are on holiday in the mountains after the whole day of hiking and your only thought is to get some sleep. Sometimes I felt like a slave of my own system.

Postponed learning

If you are like me and like reading the documentation/book/summary of the tool you want to use and only start coding after that, then you are in for deep mess. There is never enough time to read everything you want and code after that. It becomes harder to learn new stuff because you need to make the daily commit quota. The final result is that you code something meaningless (see previous point) and postpone learning new things. You are waiting for the better moment. But, better moments never come.

Problems with bigger projects and contributions

Sometimes you want to code something bigger. To write something bigger you need a plan. Making plans takes time that you don’t have. Again, you need to make the quota. This way it’s hard to write something bigger unless you have a lot of time. Otherwise, you would spend 1-3 days for planning. The need for code holds you back.

The same way it’s harder to contribute to other open source projects. To contribute you need to understand the code, contribution rules. You need to find the way to fix the issue or enhance the project. If you won’t make it in one afternoon then you won’t make the quota. Again, you are being a slave of your own system.

Breaking one habit breaks the others

Alongside with the habit of coding I decided to write a journal every day. It was successful until I broke up with writing code. After that, I failed in writing a journal. I don’t know what happened but it seems that habits are bound to break together.

Summary

Due to those bad parts it made no sense to continue the experiment. I didn’t want to feel like a slave and decided to move on. It was a nice experiment though. Enough good things happened to me. I teach about React. I’ve spoken at few meetups about ES6 and front-end development in general. I think I’m a better dev now.

Overall, I think that coding every day is not a good way to learn. At least for people that learn the way I do. Sometimes it’s better to take a break, think problems through.

I would recommend this experiment to the code ninjas - people with a lot of experience that just can’t stop themselves from coding. Ninjas will probably enjoy this kind of exercise the most as they tend to have more ideas. They already thought it through during the years of working with code.

If it’s about me I discovered that hackathons work for me fine as a coding exercise. Writing a small project to consolidate the knowledge you got from a training/course is also great. But you need to actually finish it.

Lessons I learned are definitely helpful for me, I hope some of them will help you too.