4 ms·

> 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 infor

> 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.
    - pseudalopex 5y ago
      The scenario was a front end developer making a small back end change or vice versa. In such cases the rest of the code to be written will be in the part they're familiar with. Sometimes the field isn't part of the request. Or maybe part of the minimal training was wrapping ValueError in BadRequest. Or maybe part of the minimal training was we have an exception handler do it automatically. Often there aren't any new security checks. Sometimes field types are documented. Sometimes you have an integer in the database and need the same value as an integer in the front end. Most of the issues you brought up don't go away if you use JavaScript everywhere. Learning a little of another language is comparatively simple.

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.
  - pseudalopex 5y ago
    The scenario was a front end developer making a small back end change or vice versa. In such cases the rest of the code to be written will be in the part they're familiar with. Sometimes the field isn't part of the request. Or maybe part of the minimal training was wrapping ValueError in BadRequest. Or maybe part of the minimal training was we have an exception handler do it automatically. Often there aren't any new security checks. Sometimes field types are documented. Sometimes you have an integer in the database and need the same value as an integer in the front end. Most of the issues you brought up don't go away if you use JavaScript everywhere. Learning a little of another language is comparatively simple.