Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@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. -
@erandria but that's just syntax. I think we use that but that's not going to fix badly or incorrectly/inefficiently written code?
-
@billgates I've worked in a hybrid Java/ Javascript environment too for a year. 5 developers, 2 focused on Java, 3 on Javascript. The Java devs did everything on back-end, and also helped front-end (more work there), and when we had disagreements/ saw a pattern in types of errors, we discussed it, chose an approach, and documented it in the project readme. If a pull request didn't adhere to the defined guidelines, the reviewers didn't let it pass.
-
@webketje right so in that case there are clear owners? Like those Java devs know pretty much how the code works and what shouldnt be done and they can do things faster so they actually have time to do reviews and make more technical improvements?
Does anyone work on a team with multiple stacks?
For example we have batch jobs in Java but also have a JS front-end and APIs.
How do you divide the developers and the work across these projects?
Currently everyone does everything but I feel like this is inefficient and hard to develop expertise. And different people or even the same person will make the same mistakes over and over again because they don't know how to do X or they forget or overlook some quirk. When I switched Beck to JS took me like a week to get a Promises nailed down again. And this morning someone else had a production bug and couldn't figure it out. But when I looked at the code I could pretty much see where an issue could be (uncaught exception in a promise)
Also the testing frameworks are very different and there's a lot of infrastructure technical debt, things that really should've been done a long time or fixed but no one had the time or expertise to do it or notice it (until it causes a production issue and then everyone is like WTF is happening??!!!!).
I'm not the manager but I always feel that the team needs to be split along the language lines and specific people need to own these projects to review and code changes for all these common newbie errors. And also developer enough expertise to foresee problems before it becomes a production issue.
question