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. That said, not all domain knowledge yields the same result, and it's often not obvious which ones deserve your attention or when diving too deep into a domain can actually backfire. For example, large companies often build their own internal tooling, and knowing its quirks can be a huge advantage while you're there. But if you switch jobs, reusing that domain knowledge can be tricky. On the other hand, if you've worked on/with something like Bazel at Google or Cassandra/HBase at Facebook, that's a different story. The names alone are much more marketable, and you won't have any shortage of opportunities, regardless of whether the knowledge is reusable. Knowing the ins and outs of an internal feature-flagging system at your company isn't the same as understanding the machinations of a database abstraction layer at Netflix. Not all of us work at Netflix, and finding that balance is hard. Sometimes you just have to learn enough to get by, and that's fine - learning is part of why we get paid. But domain lock-in is real. I've seen extremely good engineers get stuck in super niche areas and then struggle to pivot away. This is probably obvious to veterans, but it wasn't to me when I started. I've seen some people get burned by over-specializing, while others pulled off moonshots by spotting opportunities that let them do fantastic, novel work. There's a line between specialization and hyper-specialization, and most of the time, being more of a jack-of-all-trades isn't a bad thing. At the same time, it's neat to be able to identify those rare opportunities where getting involved early can yield outsized returns. > P.S. Domain knowledge around a business and knowledge related to specialized tools are two > different concepts. I realize this post might've blurred the lines, mostly for lack of a > better term.