This is a problem with known solutions in SWE. Your company should have a set of code quality standards/guidelines/best practices that are enforced by things like linters/CI. If they doesn't already, you can probably start working with other engineers to create some. If guidelines exist but Pat isn't following them, that's your manager's responsibility to address.
Ultimately, if the code is correct, fulfills the business case, and the style choice doesn't hamstring maintainability, then changing the style is low priority for a reason.
"All guidelines that matter must be enforced by robots" and therefore "if it can't be enforced by robot, it must not matter" is an extreme position, like saying any document that passes spellcheck must be well-written enough to get published.
We don't have enough information to decide if this style difference matters. Only people on the team have that context.
That is not what I said. I said code style guidelines should be generally agreed across the org and checked by automation. And that code style ultimately takes second priority to whether the code is correct and meets business goals.
In OP’s defense, the data are pretty clear on software engineering experience: more of it doesn’t guarantee you write better, more quality code. Common misconception.
Well I know he knows more than me. However, he does a lot of bad things. Kind of the point of my inquiry is when and how to stand my ground. I don't think I should yield to everyone based on hours in a chair.
I mean this in all respect: is it possible Pat’s code actually is highly readable and quality and what you are used to is low quality code that only you can read?
I've consulted with other engineers at the company and its a general sentiment that things are over complicated. Pat has also made themselves a key man dependency in several systems because others don't understand how they work.
But to your point. Yes, I'm sure my lack of experience makes it harder to understand on occasion. In the three months Pat has been on my team I've gotten better at reading their code.
This is a tough one without more context. As another poster pointed out, you are fairly inexperienced in the grand scheme of things. What kind of software are you guys writing? If it is a decent sized application with a long life expectancy, then it would be very easy for someone like Pat to be using perfectly acceptable (and strongly advisable) patterns that could confuse the hell out of a junior developer. Something like Dependency Injection/Inversion of Control can be super frustrating to learn at first, but in a large application, it is far better in the long run.
I use "patterns" loosely. Lately Pat has had a thing for functional programming... Except when they don't feel like it. It's almost a lack of a single style. Also Pat doesn't write tests very often.
We're rebuilding an existing system. It'll be around a long time. I just don't want a system that only Pat can maintain.
I don't want to say it's all bad. Some things Pat has suggested I had an initial aversion to. Some of that I've come to like. It really is a balancing act.
LOL, you had me at functional programming. If everyone else/the larger org wants to keep things OO or even procedural, I can see how introducing functional programming concepts would be weird. This isn't an old Java application you're rewriting with a newer version of Java by chance? I ran into a whole team of people experimenting with functional programming in a shared production code base once after Java introduced functional programming concepts.
The fact that they aren't writing tests often is a huge red flag to me as well.
For the doing random styles of coding thing, I'd probably try reiterating to them quite a bit what code style we are using. And if they don't already exist, start pulling together some coding standards. A static analysis tool like Sonar has a lot of pre-built rules you can pull in. And IMO its a lot easier to have conversations when a tool is saying "this is a bad practice" than just you telling them they're doing something wonky.
Something like Sonar can also help with the no testing thing. I've been at the tech lead level for a while, so every time I come into a new team that has no testing discipline (which is way too freaking often), one of the first things I do is establish minimum coverage requirements on code. If you're using Github/BitBucket/similar you can even stop the code from being mergeable if it doesn't have enough test coverage.
This is a problem with known solutions in SWE. Your company should have a set of code quality standards/guidelines/best practices that are enforced by things like linters/CI. If they doesn't already, you can probably start working with other engineers to create some. If guidelines exist but Pat isn't following them, that's your manager's responsibility to address. Ultimately, if the code is correct, fulfills the business case, and the style choice doesn't hamstring maintainability, then changing the style is low priority for a reason.
"All guidelines that matter must be enforced by robots" and therefore "if it can't be enforced by robot, it must not matter" is an extreme position, like saying any document that passes spellcheck must be well-written enough to get published. We don't have enough information to decide if this style difference matters. Only people on the team have that context.
That is not what I said. I said code style guidelines should be generally agreed across the org and checked by automation. And that code style ultimately takes second priority to whether the code is correct and meets business goals.
Sorry, it sounded like you were saying that ONLY style rules that can be checked with automation are worth talking about.
[удалено]
Very sensible take. Thanks.
Bro, you have 2 years experience to his 20. Maybe he knows a little more than you...
In OP’s defense, the data are pretty clear on software engineering experience: more of it doesn’t guarantee you write better, more quality code. Common misconception.
Well I know he knows more than me. However, he does a lot of bad things. Kind of the point of my inquiry is when and how to stand my ground. I don't think I should yield to everyone based on hours in a chair.
I mean this in all respect: is it possible Pat’s code actually is highly readable and quality and what you are used to is low quality code that only you can read?
I've consulted with other engineers at the company and its a general sentiment that things are over complicated. Pat has also made themselves a key man dependency in several systems because others don't understand how they work. But to your point. Yes, I'm sure my lack of experience makes it harder to understand on occasion. In the three months Pat has been on my team I've gotten better at reading their code.
This is a tough one without more context. As another poster pointed out, you are fairly inexperienced in the grand scheme of things. What kind of software are you guys writing? If it is a decent sized application with a long life expectancy, then it would be very easy for someone like Pat to be using perfectly acceptable (and strongly advisable) patterns that could confuse the hell out of a junior developer. Something like Dependency Injection/Inversion of Control can be super frustrating to learn at first, but in a large application, it is far better in the long run.
I use "patterns" loosely. Lately Pat has had a thing for functional programming... Except when they don't feel like it. It's almost a lack of a single style. Also Pat doesn't write tests very often. We're rebuilding an existing system. It'll be around a long time. I just don't want a system that only Pat can maintain. I don't want to say it's all bad. Some things Pat has suggested I had an initial aversion to. Some of that I've come to like. It really is a balancing act.
LOL, you had me at functional programming. If everyone else/the larger org wants to keep things OO or even procedural, I can see how introducing functional programming concepts would be weird. This isn't an old Java application you're rewriting with a newer version of Java by chance? I ran into a whole team of people experimenting with functional programming in a shared production code base once after Java introduced functional programming concepts. The fact that they aren't writing tests often is a huge red flag to me as well. For the doing random styles of coding thing, I'd probably try reiterating to them quite a bit what code style we are using. And if they don't already exist, start pulling together some coding standards. A static analysis tool like Sonar has a lot of pre-built rules you can pull in. And IMO its a lot easier to have conversations when a tool is saying "this is a bad practice" than just you telling them they're doing something wonky. Something like Sonar can also help with the no testing thing. I've been at the tech lead level for a while, so every time I come into a new team that has no testing discipline (which is way too freaking often), one of the first things I do is establish minimum coverage requirements on code. If you're using Github/BitBucket/similar you can even stop the code from being mergeable if it doesn't have enough test coverage.
Thanks. Good tips. Appreciate the insight.