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.
2 Likes
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.
4 Likes
A few months have passed and I feel the need to share my experience for any poor soul that finds this thread. In short, my intuition was correct. Having a setup that works for you for solving engineering problems is important. This is the matter of results, not ceremony. And I’ve had better results by ignoring most of what I was initially taught.
There is nothing specific in my project’s technology stack that can’t be accomplished only in the way I was presented with. This is just a typical case of “we’ve always worked this way”. Many project specific development and testing processes are just pure time wasting endevours that were not hard to solve given a tiniest bit of will to solve them. Sadly, this is the culture in this organization and problems just compounded over the years.
I’ve made a honest effort to use IntelliJ Idea for over 6 months and I can confidently say this is a great IDE, that is not working for me. I now code and even debug exclusively in Neovim. Not because it’s the best choice for a Java project (still have to iron out some rough edges), but simply because I can. I’ve also abandoned Postman by simply running our frontend locally. This was so radical that I was the first developer in project’s history to do this. There are many other things like that, one could write a book.
1 Like
I’ve worked on some projects with a lot of developers, and also as a platform engineer for internal teams.
I think that each individual’s way of working is the most sensitive topic that there is…
Do you install everything yourself? Do you develop in containers? Do you use one IDE over another because the configuration files were written by other team members to provide a quick and consistent means to get bootstraped? What O/S are you using? What libraries does that operating system use? Are the tools subtly different (OSX, I’m looking at you.)
I’ve seen some folks fly in a bash terminal, and others that only work within the IDE. It’s hard to make a consistent development environment that works for everyone.
The one point where everything converges is CI/CD, and if you architect that in a way where it pivots on Gitops, that seems to be the way
Use what you want to develop, but the deployment pipelines and testing gates work one way. Collaboration, communication, and lifecycle management should happen at that point, IMHO.
Bonus points if you can create a workflow that works for more than one person. That’s sort of essential in a large org. If there are a lot of manual or undocumented steps, if your git hooks don’t work outside of your machine, if the IDE setup is complete but you don’t know the IDE…
1 Like