6 ms·

> In fact the majority of your argument isn't even focused on the discussion of an ORM but on a situation you made up. No, the vast majority was explaining how

> In fact the majority of your argument isn't even focused on the discussion of an ORM but on a situation you made up. No, the vast majority was explaining how development best practices resolve the common use case that is being presented here for why ORMs are a good thing (namely “my junior devs are somehow too stupid to learn SQL”). > That said, let's address your frankly odd rebuttal... What’s odd is that you think setting up guardrails to prevent human error and then empowering your developers to write good code is itself odd. > In the end it's all about all the forms of cost, which is exactly what my initial post said and you seem to have glossed over. I covered that point with my anecdote, where I talked about the improvements that best practices bring. > Using an ORM isn't free for every use case, but in many use cases it's cheaper than training up people, especially when this isn't a regular part of their job. Perhaps you're assuming a job where everyone is constantly working on DB interactions but a lot of gigs have stuff like this as a small part of the job. It doesn’t cost any extra to train people up using the development practices I’ve outlined. Training just becomes a side effect of day to day reviews. However ORMs have a very real performance cost that will have an ongoing bottom line in your infrastructure performance and hosting costs. One is a free win/win scenario and the other is a lazy hack that adds costs. > If they were only doing db interactions, then obviously the cost calculation changes. You’re underestimating your juniors ability to learn. Or you happen to work in some really toxic environments (which might explain your other view points). But you don’t need to clock up 40 hours a week on SQL to become competent enough to write most queries. Remember we are not talking about making them DBAs, just then being competent enough to be at least as good as your average ORM (which, frankly, isn’t hard). > I'm also not talking about cost in monetary terms. I'm talking about cost in terms of time, effort, financials, planning etc... I’ve been factoring all of them in as well. I’m a cost centre owner and people manager and so I’m well versed in how to equate costs correctly. I’ve had to do exactly these kinds of studies professionally. > I'm not sure why you suddenly suggest I wouldn't be using git branches or CI to try and make your point? Because you make the argument that getting juniors to write SQL will lead to footguns and I’m explaining how you manage that correctly. > Again, those have a better cost to benefit ratio. Every single decision is down to that.when picking a project. No, those practices should be default for any all commercial projects. If you’re knocking up a POC or building something for a hobby then feel free to do it however you want (within reason). But anything built as part of an internal system or external product, and especially if it needs to be maintained for any duration of time, they should all be developed using the principles I’ve described.

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 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. :)