3 ms·

>The level of business and client knowledge, as well as prices and policy understanding required for tech positions is high. Whenever I read this advice, I get

>The level of business and client knowledge, as well as prices and policy understanding required for tech positions is high. Whenever I read this advice, I get "indie game developer" vibes. Indie game developers wear many hats and need a lot of breadth for obvious reasons: they don't have a lot of funds, they don't have a lot of people, they don't have a lot of specialist work you'd need someone for full time, but they do have a lot of different things that need to be done. Then I compare it to your regular corporate job, and it's the opposite in many ways. Tons of people. Tons of funds. Some people very specialized, some people somewhat generic for flexibility purposes. It makes me question why a developer in a corporate setting would need high levels of "business and client knowledge", or even "prices and policy understanding". Not because they aren't useful in theory, but because there's almost always someone with far more knowledge and decision-making power pulling the strings, to the point having such dedicated knowledge is more a waste than anything. The developer can't get to their level without sacrificing development time, or being with that company for a ridiculous number of years. And we already know companies in general aren't optimizing around long tenures.

NikolaNovak 4y ago
"Prices" was meant to be "process", but too late to edit :( And "business knowledge" is meant to be at a technical/tactical level, not at a strategic level. For example, an ERP developer implementing a new HR functionality benefits tremendously from being aware of HR law & process; a developer implementing T&L functionality benefits from being aware of T&L processes and business requirements; etc. This makes it a productive conversation of peers between functional and development teams, and they help each other create true and accurate requirements and specs that cover the edge cases. A developer that ONLY knows the technical aspect, in my world, will virtually forever be a "junior" developer, as I cannot send them to meet with functional teams solo and expect useful requirements to be gathered or correct code to be produced. The "client knowledge" is for process & procedures. Again, a developer that is junior/new to my project (they may be senior otherwise) will not have sufficient understanding of how our current public sector client needs code created, reviewed, approved, migrated, validated, etc. There's heaps of procedure... I'm not saying that's necessarily a good thing, but it's a fact of life in much of enterprise IT. Overall point being - 2 weeks trial would not work on any level. Developer would not know process and procedure, and would not have sufficient understanding of client's business and functional requirements and processes, to be productive yet for all but most generic and trivial of tasks. Finally, to your last point, my project / department / team / org does optimize for long tenures (that is of course empathically not the case in some other business units in same company that I'm aware of have different business plans and methods predicated around fast turnover). Each person is consciously an investment in continued training and support. We are pragmatic about turn over, but we do optimize around and crucially for people sticking around. My 100 Croatian Lipa, FWIW :-)

NikolaNovak 4y ago

"Prices" was meant to be "process", but too late to edit :( And "business knowledge" is meant to be at a technical/tactical level, not at a strategic level. For example, an ERP developer implementing a new HR functionality benefits tremendously from being aware of HR law & process; a developer implementing T&L functionality benefits from being aware of T&L processes and business requirements; etc. This makes it a productive conversation of peers between functional and development teams, and they help each other create true and accurate requirements and specs that cover the edge cases. A developer that ONLY knows the technical aspect, in my world, will virtually forever be a "junior" developer, as I cannot send them to meet with functional teams solo and expect useful requirements to be gathered or correct code to be produced. The "client knowledge" is for process & procedures. Again, a developer that is junior/new to my project (they may be senior otherwise) will not have sufficient understanding of how our current public sector client needs code created, reviewed, approved, migrated, validated, etc. There's heaps of procedure... I'm not saying that's necessarily a good thing, but it's a fact of life in much of enterprise IT. Overall point being - 2 weeks trial would not work on any level. Developer would not know process and procedure, and would not have sufficient understanding of client's business and functional requirements and processes, to be productive yet for all but most generic and trivial of tasks. Finally, to your last point, my project / department / team / org does optimize for long tenures (that is of course empathically not the case in some other business units in same company that I'm aware of have different business plans and methods predicated around fast turnover). Each person is consciously an investment in continued training and support. We are pragmatic about turn over, but we do optimize around and crucially for people sticking around. My 100 Croatian Lipa, FWIW :-)