3 ms·

Onboarding in domain specifics is different. Language and programming fundaments have to be taught, and companies rarely have any decent processes around it, a

Onboarding in domain specifics is different. Language and programming fundaments have to be taught, and companies rarely have any decent processes around it, and it eats a lot of time from other developers. Domain knowledge can be gathered from literally anyone in the company, and also unless you are a senior, you don't need that much of understanding. Moreover, you can do some tasks without knowing anything – fixing nasty bugs nobody has time for, automating some stuff. During doing that you can get some ideas what it is about. Another point is that person with experience already immersed into other/same domain in the past projects.

wwweston 8y ago
The term domain knowledge may not be specific enough to convey what I'm talking about; "domain app logic" might be closer to what I'm getting at. It's the domain specific portion of a given system. It (hopefully) represents domain knowledge or is oriented around a process informed by that knowledge, but it's encoded in the software (and docs, if any). I can see why many companies don't often have a process around teaching programming fundamentals and prefer to hire those who can demonstrate competence in one or more languages. I understand less why companies with a determination to build their team rarely have any kind of methodical approach to introducing developers to their systems and seem to prefer sink-or-swim ad hoc task assignment. There's a consistency to that approach with the approach of a precise list of specific stack/tooling requirements, of course: it says "we want to rent talent, not develop it." And that approach has its merits, even. But there's an inconsistency, too -- if your primary approach to introducing people to your existing systems is learn-by-flailing, why be concerned about avoiding that with frameworks and languages, too? Especially when, as far as you're concerned, the familiarity that matters is with specific languages and frameworks as used by your system.

wwweston 8y ago

The term domain knowledge may not be specific enough to convey what I'm talking about; "domain app logic" might be closer to what I'm getting at. It's the domain specific portion of a given system. It (hopefully) represents domain knowledge or is oriented around a process informed by that knowledge, but it's encoded in the software (and docs, if any). I can see why many companies don't often have a process around teaching programming fundamentals and prefer to hire those who can demonstrate competence in one or more languages. I understand less why companies with a determination to build their team rarely have any kind of methodical approach to introducing developers to their systems and seem to prefer sink-or-swim ad hoc task assignment. There's a consistency to that approach with the approach of a precise list of specific stack/tooling requirements, of course: it says "we want to rent talent, not develop it." And that approach has its merits, even. But there's an inconsistency, too -- if your primary approach to introducing people to your existing systems is learn-by-flailing, why be concerned about avoiding that with frameworks and languages, too? Especially when, as far as you're concerned, the familiarity that matters is with specific languages and frameworks as used by your system.