Why it's wrong, because in the real world where you are paid by a company to write code or fix code to get the bottom line tightened, which solution you employ is tertiary so long as it can be done: a) under budget. b)under time ... everything after that is a free choice variable.
It's always been wrong.
2) Monolithic vs Services ...
Why it's wrong, because in the real world there are classes of problems that are best served using one architectural approach versus the other. This choice is weakly bounded by 1) above by the way.
It's been wrong since computers became powerful enough and distributed enough so that small units of redundant code could be executed in a per process function way as a solution option for various types of programming problems. Yes, services can answer a host of scalability under load conditions that were not optimally addressed by a non parallel / monolithic architectural approach but not all problems are amenable to that approach and often 1) gets in the way on implementing them.
3) Knowing patterns means knowing how to code...
Why it's wrong, some patterns are highly language specific ..which makes them paradigm specific which makes them not fully generalizable. Even within a given language and paradigm it's possible to code properly but not know a thing about what some one else calls the pattern you are applying to solve the problem. I call this the Good Will Hunting position...it's possible to be very adept at Engineering without being an acolyte to the gospel of subjective proselytizing of names given to the "ways of programming". Conversely it's possible to know all the names and not be able to identify where in your design you should be using them (that's where the art of programming comes in as well).
It's always been wrong.
4) waterfall vs agile vs ....etc.
Why it's wrong. Pretty much the same reasons described in 1) above. How you manage the building of code will be constrained by your problem scope, time and cost limitations. It additionally has the legacy code versus novel code constraint...I assure you that if Jeff Dean and Sanjay Ghemwat were doing daily stand-up's and filling out task cards and doing iteration planning meetings while they were inventing the MapReduce algorithm it would have obliterated their ability to actually innovate. Thus R&D code building is much better served by a non agile approach like waterfall.
It's always been wrong.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A whole bunch:
1) OO vs Functional vs Imperative vs ...etc.
Why it's wrong, because in the real world where you are paid by a company to write code or fix code to get the bottom line tightened, which solution you employ is tertiary so long as it can be done: a) under budget. b)under time ... everything after that is a free choice variable.
It's always been wrong.
2) Monolithic vs Services ...
Why it's wrong, because in the real world there are classes of problems that are best served using one architectural approach versus the other. This choice is weakly bounded by 1) above by the way.
It's been wrong since computers became powerful enough and distributed enough so that small units of redundant code could be executed in a per process function way as a solution option for various types of programming problems. Yes, services can answer a host of scalability under load conditions that were not optimally addressed by a non parallel / monolithic architectural approach but not all problems are amenable to that approach and often 1) gets in the way on implementing them.
3) Knowing patterns means knowing how to code...
Why it's wrong, some patterns are highly language specific ..which makes them paradigm specific which makes them not fully generalizable. Even within a given language and paradigm it's possible to code properly but not know a thing about what some one else calls the pattern you are applying to solve the problem. I call this the Good Will Hunting position...it's possible to be very adept at Engineering without being an acolyte to the gospel of subjective proselytizing of names given to the "ways of programming". Conversely it's possible to know all the names and not be able to identify where in your design you should be using them (that's where the art of programming comes in as well).
It's always been wrong.
4) waterfall vs agile vs ....etc.
Why it's wrong. Pretty much the same reasons described in 1) above. How you manage the building of code will be constrained by your problem scope, time and cost limitations. It additionally has the legacy code versus novel code constraint...I assure you that if Jeff Dean and Sanjay Ghemwat were doing daily stand-up's and filling out task cards and doing iteration planning meetings while they were inventing the MapReduce algorithm it would have obliterated their ability to actually innovate. Thus R&D code building is much better served by a non agile approach like waterfall.
It's always been wrong.