3 ms·

Deciding your tech stack solely on avoiding having to train people for a few days sounds like a terrible way to organise projects. How often is it really only

Deciding your tech stack solely on avoiding having to train people for a few days sounds like a terrible way to organise projects. How often is it really only a few days, though? If you're talking about learning a different programming language, that's no small thing for a junior developer. For a senior who knows multiple languages already and has a few years of experience, learning the new language itself might only take a matter of days to be productive, as long as it's still a similar style of programming to something they've done before. But then you need to find your way around the ecosystem so you can make informed decisions, and that ecosystem might be huge and mostly low-quality, even if the good parts that you eventually want to use are not. For similar reasons, in the case of web development specifically, I think people often have unreasonably high expectations from using JS/TS both front and back. Yes, it's the same language, more or less. Yes, sharing code can sometimes be useful. But the JS standard library is limited, and the ecosystem beyond that has almost nothing in common on the front and back ends. In practice, assuming you have some decent senior devs on your team, that ecosystem jump is still likely to be the biggest time sink even if you're running something in Node on the server. So I kind of agree with both the parent and GP comments. It is beneficial to use familiar tools and reduce the need to learn new things before you can be productive, but you are going to have to learn new things sometimes anyway and that might require significant time no matter what you decide to do. When it comes to making fundamental architectural decisions for a new project, it's wise to keep the potential costs of using new things in mind, but it's foolish to disqualify choices that might be better in the long term because of small differences in up-front costs.

creshal 5y ago
> How often is it really only a few days, though? Depends entirely on what you expect the devs to do, naturally. Junior devs are IMO not supposed to make informed decisions of significance in any language, that's what you have senior devs for. GP's use case of having frontend devs do small changes to backends and vice versa to avoid having to wait for The Other Team to have time, is very easily covered with really minimal training.
- Silhouette 5y ago
  GP's use case of having frontend devs do small changes to backends and vice versa to avoid having to wait for The Other Team to have time, is very easily covered with really minimal training. Sorry, but I can't really agree with that, certainly not for anyone below senior. Asking juniors, who don't have much breadth of experience yet, to jump from front end to back end is a good way to end up with subtle SQL injection vulnerabilities, or passwords being hashed with non-cryptographic hashing algorithms, or secrets that should be handled at the environment level being hard-coded and committed. Asking juniors to jump from back end to front end is a good way to end up with code that runs fine in Chrome but breaks in iOS Safari, or a subtle interaction between promises or awaits that deadlocks the whole UI if the server is unreachable, or styles that break when someone updates the theme six months later because two elements were the same blue at the time but the stand-in dev looked it up from the wrong place. Either way, there's significantly more for them to learn if they need to know a whole new programming language as well as the specific libraries and the general principles about security and so on. And either way, The Other Team are probably going to be involved and therefore a potential bottleneck anyway, as surely at the very least someone senior from that team will be required to review code changes being requested by someone from outside the team who doesn't normally work in their part of the code.
  - pseudalopex 5y ago
    I think you have different definitions of small changes. Minimal training is enough to add a read only field to a structure for example.
    - Silhouette 5y ago
      It's never just adding a field to a structure. That data is going to be there for a reason, and someone is going to write the code to do whatever that is. And to parse the data arriving in a request from the front end. And to validate the parsed value. And to perform the necessary security checks. Wait, shouldn't they have been done already? Where do we keep the validation logic in this design, anyway? Hang on, what type is this field? Is there a native way to represent that in this back-end language, or some convention we've adopted? Did the parser already handle that? It's never just adding a field to a structure.

creshal 5y ago

> How often is it really only a few days, though? Depends entirely on what you expect the devs to do, naturally. Junior devs are IMO not supposed to make informed decisions of significance in any language, that's what you have senior devs for. GP's use case of having frontend devs do small changes to backends and vice versa to avoid having to wait for The Other Team to have time, is very easily covered with really minimal training.

Silhouette 5y ago
GP's use case of having frontend devs do small changes to backends and vice versa to avoid having to wait for The Other Team to have time, is very easily covered with really minimal training. Sorry, but I can't really agree with that, certainly not for anyone below senior. Asking juniors, who don't have much breadth of experience yet, to jump from front end to back end is a good way to end up with subtle SQL injection vulnerabilities, or passwords being hashed with non-cryptographic hashing algorithms, or secrets that should be handled at the environment level being hard-coded and committed. Asking juniors to jump from back end to front end is a good way to end up with code that runs fine in Chrome but breaks in iOS Safari, or a subtle interaction between promises or awaits that deadlocks the whole UI if the server is unreachable, or styles that break when someone updates the theme six months later because two elements were the same blue at the time but the stand-in dev looked it up from the wrong place. Either way, there's significantly more for them to learn if they need to know a whole new programming language as well as the specific libraries and the general principles about security and so on. And either way, The Other Team are probably going to be involved and therefore a potential bottleneck anyway, as surely at the very least someone senior from that team will be required to review code changes being requested by someone from outside the team who doesn't normally work in their part of the code.
- pseudalopex 5y ago
  I think you have different definitions of small changes. Minimal training is enough to add a read only field to a structure for example.
  - Silhouette 5y ago
    It's never just adding a field to a structure. That data is going to be there for a reason, and someone is going to write the code to do whatever that is. And to parse the data arriving in a request from the front end. And to validate the parsed value. And to perform the necessary security checks. Wait, shouldn't they have been done already? Where do we keep the validation logic in this design, anyway? Hang on, what type is this field? Is there a native way to represent that in this back-end language, or some convention we've adopted? Did the parser already handle that? It's never just adding a field to a structure.