3 ms·

Nowhere in any of my posts did I say juniors are too stupid to learn. Much like your previous comment, you are filling in your own blanks. Every thing has an a

by dagmx 5y ago

Nowhere in any of my posts did I say juniors are too stupid to learn. Much like your previous comment, you are filling in your own blanks. Every thing has an associated cost. An ORM in a familiar language, like sqlalchemy in Python, is easier to learn than learning SQL from scratch, and it provides guardrails like schema enforcement that SQL does not. That means anyone, not just a junior, can drop into a codebase using it and be able to quickly use it You seem to be under the impression that an ORM has to have a significant performance penalty. While there's of course going to be some, for the vast majority of tasks that I use it for, it is negligible versus the rest of the IO happening. If there is a significant penalty in some edge cases, I can still use direct SQL queries. Again, like my original post, I know when and where to use an ORM and as I've tried to explain to you multiple times, I know it's not a silver bullet solution. In your previous comment you simply went off the rails talking about branching and CI without tying it into your argument. If your argument is that CI will catch the issues, CI can only catch some issues. It too isn't a silver bullet, and relies on code review to catch some other issues. Why not just use an ORM to add that security up front? It doesn't replace CI or code review, but it greatly reduces the risk of each stage failing. > they should all be developed using the principles I’ve described Okay, you do you. You've dissalowed any reply of situational pragmatism for your own fastidious absolutism.

laumars 5y ago
> Nowhere in any of my posts did I say juniors are too stupid to learn. Much like your previous comment, you are filling in your own blanks. Easy conclusion to make when every post is full of reasons why juniors can’t learn SQL ;) > is easier to learn than learning SQL from scratch, I very much doubt many juniors are learning SQL front scratch. They’d have learned some already at college. And if they don’t genuinely don’t have any experience with databases what do ever then you bloody well need to skill them up irrespective of whether they use an ORM. So again, your argument here has no teeth. > In your previous comment you simply went off the rails talking about branching and CI without tying it into your argument. I’ve explained how that ties in several times now. There’s a difference between you not understanding best practices and me not explaining them > If your argument is that CI will catch the issues, CI can only catch some issues. It too isn't a silver bullet, I agree > and relies on code review to catch some other issues. Not just code review, automated tests, vets and so forth too. But I also agree that code review is a key part. > Why not just use an ORM to add that security up front? Because ORMs aren’t a silver bullet either. Except you’re trading in due diligence with lazy abstractions that add runtime overhead. > It doesn't replace CI or code review, but it greatly reduces the risk of each stage failing. It doesn’t reduce the risk of it failing. It reduces the ability for code to be vetted. It adds overhead and runtime costs. It adds complexity and the only benefit is you can keep your juniors blissfully in the dark about how your database works. That strikes me as a stupid compromise. > Okay, you do you. You've dissalowed any reply of situational pragmatism for your own fastidious absolutism. I’m not being absolute. I’ve said POCs and hobbies can bypass these best practises. And I’m being pragmatic when I say that every organisation I’ve worked at, both as an engineer and as a leader, has benefited from these best practices. Hence why they’re called “best practices” rather than “pointless processes”. Every organisation I’ve worked at where I’ve seen teams bypassing these best practices have been dysfunctional. That might work for you but it results in shit code — which is likely why you’re dependent on ORMs to fix things for you. And I urge you to read more on this typic rather than just taking my word for it. :)
- dagmx 5y ago
  Nowhere have I said juniors can't learn SQL either. This is such a pointless argument anyway. You aren't bothering to read what I'm writing, you're twisting what I'm saying in what little you do read by filling in your own blanks, and you're insinuating that I won't use other best practices just because I won't agree with your subjective definition of best practices. I have read many arguments about this, and again, I am experienced enough to know when to use it. The issue here is you have a completely condescending view of anyone who's not sharing your exact view. Your posts repeatedly insinuate that your experience outweighs my own, without actually providing anything other than YOU think ORMs are bad. Not every college teaches SQL, not every junior comes from the same technical background, and you're assuming a lot more about someone else's workplace than you have any basis to. You're also kind of a jerk by further insinuating that I put up with shit code. Perhaps I just don't put up with shit personalities who have a chip on their shoulders.
  - laumars 5y ago
    > Nowhere have I said juniors can't learn SQL either Then why invest so much effort trying to convince me that they shouldn’t learn SQL or that ORMs are better than learning how the underlying database manages their relational data? ;) If I come across arrogant it’s because I’ve spent meany years managing fixing a great many failing dev teams and the comments you’re making resonate heavily with those who are usually against the changes I make. They always come round to agreeing that those changes are for the better after living with them for a few months. But I guess we’ll never prove that on a message board so I’m happy to agree to disagree for the sake of etiquette.

by dagmx 5y ago

laumars 5y ago

> Nowhere in any of my posts did I say juniors are too stupid to learn. Much like your previous comment, you are filling in your own blanks. Easy conclusion to make when every post is full of reasons why juniors can’t learn SQL ;) > is easier to learn than learning SQL from scratch, I very much doubt many juniors are learning SQL front scratch. They’d have learned some already at college. And if they don’t genuinely don’t have any experience with databases what do ever then you bloody well need to skill them up irrespective of whether they use an ORM. So again, your argument here has no teeth. > In your previous comment you simply went off the rails talking about branching and CI without tying it into your argument. I’ve explained how that ties in several times now. There’s a difference between you not understanding best practices and me not explaining them > If your argument is that CI will catch the issues, CI can only catch some issues. It too isn't a silver bullet, I agree > and relies on code review to catch some other issues. Not just code review, automated tests, vets and so forth too. But I also agree that code review is a key part. > Why not just use an ORM to add that security up front? Because ORMs aren’t a silver bullet either. Except you’re trading in due diligence with lazy abstractions that add runtime overhead. > It doesn't replace CI or code review, but it greatly reduces the risk of each stage failing. It doesn’t reduce the risk of it failing. It reduces the ability for code to be vetted. It adds overhead and runtime costs. It adds complexity and the only benefit is you can keep your juniors blissfully in the dark about how your database works. That strikes me as a stupid compromise. > Okay, you do you. You've dissalowed any reply of situational pragmatism for your own fastidious absolutism. I’m not being absolute. I’ve said POCs and hobbies can bypass these best practises. And I’m being pragmatic when I say that every organisation I’ve worked at, both as an engineer and as a leader, has benefited from these best practices. Hence why they’re called “best practices” rather than “pointless processes”. Every organisation I’ve worked at where I’ve seen teams bypassing these best practices have been dysfunctional. That might work for you but it results in shit code — which is likely why you’re dependent on ORMs to fix things for you. And I urge you to read more on this typic rather than just taking my word for it. :)

dagmx 5y ago
Nowhere have I said juniors can't learn SQL either. This is such a pointless argument anyway. You aren't bothering to read what I'm writing, you're twisting what I'm saying in what little you do read by filling in your own blanks, and you're insinuating that I won't use other best practices just because I won't agree with your subjective definition of best practices. I have read many arguments about this, and again, I am experienced enough to know when to use it. The issue here is you have a completely condescending view of anyone who's not sharing your exact view. Your posts repeatedly insinuate that your experience outweighs my own, without actually providing anything other than YOU think ORMs are bad. Not every college teaches SQL, not every junior comes from the same technical background, and you're assuming a lot more about someone else's workplace than you have any basis to. You're also kind of a jerk by further insinuating that I put up with shit code. Perhaps I just don't put up with shit personalities who have a chip on their shoulders.
- laumars 5y ago
  > Nowhere have I said juniors can't learn SQL either Then why invest so much effort trying to convince me that they shouldn’t learn SQL or that ORMs are better than learning how the underlying database manages their relational data? ;) If I come across arrogant it’s because I’ve spent meany years managing fixing a great many failing dev teams and the comments you’re making resonate heavily with those who are usually against the changes I make. They always come round to agreeing that those changes are for the better after living with them for a few months. But I guess we’ll never prove that on a message board so I’m happy to agree to disagree for the sake of etiquette.