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, when 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.
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 from a colleague. So I wrote it down and in my next project I worked on, I refactored my work to include these arrow functions.
What you didn't like
You may think this is the easy one to do, as the technical industry can be quite opinionated. 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.
Have I convinced you yet?
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.
This was my first post, I hope you enjoyed and thank you for taking the time to read it.
Top comments (0)