Responsibility stops me from building applications and services using obscure tools or writing my own tools. Because it'll be rewritten by later developers using commonly-used tools. There's certain expectations. You don't write your own logger library in Java, you're using logback or log4j (despite them being monstrosities). You don't write your own framework or use some obscure framework like Helidon. You use Spring Boot because everyone uses that. If you'll write your GUI application using Gtk, it's likely to be rewritten with Electron just after you leave the company and next developers will not be able to speak C because they just finished some JS bootcamp and just went into industry.
I can use assembly language for my own projects if I want. Nobody cares. But for code that I was hired to write, I'll use most appropriate approach and usually that's a most popular approach. Even if I'd love to just write some SQL, I'll bring Hibernate and meddle with its configurations because that's what everyone uses and knows (and hates) in Java. That'll produce maintainable software that won't get rewritten tomorrow because you used arcane tech nobody understands.
Using non-conventional approaches might be good for job security, though, I guess.
> Because it'll be rewritten by later developers using commonly-used tools.
Everything will eventually be rewritten so this isn't much of an argument... What's "common" today won't be that way forever, likely not even for a couple of years (which is the whole point).
There's no reason to use a particular tool because it's common. A proper developer uses the tool that is right. If that happens to be old, so be it. An engineer should be able to decide what to use based on merits of tools not just picking up the new shiny.
I can use assembly language for my own projects if I want. Nobody cares. But for code that I was hired to write, I'll use most appropriate approach and usually that's a most popular approach. Even if I'd love to just write some SQL, I'll bring Hibernate and meddle with its configurations because that's what everyone uses and knows (and hates) in Java. That'll produce maintainable software that won't get rewritten tomorrow because you used arcane tech nobody understands.
Using non-conventional approaches might be good for job security, though, I guess.