Last year, I was listening to a podcast on JavaScript Jabber and the topic of a code diary was mentioned. A code diary, is simply keeping a record of you’re daily coding habits, exactly like a regular diary but specific to development. It doesn’t matter where you write it paper, text editor, Google docs, etc. Somewhere preferably you can access it at anytime, you want to jot something down.

You may be wondering why this is useful and what to write in it, so let me explain.

Everyday you write, review, edit or interact with code in any way. Open up your diary and aim to write a sentence or two on the following:

• What you learnt during that day
• What you liked
• What you didn't like

It can be as brief or detailed as you like, I prefer detailed but after all it’s your diary. Now let me expand on each of these points:

What you learnt

Continuous learning is a must in the development industry, everything technical is changing on a rapid basis. It is important to want to learn, not only for yourself but companies want employees who are actively trying to improve themselves.

With great power comes great responsibility - Ben Parker

In my opinion knowledge is power. The more knowledge, the greater responsibility you have to share it with the World. By writing down what you have learnt that day means in future you can come back to reflect, track your progress and also share it with others in the community.

What you liked

You may think this is similar to what you learnt, and in ways they are but I think of it as a way of taking what you have learnt and applying it to your work. When writing or reviewing others code, you may see it written in a slightly different manner and think I want to use that next time. This is what you like, and what you actively try to incorporate in your next piece of work. For example: ES6 Arrow functions, I learnt about it in a Lunch &Learn session in work of a colleague Lyndsey Browning. I liked it that much, that I wrote it down and then used it in my next project.

What you didn’t like

You may think this is the easy one to do, as the technical industry can be quite opinionated. But what I recommend is not only write down what you didn’t like, write down why you didn’t like and how it could be improved. If this is your own code, you can see the areas of improvement that you can work on. If it is another’s work, by all means communicate and discuss its implementation but remember there is always a reason as to why it was coded that way. Find that reason out, it will spark a discussion and then by interacting you both have learnt something new.

Convinced you yet?

By now, you should see how helpful and important a code diary can be, but it starts with you. You need to make the time and effort to sit down and truly reflect on your activities. It doesn’t have to be daily but when you get into a routine, it is good to reflect and see the areas you can improve on. If in doubt, ask someone who you respect and look up to, to take a look and they can guide you also.

From my own personal experience: I found writing down the different points on a regular basis, kept me focused on my technical skills and what I wanted to achieve. I could start a fresh slate, every day and take what I learnt and apply it the next time. I started researching solutions more to find a practical example and talked to others on different implementations to knowledge share. I even started reflecting on not only technical skills but expanded it to personal skills too. I realised I could improve in my technical skills on a continuous basis but if I don’t work on my personal skills such as communicating with others, I could not achieve my goals that I am aiming for in my career.

When will you be starting yours?