These are questions for wise men with skinny arms

For my annual review I had to recall what I’ve done well and where I need improvement. Previously I used my notebook with my //todo lists and debug ideas to evaluate what I was working on and how well I did. This worked great when my projects were small enough in scope that I had design and debugging notes for each part that I accomplished. It was easy to see when and where I had problems and then address those issues accordingly.

I could count the number of pages that showed I spent too much time reading and mapping out code when I made much bigger steps in the debugger. I could see that my tests were effective because the projects where I wrote tests first had fewer issues later when I made changes. The length and detail of my notes was a metric I used to measure my technical progress.

But for my most recent project, I found that metric wasn’t informative anymore. I took very few notes during most of my tasks (user stories), and a disproportionate amount of my notes were on one or two really nasty infrastructure bugs that I needed my team to help fix. I found I wasn’t taking notes for myself anymore, I was taking notes to share what I was doing with my team. This was great for stand-ups and other collaboration opportunities; I always had an updated list of the specific technical problem I was on and what other related problems were in progress or just solved.

Upon review, I found them to be mundane and uninformative. Noting that I was ’testing and integrating fields i,j,k from the database to the front-end’ was important for my team if they had issues accessing or verifying the correctness of field k, but now that information is irrelevant. I don’t have any information about what I was thinking in a technical sense outside of my commit history.

I’m now going to start keeping my domain notes separate from a technical journal. I didn’t like the experience of looking back at 6 month project and thinking “Did I actually learn anything?”. I knew I was getting things done, my commit history and those fancy graphs of story points proves when and where that happened. I now need to keep track of what articles I’m reading and what tools I’m learning to use. Before, I didn’t realize that over the course of the project I gained a whole ton of T-SQL experience until a team member asked how in the heck I knew how to do a feature that needed it.

I don’t know if I’ll post my insights here, as I feel they might be trivial things like learned more tmux shortcuts or used an sql output clause. Or even less useful notes about internal tool quirks and infrastructure experiences.

I searched for examples of writing like this, but it seems like dev blog is either a marketing tool or a way to document in-progress or complete projects. I’m just looking to keep a record of my assorted technical experiences!