4 ms·

I love these technical topics because I can open up popcorn bag and read how people with statistical significance of 1 person experience throw their opinions an

by ozim 4y ago

I love these technical topics because I can open up popcorn bag and read how people with statistical significance of 1 person experience throw their opinions and claim they have it all figured out. In my 14-15 years of experience in software industry I learned that having framework helps mostly with that - having bunch of "know it alls" rounded up to use the same approach instead of having "I know better discussions". Where frameworks shine is specifically lowering amount of discussions on technical details that has no relevance to the business but has all kind of opinions from devs. Someone in the thread claims - if he is hired he has to learn framework - well I am hiring people with knowledge on framework we use, he might not have been looking for a job lately. I have not seen we hire c# or c or java dev - there is always framework in requirements. Just see how frontend devs ads look "react dev to hire"/"angular dev to hire" no one hires "someone who knows html and css", yes it is requirement to know these but you also have to know at least one framework.

bowsamic 4y ago
Why start your post with an "I love to see 1 sample anecdata" and then make a whole post doing the same thing?
berkes 4y ago
Architectural patterns and design patterns can just as well help against "bikeshedding". More than a framework. I avoided this topic in my article because it already is far too long :). But a framework such as Angular or Rails does three things here, all of which aren't really properties of the framework: 1. Dictate where to put files, and how to name stuff. 2. Dictate what architectural pattern you must use. Rails? MVC or GTFO. 3. Dictate what surrounding tech to use. RDBS, REST, template languages etc: you don't have a say, use them, or GTFO. First, I don't think this is good, not because I know better, but because use-cases demand different setups. Sometimes Event-sourcing is crucial to a domain. Sometimes message-bus, sometimes microservices, sometimes monolyth. It really depends. Having the freedom to choose the best constraints and trade-offs for a project is IMO a crucial skill for long-term success. But even if such bikeshedding is bad and "we use Rails for everything, from websites to bots to embedded software" is the proper thing. Nothing in those thre points come from a framework directly: 1. where to put what, how to name things? - ubiquitous language, a thesaurus a simple loader or even the language (rust "enforces" file naming conventions as a language). It's a good thing to have, but can be achieved without marrying to a framework with all its trade-offs. 2. What architecture to use? This should be the first thing. Maybe second is to then choose a framework that uses or allows this pattern. Not the other way around. So you'll need to do this anyway: frameworks or not. 3. Again, highly dependent on the use-case. The requirements should dictate the tech to be used, not the other way around. And the tech used then dictates whether a certain framework is feasible at all.

by ozim 4y ago

bowsamic 4y ago

Why start your post with an "I love to see 1 sample anecdata" and then make a whole post doing the same thing?

berkes 4y ago

Architectural patterns and design patterns can just as well help against "bikeshedding". More than a framework. I avoided this topic in my article because it already is far too long :). But a framework such as Angular or Rails does three things here, all of which aren't really properties of the framework: 1. Dictate where to put files, and how to name stuff. 2. Dictate what architectural pattern you must use. Rails? MVC or GTFO. 3. Dictate what surrounding tech to use. RDBS, REST, template languages etc: you don't have a say, use them, or GTFO. First, I don't think this is good, not because I know better, but because use-cases demand different setups. Sometimes Event-sourcing is crucial to a domain. Sometimes message-bus, sometimes microservices, sometimes monolyth. It really depends. Having the freedom to choose the best constraints and trade-offs for a project is IMO a crucial skill for long-term success. But even if such bikeshedding is bad and "we use Rails for everything, from websites to bots to embedded software" is the proper thing. Nothing in those thre points come from a framework directly: 1. where to put what, how to name things? - ubiquitous language, a thesaurus a simple loader or even the language (rust "enforces" file naming conventions as a language). It's a good thing to have, but can be achieved without marrying to a framework with all its trade-offs. 2. What architecture to use? This should be the first thing. Maybe second is to then choose a framework that uses or allows this pattern. Not the other way around. So you'll need to do this anyway: frameworks or not. 3. Again, highly dependent on the use-case. The requirements should dictate the tech to be used, not the other way around. And the tech used then dictates whether a certain framework is feasible at all.