Unfortunately I have met this type a few times over the years. They prefer the over engineered solution that fits the textbook rather than be pragmatic and develop what suits the requirement. It never ends well. You will probably need to get yourself another programmer. This type are always right. Especially when they are not ;) In the end they will leave anyway.

What is your relationship to this programmer? Are you his manager, a peer, or a junior?

@Jane likewise; also they will likely insist on the one true language and toolset, regardless of its appropriateness for the business as a whole.

Read meta.programmers.stackexchange.com/questions/6629/…

Just wondering, how critical a business priority is it for you that your developers don't find maintaining your code miserable, and leave? (Note - this question doesn't mean I think your specific example indicates this.)

@JuliaHayward Oh, you worked with him too? :)

If you can't measure how his code is not meeting the business needs, you need better requirements. If he isn't meeting deadlines or performance targets, it shouldn't be a debate.

@StephanKolassa Technically his manager, but it's such a small company that I'm also his peer (as in, I do the same work as him, plus some extra admin/management stuff on top)

@Benubird: thanks - I'd suggest you edit your question and put this piece of information in. It would be helpful for answerers and may get drowned in the comments.

Some people consider ORM a antipatern. Normally I would side with the programmer and claim management has nothing to do with programming dissensions. However, in this case the programmer is writing provable bad code that does not meet business requirements like performance goals. This indicate we're just dealing with a bad programmer.

@Dorus that's the problem - he's a good programmer (i.e. competent), he just doesn't care about anything except programming.

"How can I convince him to reprioritize" - if you are his manager, you need to explain to him what his job is, and what it isn't. Then you need to hold him accountable.

@Benubird Then he isn't really a good programmer. My job as a programmer isn't writing great code, that's merely a part of my actual job, which is solving problems and adding value.

Isn't SQL injection a security problem, not just a 'bad pattern' problem? Unless his only issue with your solution is 'code prettyness', it sounds like he's just bad at explaining himself, which is something he should learn to do.

@Benubird: If he only cares about programming, he can do that at home.

@Zibbobz Just an example. As far as injection goes, the specific sql in this case did not require user input: it was just reporting aggregates over all the values in a table, so not a security issue - just the question of whether it gets written in the ORM or in raw sql.

@Benubird Fair enough. I know that type of SQL command. Still, if he's a junior programmer fresh out of college, he might not know that himself, and might just be thinking of it as 'this is going to be a security breach' without considering the context.

I have to point out that even though you think there's no user input with that SQL statement you cannot be sure that things don't change and you don't have some SQL injection later. I don't say you need the ORM, I just say you have to craft the query using the proper tools - for example you could use EntityFramework (example of an ORM) or you could use parameterized queries instead of concatenating strings - the latter two would both give you perfect control over emitted SQL query but concatenating strings can be prone to SQL injection. This could make both of you happy.

I think discussions about SQL injection are off-topic. You might be right that there is a different approach that is better, but I really did just include it as an example, I'm not concerned about that specific case so much as I am about his attitude towards development and understanding of business issus.

@Benubird Okay, then the real problem is that he doesn't want to take your presumably uncool hand-crafted query and rewrite it with a proper approach (but without ORM).

@benubird, why do you put up with it? find another programmer that understands pragmatism and send the dogmatic primadonna you currently have packing.

we don't have any fixed organizational standards or conflict resolution procedures. This is not a programming problem. Maybe you're both right or maybe one of you is wrong, but at the end of a day making decisions is a must, even if they're sometimes wrong.

From 4 hours to 30 seconds? Did I misread something? Is one or the other supposed to be "minutes", instead?

These disagreements sound like examples of both sides missing nuance. Whether performance is more or less important than clean code depends entirely on how performance-critical the section of code is. Causing the users noticeable delay to be able to write "nice" code is silly, but so is bearing the burden of bad code to shave microseconds off a web request. Similarly, if an ORM is causing performance problems, the question should be what caused that, can it reasonably and safely be avoided in future, and if not, what are the alternatives. Not "ORMs rule!" vs "ORMs suck!"

I think he might benefit from having a talk from an engineering perspective. In programming, a very basic part of the job is identifying what you need to optimize for in any particular project. Sometimes you know the system needs to be very robust and flexible, other times performance and storage space is key. You want him to focus more on the latter than he is now. Also, there is such a thing as over-engineering. Would he use a whole feature-full framework to build a single completely static page? The point being, sometimes using a whole ORM can be overkill too.

I would really strongly recommend asking a related question on Programmers.SE, if only to get a more exact description of how you should address this employee, assuming you want to help him beyond reminding him of his business obligations (If not then disregard).

From the programmer's POV: "I need an assurance that I will not be blamed when this goes wrong." Unless OP is giving this assurance in writing, he will not convince the programmer, regardless of any advantages the solution appears to have.

So it all boils down to whether the OP is confident enough of his solution to also take the blame if it turns out to introduce technical debt that needs a man-month to clear up a year later.