Never work on a feature which is too huge so it needs to be divided among multiple developers. Reason because there are high chances that one of the devs will do one or more of these:
- Follow his/her own coding style rather than what the system already follows.
- Write generic flows based on his/her part alone making it super difficult for rest to reuse.

  • 3
    If there only would be a management to keep them in line...
  • 0
    Coding style should be enforced in the CI pipeline. The second part can be helped with pair programming
  • 2
    That indicates a bad team spirit or to big teams.

    We have 2-4 backend devs and 2-3 frontend per team. Thats small enough that they can all check each others code and thereby ensure some minimal common syntax and style.

    If they still fail then that is a management problem that does not set the demands correctly.
  • 1
    You basically summed up what I've been annoyed by for the last few months. I'm more and more convinced that the person on my team is doing it on purpose just to "leave their mark" 😭
  • 1
    When we assign 2 devs to the same feature it's not to make them work in parallell silos. It's to pair program. (Except when it's entirely different code bases, like an api dev a frontend dev)

    It's not twice as fast. More often than not it's twice as slow. But when 2 people coded something it doesn't need nearly as mucynthorough code review as when it was a solo job.

    PS: we have a rule that there's a limit where pair programming becomes ridiculous. And that's css pixel pushing. that can be done solo. as long as you resume pair programming if you changed something majorly like moving from flex to grid.
Add Comment