Commit code to a public repo for 30 days.
A while ago I spoke about doing a 30 day github streak challenge. Well I went for 100 days instead 🙂
What are github streaks
Github streaks show how many consecutive days a user has committed a change or raised an issue to a repository.
Why attempt a consecutive streak?
I believed by committing code every day for 30 days that I would improve as a programmer. By committing code, it made me think carefully about code quality more so because my repos were public.
At times I would spend hours getting a piece of code to work and end up committing a single line. Which was okay as long as I committed something. The goal of the challenge after all was to get in the habit of delivering worthwhile code.
First week was particular difficult as I adjusted to the pressure of committing something worthwhile every day, especially on the weekend. By the 2nd week it became a habit, I would eat, sleep, code.
When the 30th day finally arrived, I didn’t want to stop, I felt like I could do this forever! So I decided,I would aim for 90 days.
I started to feel a change, I felt that if I kept this up that I would become a competent web developer. I started to see the effort paying off in small ways. For example, understand new concepts a little quicker than before, solving small problems more elegantl, it also made me realise how little I knew. So I pushed on.
Slowly my enthusiasm began dwindling, at this point I wanted the challenge to end.
I felt victorious, I reached my goal but…. what if I went for 100 days, that seemed like a nicer round number.
I went to bed at 11pm and realised I hadn’t yet commited. I got up, commited a code fix that was bugging me the previous day and went back to bed.
At the point, I started to feel burnt-out. I had reached my capacity. I had already completed my original goal, there would be no shame in stopping now, but I was too close to stop.
This was a wonderful day, I got up and all I wanted to do was commit one more code so I can take a break for a while. Do something else, read a non-technical book, spend time playing video games, anything as long as it wasn’t to do with coding.
A breather was needed.
Once I committed the last piece of code, I felt great. I had pushed mysel, learnt a lot about coding and myself in the process.
What I learnt
Don’t break the chain.
I got this idea after reading a lifehacker article explain how Seinfield stays productive[http://lifehacker.com/5886128/how-seinfelds-productivity-secret-fixed-my-procrastination-problem].
Imagine as if each day in which you commit a piece of code is connected via a chain. The day you don’t commit, you break that chain. Simple but effective approached to productivity.
Remind yourself as to ‘why are you doing this’
It’s important to remember why we are doing something. Times when the challenge felt bothersome, I reminded myself that I was ultimately doing this so I can improve as a developer.
It’s a marathon not a sprint
Learning to deliver develop great software is a long journey, so I shouldn’t rush it and should at times take breaks to avoid burnout.
Better to deliver something than not at all.
This challenge forced me to deliver code rather than waiting until a piece of code was ‘perfect’ or the project was ‘perfect’. This is not a good attitude to have, so I wanted to eliminate it, I wanted to become a person that delivers code rather that just talks about wanting to do it. This reminded me a lot of a Steve Jobs quote “Real artists ship”.
I’m going to take short break, I’m not going to commit anything for a while. I’m still going to code, of course! I enjoy doing it, however I’m going to code without the pressure of committing something. Going back to coding for the fun of it, experimenting without any expectations.
Perhaps one day I might do a ‘Pull request streak’ challenge! 🙂