Development Diaries and Today I Learned Repositories

One of the difficulties in technically mentoring juniors you don’t see on a near daily basis is ensuring the right level of challenge and learning. It’s surprisingly easy for someone to get blocked on a project or keep themselves too deep in their comfort zone and essentially halt their progress for extended periods of time. An approach I use to help avoid this stagnation is the keeping of a “Development Diary”.

A development diary, which I’ve heard called by many other names, is simple in concept and can be just as easy to implement. It’s the commitment to write down something that you’ve learned in your role each and every day. Over time it becomes a collection of small wins and achievements and shows that even little learnings have a big cumulative impact. While the daily aspect isn’t essential, and I’ve had people on more “Business as usual” focused teams reduce the frequency to as low as once a week, I think that while you’re at a more junior point in your career it should be easier to find new things to take note of than the awkward part in the middle where you’re doing the same thing for the fifth company. One of the best diaries I’ve had the pleasure of reading was by a non-native English speaker and nested amongst the usual technical content was the occasional gem, an explanation of an idiom they’d heard and tried to work out before looking it up.

The best technical implementation of a development diary I’ve seen recently was a simple git repo of directories. A single post, written in markdown, was added each day. It served as a great little git learning project for the junior (pull request reviews, branches and merging in to master) and provided an excellent single location to both look back over and see how much they’d learned over the last five months while providing them with starting material for their more formal quarterly reviews.

Watching this diary grow as a mentor provides some helpful insights in to how the person is doing. You can see what they consider interesting, if their focus is narrow or ranges over entire parts of the work and, if nothing is added for longer periods of time, can provide an early warning. I’ve found that not having anything to add for longer periods of time is a red flag and highlights that something is happening that requires more attention. It could be the person’s either blocked at work, has something else on their mind or isn’t being challenged. None of which are ideal for anything beyond short periods of time.

As an aside while I’ve had the most success using this in a one-to-one basis with juniors I’ve tried it a few times across an entire team when doing a discovery phase for a larger piece of work. I’ve found it a lot harder to achieve consistent buy-in in this environment. Especially when external contractors and companies are involved as it requires a fair amount of trust and honesty between all involved for it to be useful. When used in this way the willing involvement of the more senior technical people and how the juniors consider them seems to be the best indication of whether it’ll have a positive impact or not. In a more nurturing and sharing team the seniors are willing to show what they didn’t know without risk of losing credibility and the juniors are open to show their progress without being judged harshly. In a less functional team the juniors are very hesitant to risk embarrassing themselves and the seniors hate the idea of showing weakness or gaps in their skills.

Something I’ve had a lot less success with is nearly the reverse of a “Today I Learned”. A place to collect the things you didn’t understand while working. I find it hard to determine how much material to record in this form and walk the line between having some guidance tasks for downtime and self-paced learning while not becoming a disheartening pile of things you never get to.

It’s more prescriptive than I’d normally be but I think the next time I start with a new person I’m going to push the path of a “Today I Learned” git repo rather than the usual completely free form approach. I think it provides a nice segue into things like git while also sounding much punchier.

I heartily recommend a development diary, even if you have a blog, as it’ll provide a great little way to health check your own learning while ensuring you write down all those nifty little tidbits you stumble across.