Working on RFCs: Some Takeaways
It is very likely that a few years into being a software engineer one could be tasked with either assisting a more senior engineer or even working independently on RFCs (Request for Comments). In some organizations, these RFCs are called “Tech Specs” or “Design Docs”, but really they all are effectively the same thing. These can be daunting as they are a deviation from the day-to-day that a more junior IC (Individual Contributor) is used to: compartmented, more clearly defined programming tasks.
An RFC focuses on either introducing a new technical component(s) to a system, modifying or improving an existing one. More often than not, these are to achieve some sort of product objective. Sometimes, these could be focused on improving an existing, or maybe legacy system either for just overall design improvement or to eke out a little more performance from it. As a side note, this post focuses on RFCs that are typically found in technology business organizations rather than programming language, or protocol RFCs that have much larger scope and tend to have more open-source elements.
The challenge with drafting and going through the whole process of producing a good one, in my limited experience, is that it exercises a slightly different, yet broader skill set.
1. Understanding the Existing System
In the traditional sense of it, software engineers spend most of their time writing code. However, while working on an RFC, there is a need to look at the system and take a “snapshot” of it, nuances and all. This typically entails reading code across the different system components. For instance, if the system comprises two HTTP services alongside their datastores, one web client and a CLI client, then if the RFC that will be proposed affects any of these pieces, reading through the code and tests that implement these components helps create this visual, as the author. Sometimes I find that capturing the system under design using sequence diagrams or other tools can prove useful too. As you poke around parts that you have no familiarity with, it’s possible that questions like “Why is A implemented using approach X instead of the more straightforward approach Y?” form in your mind. At times like this, it’s best to either cross-reference the RFC that proposed the approach or simply leverage git blame and set up time with the code author to understand the reasons (when you do understand it, it might be useful to throw in a comment explaining why, so as to save time and effort for other readers who might encounter the same question).
2. Understanding the Stakeholders
While writing code, there is a level of empathy utilized. Nevertheless, it is limited to the users of the feature, fix, or improvement being implemented. With RFCs, the table of stakeholders to which this empathy must be extended to, now stretches wider and has product managers, program managers, possibly engineers from other teams and engineers on your team, end-users, and sometimes even legal counsel! It is essential that once this is realized, value points, requirements, constraints, and the like are noted down and kept in mind when drafting the RFC. Requirements change, and they change frequently, and the changes come from different stakeholders and could make you go from design decision A to a diametrically opposite design decision B. Adaptability, flexibility, and openness of mind to scrap parts of your draft that do not fit the requirements become key skills. Besides, it is important to recognize that each of these stakeholders brings valuable input that has the overarching goal of making the change as good as it can be.
3. Utilizing the Feedback Loop
Feedback to proposed changes in most technical organizations play a crucial role not only in improving and shaping the solution but also act as a mentorship opportunity. When your document is ready for review, and the comments and suggestions start pouring in, one of two things usually happen: you either respond with conviction that your solution to the specific problem addresses the concern and explain your thought process or you then second-guess and see that there is a major flaw in the solution and you need to go back to the drawing board. It is not a bad thing. It is a learning opportunity and the time spent to “loop-back” is most likely accounted for in project planning. However, during the “loop-back”, is when you go to the person who made the suggestion that took you back to the drawing board and discuss with them the alternative and how they would design that piece. Another take away from my experience is that, in this phase, when the person is a senior or staff-plus engineer, they tend to guide by nudging rather than by hand-holding so as to allow you to uncover the solution on your own. This has proven on many occasions to be valuable in my professional growth.
These are some things I’ve learned over the past couple of years while working on RFCs and I’m sure I’ll have more to say as I trudge happily along this journey of being a software engineer.