{
  "$type": "site.standard.document",
  "canonicalUrl": "https://rednafi.com/zephyr/domain-knowledge-dilemma/",
  "description": "Navigating the balance between building valuable domain expertise and avoiding over-specialization that limits career mobility.",
  "path": "/zephyr/domain-knowledge-dilemma/",
  "publishedAt": "2025-01-19T00:00:00.000Z",
  "site": "at://did:plc:fgtm2c26vfcj74rfmeggbyqj/site.standard.publication/3mnl6f7ob462z",
  "tags": [
    "Essay"
  ],
  "textContent": "Seven years isn't an awfully long time to work as an IC in the industry, but it's enough to\nsee a few cycles of change. One thing I've learned during this period is that, to be a key\nplayer in a business as an engineer, one of the biggest moats you can build for yourself is\ndomain knowledge.\n\nWhen you know the domain well, it becomes a lot easier to weather waves of technological and\nmanagerial change. This is especially true in businesses where the tech is mostly a fleet of\nservices communicating over some form of RPC. Doing something novel in setups like that is\noften hard. In situations like these, picking up the domain quickly and being able to apply\na template solution is probably one of the few edges we still have over LLMs.\n\nTelling someone to acquire domain knowledge in a business is kind of like telling a CS grad\nto focus more on protocols and less on mechanisms. Protocol changes are way harder, and\nmechanisms shift under your feet constantly - grappling with that change is just part of the\njob.\n\nThat said, not all domain knowledge yields the same result, and it's often not obvious which\nones deserve your attention or when diving too deep into a domain can actually backfire. For\nexample, large companies often build their own internal tooling, and knowing its quirks can\nbe a huge advantage while you're there. But if you switch jobs, reusing that domain\nknowledge can be tricky.\n\nOn the other hand, if you've worked on/with something like Bazel at Google or\nCassandra/HBase at Facebook, that's a different story. The names alone are much more\nmarketable, and you won't have any shortage of opportunities, regardless of whether the\nknowledge is reusable.\n\nKnowing the ins and outs of an internal feature-flagging system at your company isn't the\nsame as understanding the machinations of a database abstraction layer at Netflix. Not all\nof us work at Netflix, and finding that balance is hard. Sometimes you just have to learn\nenough to get by, and that's fine - learning is part of why we get paid. But domain lock-in\nis real. I've seen extremely good engineers get stuck in super niche areas and then struggle\nto pivot away.\n\nThis is probably obvious to veterans, but it wasn't to me when I started. I've seen some\npeople get burned by over-specializing, while others pulled off moonshots by spotting\nopportunities that let them do fantastic, novel work. There's a line between specialization\nand hyper-specialization, and most of the time, being more of a jack-of-all-trades isn't a\nbad thing. At the same time, it's neat to be able to identify those rare opportunities where\ngetting involved early can yield outsized returns.\n\n> P.S. Domain knowledge around a business and knowledge related to specialized tools are two\n> different concepts. I realize this post might've blurred the lines, mostly for lack of a\n> better term.",
  "title": "The domain knowledge dilemma"
}