3 ms·

This is an excellent observation. Thank you for making this. A pre requisite for "convincing" a large team is respect from the team. Assuming that it's not a to

This is an excellent observation. Thank you for making this. A pre requisite for "convincing" a large team is respect from the team. Assuming that it's not a toxic jungle, proven competence over a period of time is a good way of of earning said respect. Once you have that, you can cash it in for attention and people will listen. A more tactical thing is to actually do some work. You said that they don't have a style guide. Create one which you personally use and share it with your immediate team so that your own lives are better. Your immediate manager and team mates will have to work with you and if you start doing things which make your work obviously better, they'll pick up and that will give you mileage in the long run. Automated testing is hard in practice when there are a lot of external dependencies and when there's a huge legacy codebase. This is a case by case thing but just like before, if you have something to show and the respect to buy attention, you might be able to sell an idea to them.

gregjor 5y ago
"Show, don't tell" is a good principle. Don't tell the team how they should write better code. Show them an example that you can credibly argue represents improvement. Expect pushback and alternate opinions, don't fall in love with your particular style. Teams can get derailed over very minor things like tabs vs. spaces, so remember the important thing is a consistent style, not a particular style. Automated tests can be useful but don't expect the team to retrofit that, or for everyone to buy into it. You have to show the benefits in that environment.