Adpoting your team's ways vs doing thing your ways

TL;DR: What’s your opinion on adopting tooling and ways of your team/project versus doing things your way?

The long version
I’ve worked most of my software dev carreer (over 13 years since I was first paid for my code) in Java ecosystem. I’ve recently joined a new project and it’s a first time I’ve encountered significant differences of how my team works versus how I happened to work until now. Just as an example, my team uses IntelliJ Idea Ultimate and I’m strongly encouraged to use it as well for consistency. I’m an Eclipse dinosaur, tried Idea a few times over the years and this tool just never worked for me. I would also like to not get dependent or used to an expensive edition of a tool. I’m not paying for Ultimate license in this case, the client does, but I won’t stay here forever. In reality, every dev seems to do something a bit different, but major things like Idea remain. This causes a side effect where it’s not trivial to run project (Idea does some “minor thing” that should normally be in project configuration in git). Another example is that I’m supposed to just bang out raw REST calls to get the app in the state I need to do what I need to do. I’d rather just run the frontend locally and use it like the user would and only use raw calls as a supplement.

Do you personally just get into whatever your new project does and call it a day or do you keep using the tools you like? Where do you draw the line? I’m obviously not talking about things that impact the project and other devs. I’m absolutely not changing things in the code or configuration of the project to make my stuff work and I make sure to use whatever common code style. My output should look and work the same as anyone else’s. And the problems I have with my tools are just my problems.

10 years ago I’d say this is a big red flag, and that IDE shouldn’t dictate you how to do things and that projects should be written in an IDE agnostic way, e.g. building, tests, linting, etc. should all be runnable anywhere (in other words, everything that’s not my way was a no way). But today - it depends. Maybe this is a genuinely large complex project that justifiably requires this specific IDE due to some of it’s advanced integrations. Or maybe it’s due to team’s skill issue, maybe no one had time, money and incentive to organize everything differently. And so what, this is automatically a bad project? Likely not, if it works for them and project is profitable, yields some value. So this rather just your problem.

1 Like

If you are being paid, you are creating a “work for hire” and the client’s specifications are more important than your tech preferences.

Quite simply, being able to easily hire, train, and replace employees is a core component of business continuity. This is the reason Javascript and Python are used everywhere - not because they’re technically superior but because it’s trivially easy to find someone with those skills.

Oddball one-off members of the team create silos and silos are an anti-pattern. You’ve accepted the wrong position if you feel the need to fight the tool chain.

3 Likes