Generally, academia is governed by very different rules. Groups that can apply meticulous arch principles will do it. Others will just focus on speed because that is the aim of the research. It is very difficult to put everyone in academia or judge everyone by the same rules. And also depends absolutely on the desire and coding style, of the developer.
In my case, I am the sole developer of the whole project. I am my own project manager, the daily developer, the beta testers, the bug corrector, one-man-team. So it is up to me to find the equilibria between dedicating a lot to arch or not. Usually, I am paranoid and won't rest until I have perfect architectures I can come up with. Obviously, that has a cost. Actually, I rarely care about making quick prototypes because we already know it will work; it has been demonstrated mathematically at some point in the past. Hence, I focus, from scratch, on the best arch I can achieve. Anyway, suppose I fail in the design. In that case, my programs will rapidly run into a dead end because projects continuously require new additions to the software. Weekly! So, I have become quite paranoid with design, which inevitably collides with performance. And back-and-forth.
Altogether, I am not a computer scientist. I am a biochemist who self-taught programming by passion. Which sometimes makes things more difficult because I feel without references and lacking some hardcore concepts on how computers work, or references regarding culture-known assay comparing implementations or strategies.
Also, I have no bias. Which sometimes slows down development; other times it is a benefit. For example, some people are all-in to OOP. OOP everywhere. Others are FP-everywhere (these are very rare). Everyone has a bias. Having a bias has the positive aspect that you won't lose time looking for answers. You will just apply your hammer everywhere. The counter effect is that biases become short some times. However, if one does not have a bias, one might get lost some times trying to find the best hammer for the task, ending up testing all hammers before the actual implementation takes place. I am in this second situation most of the time. :-) Which I like, actually.
Regarding pragmatism, I am a Python dev. And Python quite embraces every paradigm. So I am balancing my code know mixing OOP with FP in the best pragmatic manner I can.
That is, it's not "I can't", rather it's "I don't want to".
I believe that when one has the concepts really plugged in (really learned) into one's behavior than there is no "I don't want to". It will become the only way you know how to code. In my case, it took me quite some time to understand some strategies, but once I got them deep into my mind, then, I could not use the outdated ones again; they won't simply reach my fingertips.
Good talk!!
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.
Generally, academia is governed by very different rules. Groups that can apply meticulous arch principles will do it. Others will just focus on speed because that is the aim of the research. It is very difficult to put everyone in academia or judge everyone by the same rules. And also depends absolutely on the desire and coding style, of the developer.
In my case, I am the sole developer of the whole project. I am my own project manager, the daily developer, the beta testers, the bug corrector, one-man-team. So it is up to me to find the equilibria between dedicating a lot to arch or not. Usually, I am paranoid and won't rest until I have perfect architectures I can come up with. Obviously, that has a cost. Actually, I rarely care about making quick prototypes because we already know it will work; it has been demonstrated mathematically at some point in the past. Hence, I focus, from scratch, on the best arch I can achieve. Anyway, suppose I fail in the design. In that case, my programs will rapidly run into a dead end because projects continuously require new additions to the software. Weekly! So, I have become quite paranoid with design, which inevitably collides with performance. And back-and-forth.
Altogether, I am not a computer scientist. I am a biochemist who self-taught programming by passion. Which sometimes makes things more difficult because I feel without references and lacking some hardcore concepts on how computers work, or references regarding culture-known assay comparing implementations or strategies.
Also, I have no bias. Which sometimes slows down development; other times it is a benefit. For example, some people are all-in to OOP. OOP everywhere. Others are FP-everywhere (these are very rare). Everyone has a bias. Having a bias has the positive aspect that you won't lose time looking for answers. You will just apply your hammer everywhere. The counter effect is that biases become short some times. However, if one does not have a bias, one might get lost some times trying to find the best hammer for the task, ending up testing all hammers before the actual implementation takes place. I am in this second situation most of the time. :-) Which I like, actually.
Regarding pragmatism, I am a Python dev. And Python quite embraces every paradigm. So I am balancing my code know mixing OOP with FP in the best pragmatic manner I can.
I believe that when one has the concepts really plugged in (really learned) into one's behavior than there is no "I don't want to". It will become the only way you know how to code. In my case, it took me quite some time to understand some strategies, but once I got them deep into my mind, then, I could not use the outdated ones again; they won't simply reach my fingertips.
Good talk!!