My year started with a new full-time job. This week was pretty hectic in many respects, learning new people, new culture and of course a new codebase. Getting to see the code and work practices first time is an invaluable time to see and point out obvious issues that may not be visible after you get used to things. I love this phase but I’m also acutely aware that my findings and ideas may not seem very positive to everyone (even when they usually are intended to be).
Daily Notes
One of my oldest tools in trying to push tacid knowledge out of peoples heads and to keep team communication as open as possible, I’ve built a habbit of keeping a simple daily log of all my work. I just create a Google Doc or similar where I put short bullet points of things I’ve done and what I’m working during the day, and also general notes that I should maybe come back to or talk with someone soon.
I’ve found this practice to be really helpful for myself to remember all relevant stuff in the dailies with the team but also in situations where people may not be so easily in the loop on what someone in some other team is doing or to help with async communication when you hapen to be offline. More often than not the thing people are looking for (things like “did he start projext x yesterday”, or “why didn’t he merge this yet”) are already documented in my notes so it saves them trying to ask them and saves me of interruption when I try to stay in the flow (or am out running).
Some teams are super active on Slack, and that works to some extent, but it can also become pretty unwieldly pretty fast. I do like to use my Slack status for extra info at any given time (“Out swimming, back at noon”) to further help everyday communication without the noice for everyone.
The implementation details don’t actually matter that much as long as the team learns to communicate optimally and without too much noice.