It would have been more constructive for the author to make the same points as things they've learned that make a good coder rather than shitting on a colleague

It would have been more constructive for the author to make the same points as things they've learned that make a good coder rather than shitting on a colleague. Whether their colleague is using what the author would consider to be good practices or not, it sounds like the colleague is merely doing their best with the knowledge that they have and are apparently confident enough in their skills that they can get things done. The truth is that neither of these individuals are demonstrated to be senior-level by this article. Unless otherwise is said, I take it that the author hasn't actually done anything to elevate this new coder. Yes, I'm making an assumption, but that's what I usually see. Rather than create systems to help newbies of any experience level, most people would rather complain than, say, create requirements around new code being tested, or having lint rules. Most of the points the author makes are dubious. > 1. He puts everything in one file. There is no one answer on this. Prove that it's better. Oh, wait, you can't. And depending on the software community, it may be expected for verboten. > 2. He creates single letter variables I prefer verbosity, but some algorithmic things are better suited for single letters. Can be bad depending on how used. > 3. He makes functions with loads of parameters Honestly never understood why anyone gave a shit about the number of parameters. A better rule should be that a function should have a single purpose and only accept parameters related to that purpose. If there's a lot of parameters then either accept that fact, split the function up, or pass in named properties (or a hash). Even adding adequate JSDoc comments makes complex parameters understandable. I do prefer to limit the number of parameters, but getting your panties in a bunch if someone uses more than 3 parameters is usually a complete waste of time. If you don't like it, let the other person merge their PR and then change it yourself. > 4. He always makes massive Pull Requests Depends on the task. In many cases, small pull requests don't make sense because individual changes are potentially breaking and the nature of the task isn't a linear progression of changes. Maybe he's making massive PRs because you're giving him far too complicated tasks for his experience level. An otherwise simple PR can easily balloon because the developer is learning a lot of concepts as they're going, and they can't predict the eventual size of their work. > 5. He doesn’t want to write needs tests Not everyone is taught about tests. They might hear about tests, but in general people see tests as a nuisance, and I understand why, because when I work on hobby projects I don't write out a bunch of tests for everything initially. It's not fun. But in a professional circumstance, tests are a lifesaver because it's evidence that your work is sound and that you aren't likely to get an emergency phone call in the middle of the night. If someone doesn't experience the virtues of writing tests, it's not obvious why one would go through the extra work. The answer is to have standards around tests. Make it a requirement to at least have an integration, application, or e2e test for a change. > 6. Keep your tests green So you're saying this person is intentionally pushing tests that don't pass? And shouldn't you have a repository that prevents merging if tests aren't passing? > 9. He avoids meetings Maybe your meetings are bullshit. We're only hearing one side of the story on this. For all I know, you haven't invited him to these meetings on his calendar. I missed meetings in one of my first jobs because it turned out no one invited me to them. > 10. He thinks he is competing with everyone You've created an environment where he is competing with everyone. Instead of using him as a bad example on the internet, either figure out how to help him be the best he can be on your team or let him go (if you're in control of that).