5 ms·

Early in my career, I noticed a mindset among senior developers disparaging ORM's with "I'll write my own SQL, thanks." Although I noted their thoughts at the t

Early in my career, I noticed a mindset among senior developers disparaging ORM's with "I'll write my own SQL, thanks." Although I noted their thoughts at the time, I didn't really do anything with it - there was a mountain of other things to learn and using an ORM made me productive enough to get tasks done. Of course, years later when I finally dug into SQL and interacting directly with databases, I had a much better understanding of their mindset and wish I would have learned earlier. Now your mindset feels very similar to me - "I'll write my own shell scripts, thanks." So, to avoid making the same mistake twice, do you have any advice for what to read / learn to better understand your position? Note: I've written plenty of shell, but the shell I've writen is way to hacky to use as a replacement for ansible.

jlgaddis 6y ago
> ... but the shell I've writen is way to hacky to use as a replacement for ansible. You obviously haven't looked at the code for some of the Ansible modules!
- webknjaz 6y ago
  Is that about the community supported stuff that got moved out because nobody maintained it?
strzibny 6y ago
Shell is not the best solution long-term for a largish organization, but if you are indie hacking a simple app it's actually a viable option. That's also why I chose Bash to teach config management and deployment[0]. Do it in Bash, understand it fully. Then go a pick up a tool of your liking. Or not, if it actually does it job. [0] https://deploymentfromscratch.com/ https://deploymentfromscratch.com/
mekoka 6y ago
> Early in my career, I noticed a mindset among senior developers disparaging ORM's with "I'll write my own SQL, thanks." Hopefully they were justified in their choice. Most senior developers I've worked with who started with this mindset, be it about an ORM, a framework, or some library that they did not understand or wanted to spend some time to learn, ended up just proving that these abstractions were not completely useless after all. How? By recreating their own vastly inferior and headache inducing implementations. I believe that there's an additional layer of skills between seniority and mastery. The former seems to be just about time and experience, whereas the latter adds a dimension of pragmatism and detachment. You become just a craftsman using tools with indifference to nimbly navigate complexity. You don't blame your tools, you just understand them, strengths and weaknesses. You know when to leverage them and when to ditch them.
- harrygeez 6y ago
  I find that with ORMs you'll inevitably run into some kind of corner cases that is not covered, migration issues, library or framework incompatibility. Some argue for query builders but if you're doing that you might as well just write SQL.
chousuke 6y ago
I think using Ansible is not by itself a problem. There are many things I don't like about Ansible and I don't think it's particularly robust, but it is an improvement over manually written scripts, most of the time, because writing robust scripts is not easy. What I think "senior developers" are usually disparaging is using tools like ORMs without appropriate understanding of how they work, and thus being unable to recognize when they don't suit the task at hand.
deleted 6y ago
[deleted]

jlgaddis 6y ago

> ... but the shell I've writen is way to hacky to use as a replacement for ansible. You obviously haven't looked at the code for some of the Ansible modules!

webknjaz 6y ago
Is that about the community supported stuff that got moved out because nobody maintained it?

strzibny 6y ago

Shell is not the best solution long-term for a largish organization, but if you are indie hacking a simple app it's actually a viable option. That's also why I chose Bash to teach config management and deployment[0]. Do it in Bash, understand it fully. Then go a pick up a tool of your liking. Or not, if it actually does it job. [0] https://deploymentfromscratch.com/ https://deploymentfromscratch.com/

mekoka 6y ago

> Early in my career, I noticed a mindset among senior developers disparaging ORM's with "I'll write my own SQL, thanks." Hopefully they were justified in their choice. Most senior developers I've worked with who started with this mindset, be it about an ORM, a framework, or some library that they did not understand or wanted to spend some time to learn, ended up just proving that these abstractions were not completely useless after all. How? By recreating their own vastly inferior and headache inducing implementations. I believe that there's an additional layer of skills between seniority and mastery. The former seems to be just about time and experience, whereas the latter adds a dimension of pragmatism and detachment. You become just a craftsman using tools with indifference to nimbly navigate complexity. You don't blame your tools, you just understand them, strengths and weaknesses. You know when to leverage them and when to ditch them.

harrygeez 6y ago
I find that with ORMs you'll inevitably run into some kind of corner cases that is not covered, migration issues, library or framework incompatibility. Some argue for query builders but if you're doing that you might as well just write SQL.

chousuke 6y ago

I think using Ansible is not by itself a problem. There are many things I don't like about Ansible and I don't think it's particularly robust, but it is an improvement over manually written scripts, most of the time, because writing robust scripts is not easy. What I think "senior developers" are usually disparaging is using tools like ORMs without appropriate understanding of how they work, and thus being unable to recognize when they don't suit the task at hand.

deleted 6y ago

[deleted]