Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
In my team, people share ownership over modules.
That way they usually know the code they are working on AND there's no issue if one owner is preocupied and work needs to be done on his module.
There is, of course, stepping out into the unknown, but that's to be expected.
@ravijojila ok but in my team we have like 2 big modules/projects. One is in JS, one is in Java. Everyone does everything. And when something blows up anywhere, it's all hands on deck... And no one really knows enough to just go "this is why it's fucked up". And if someone does, then why the fuck is it even in production. The answer is usually, because someone else wrote it and didn't think that this would happen.
I'm usually the guy that has to explain to people how they fucked up. And even then I have to find time investigating code and figure out why it's not working.
And it's usually some language specific thing or you need to really have at least the know how to find the tools that can be used to investigate.
I meant something smaller than a project: one functionality (business logic) or one feature or something like that.
In order for that to work, there needs to be someone who knows the whole project who can assign tasks based on best guess where the problem lies. Or, when someone tracks bug, he either finds a solution once he finds the module, or reassigns the bug to one of the module owners.
In your example, you would assign tasks/bugs based on research where the problem lies, but solving the problem would be someone else's responsibility. But that way, they woul get to know those modules, would most likely be working in one language and would, in time learn those spwcifics you mention.
Also, there should be 2 of yous, one for each project/language.
@ravijojila well that's how I would like it but I'm not the manager.
But I think then what your saying is pretty much the way I sorta see it? You can't have the whole team doing everything especially when it involves 2 different stacks?
The way you code and think about Java, other than the basics, is actually very different from JS (like using 2 different frameworks). But I'm starting to see that now except my boss still thinks they're easily interchangeable. And in terms of code quality and structural improvements, both have been stagnant or getting worse for years given the number of people putting in changes. People have been disabling tests or not even writing any because the testing framework was broken and no one knows or has the time to fix it or develop a better general solution.
I agree on all points.
erandria389369dat the very least, make them use linters, for js eslint.
it mitigates the code suckage
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job