The domain knowledge dilemma
Seven years isn’t an awfully long time to work as an IC in the industry, but it’s enough to see a few cycles of change. One thing I’ve learned during this period is that, to be a key player in a business as an engineer, one of the biggest moats you can build for yourself is domain knowledge.
When you know the domain well, it becomes a lot easier to weather waves of technological and managerial change. This is especially true in businesses where the tech is mostly a fleet of services communicating over some form of RPC. Doing something novel in setups like that is often hard. In situations like these, picking up the domain quickly and being able to apply a template solution is probably one of the few edges we still have over LLMs.
Telling someone to acquire domain knowledge in a business is kind of like telling a CS grad to focus more on protocols and less on mechanisms. Protocol changes are way harder, and mechanisms shift under your feet constantly—grappling with that change is just part of the job.
