As an intern, one of the more frequently asked questions you get asked is “what was the most important thing you have learnt?”. I know now that it is how I learnt to apply “processes” to make the most of you and your team’s time, but that was not always the case.
Previously, I would have responded with technical techniques or some anecdotal learnings. But how can such specific or situational lessons be the most important thing I learnt? Did I truly not gain anything that could be widely applicable?
Of course I did, although it was a struggle to distil my fledgling “insights” into words. The process of doing so has greatly helped to cement what I learnt and, having come this far, decided to write this blog post. I don’t expect any of these ideas to be new, but I hope that you too can gain something from my perspective on processes.
Processes are a KPI
In my short time at Kablamo, one thing that became apparent was that good processes lead to maximum utilisation of resources. Despite how the overhead introduced, such processes can quickly outstrip the marginal losses at the individual level, in favour of overall utilisation.
I may have known this intellectually, but it has been enlightening to see how much productivity can change as areas of friction were smoothed out. This has exemplified to me that, at some level, the processes themselves could be considered a Key Performance Indicator, and should be reviewed and refined just as much as the code to be delivered.
However, such vague statements are not very helpful so let’s dive into this in more detail.
Code Confidence
Something that I couldn’t appreciate until I became part of a real project, with people rolling on and off of it, was the importance of predictability. The harder it was to predict how new changes would affect the application, the more time was spent on verification - usually in the form of traditional debugging.
I found that usage of code formatters, unit testing, component libraries, code coverage thresholds, linters and other static analysis tools were instrumental in lowering this uncertainty. Thereby increasing the confidence that any changes made by a contributor would work as intended.
Inappropriate lint rules and tests of questionable value (for example prolific use of snapshot tests) are to be avoided, as they often unnecessarily increased complexity or artificially raised confidence. However, effective use of such tools greatly reduced the amount of second-guessing for both code authors and reviewers, allowing for faster feedback and iteration time.
CI/CD as a Source of Truth
If the tools above were used to build code confidence at the developer level, then Continuous Integration and Continuous Development/Deployment (CI/CD) was how that confidence was shared and solidified into a baseline level of quality. By preventing the merging of any changes that do not meet an expected level of confidence, CI/CD pipelines can establish themselves as a source of truth, if you will, about the quality of the final product.
I also found development and test environments extremely useful to compare and contrast your local changes with the current established “truth”. It provided a more wholistic view that highlighted any unintended divergence and exposed unaccounted edge cases - in both your own changes and others'.
These deployments ended up being a powerful way to set expectations for all members of the team, and served as a good reference for any cross-discipline discussion.
Slack is More than an IM
Slack is a communications platform, and is rich with features and third-party integrations. Despite this, it is easy to fall into the trap of using it like any other Instant Messenger. In the same way human speech is more descriptive than plain text, I feel that judicious use of Slack’s features can significantly enrich your messages.
Although there is a lot of benefit to be found in to developing your own “Slack style”, there were several techniques that I settled on I felt leveraged Slack’s features best.
Link any context - Slack supports creating links with custom text. Whenever you can link to a relevant resource that will provide further details and/or context, link it with something descriptive. It is much easier for responders to click your links rather than find those resource for themselves. Use Slack integrations (e.g. for GitHub or Jira) to provide previews, as they generally summarise the link much better than the default previews.
Maximise audience, minimise @mentions - The idea is to have conversations with as few participants as needed, but in a highly visible manner. It is an indirect way for other team members to keep abreast of what is happening, and leave historical evidence of any decisions made. Try to start new discussions in your “primary” channels with the most members. Try to write every message as if they will be the start of a thread (or, alternatively, try to convert other peoples’ messages into threads). In general, try to have your messages be in as many peoples’ history as possible.
Today I Learnt
My final insight, is to be open with what you have learnt. There is such an incomprehensible amount of knowledge, techniques, and features that any personal learning can be supplemented and augmented by taking advantage of the collective knowledge of your group.
Much like this blog post, which had been embarrassingly torn apart by my mentors, if you come across something you believe would be useful for others to learn (such as React strict mode or AWS Infinidash), talk to someone about it and hope to be surprised.
It was an invaluable experience working with such brilliant people, so ready to critique and teach a junior like myself. It is in no small part due to this, that I have gained as much as I have from my short time working there.
