A few years ago, I had been working in a company where I was working with a developer with 10+ years of experience. I never met that guy's face to face, but when I was doing a code review of his code, I often found things like that:
I tried to talk to him, but I did't find understanding between us, but he had been correcting all the remarks about his code, so I just had been checking his code more thoroughly than code of other team members.
Although probably a violation of the YAGNI principle, this is an entirely valid way to structure this code with an eye for future maintenance. Perhaps the dev who wrote this has done the refactor from return isSomethingTrue(); to this structure so many times -- to add logic to one or both branches -- that they now default to the latter. And they expect that in the average case it will save time.
I don't do this thing in particular, but I will sometimes opt to do longer-form ways of structuring things when they are more amenable to maintenance in the future.
Shit regular happened, but fortunately, there are companies where code quality is still very important.
Of course the code quality can be sacrificed for the sake of performance, but I had to do it only once in my life when I had to optimize the algorithm from 120 processor clock signal to 10.
Obviously I don't know about the specifics of the senior dev you're talking about, but sometimes junior and mid level developers can spend too much time sweating the unimportant stuff (when viewed from a senior developer perspective).
So for someone who is in the first few years of development (or someone who has OCD), coding is hard enough without also having to deal with brackets in weird places, inconsistent spacing and code like the sample you just posted. I get that, and I think it's something that senior devs should probably consider more.
The thing is, most senior devs will know that development wise that kind of stuff is never what kills a project, what kills a project is things like: sloppy architectures (or no architecture, or 3 architectures in the same app and no communication about which one should be followed), or a lack of tests (or too many pointless tests), or a team that hates each other, or team members competing over who is the smartest, or too much team churn so that the vision or expertise gets lost. All those things usually cause a build up of bugs which in turn slows the pace of new development to a crawl. Eventually the person who is paying for the project decides to re-write the whole thing from scratch or scrap the project entirely.
It is possible that the 10+ year developer you have encountered just doesn't care about the small stuff because they understand that the higher level code structure and its testability is much more important. When you provide endless nitpick code reviews, rather than argue and tell you it's barely worth the 5 seconds it would take to fix it - they just fix it, because they are also aware that arguments about pointless things among team members are a genuine serious risk to the success of a project.
Again - I'm only speaking generally, possibly your 10 year dev would just rather be on their boat or on a beach somewhere ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A few years ago, I had been working in a company where I was working with a developer with 10+ years of experience. I never met that guy's face to face, but when I was doing a code review of his code, I often found things like that:
I tried to talk to him, but I did't find understanding between us, but he had been correcting all the remarks about his code, so I just had been checking his code more thoroughly than code of other team members.
Although probably a violation of the YAGNI principle, this is an entirely valid way to structure this code with an eye for future maintenance. Perhaps the dev who wrote this has done the refactor from
return isSomethingTrue();to this structure so many times -- to add logic to one or both branches -- that they now default to the latter. And they expect that in the average case it will save time.I don't do this thing in particular, but I will sometimes opt to do longer-form ways of structuring things when they are more amenable to maintenance in the future.
Oh man, this is everywhere.
Shit regular happened, but fortunately, there are companies where code quality is still very important.
Of course the code quality can be sacrificed for the sake of performance, but I had to do it only once in my life when I had to optimize the algorithm from 120 processor clock signal to 10.
Obviously I don't know about the specifics of the senior dev you're talking about, but sometimes junior and mid level developers can spend too much time sweating the unimportant stuff (when viewed from a senior developer perspective).
So for someone who is in the first few years of development (or someone who has OCD), coding is hard enough without also having to deal with brackets in weird places, inconsistent spacing and code like the sample you just posted. I get that, and I think it's something that senior devs should probably consider more.
The thing is, most senior devs will know that development wise that kind of stuff is never what kills a project, what kills a project is things like: sloppy architectures (or no architecture, or 3 architectures in the same app and no communication about which one should be followed), or a lack of tests (or too many pointless tests), or a team that hates each other, or team members competing over who is the smartest, or too much team churn so that the vision or expertise gets lost. All those things usually cause a build up of bugs which in turn slows the pace of new development to a crawl. Eventually the person who is paying for the project decides to re-write the whole thing from scratch or scrap the project entirely.
It is possible that the 10+ year developer you have encountered just doesn't care about the small stuff because they understand that the higher level code structure and its testability is much more important. When you provide endless nitpick code reviews, rather than argue and tell you it's barely worth the 5 seconds it would take to fix it - they just fix it, because they are also aware that arguments about pointless things among team members are a genuine serious risk to the success of a project.
Again - I'm only speaking generally, possibly your 10 year dev would just rather be on their boat or on a beach somewhere ;)