|
|
|
|
|
by retcon
1470 days ago
|
|
1 may be better asked as what aspects of your team understanding of any considered language apply to your problem space. How well can you port that knowledge to another model of expression. 2 is fine. the more significant question is often do you want to work with that talent pool and does the pool tell you more about the costs structure of your sector against which information you may prefer to tack against the prevailing winds and even more patiently attempt to trade actual equity for deep abilities and stuff what language is chosen if your stock has value. I don't understand how much attention individual languages receive. Plural understanding across your team and ability to transcribe the code into valid parseable docs against which APIs are easily written, is paramount in my mind. Corollary to my incredulity I have often thought that you emphasize the codebase language and dialects only to find you fuelled holy wars and dissipated your technical mission values. Which is disastrous for hiring the kind of colleagues we get up in the morning and forget about industry grief to share increasingly awful spaces with. |
|