6 ms·

Craft and expertise are worth a lot, but so are the facts of computer science and so are people wanting to debate and try new things some mistakes repeat (and c

by kodoman 17d ago

Craft and expertise are worth a lot, but so are the facts of computer science and so are people wanting to debate and try new things some mistakes repeat (and computing seems to repeat it's self so many times.), But those zoomers might have the theory fresher in their minds and they might have studied something you have not or did not know. If what you learned in university was plain wrong that does not sound good because computer science has eternal truths to it, If an architect said everything he learned in university was wrong I would be very worried and not trust his judgement because he should have learned facts not just theories of practice. If he only learned theories of practice I would be worried, if he learned both theories of practice and science and starts to disagree with the science I would be worried.

fjcururuvy7 17d ago
Or maybe UML, separation of concerns, DRY and other clean code euphemisms just aren't all they're cracked up to be. The problem is a lot of the science might be correct but that doesn't make it pragmatic and more often than not, it's just counter productive.
- kodoman 17d ago
  Agreed UML is something I have never used or wanted to use. Z and all that stuff as well. DRY and clean code is clearly in the box of theory of practice to me and that stuff is not computer science but is the practical advice, rules of thumbs and heuristics that get developed. What is problematic is the worship of these theories of practice and their is many points where they break down and knowing when they don't apply or why their not entirely correct here is golden and fuzzy and ineffable or at least unteachable. But the things that are in a computer science course. Type theory, compatibility, time/space complexities, more general algorithmic analysis, Logical programming, logical inference algorithms, Low level fundamentals, Mathematical concepts and proofs, machine learning, different models of programming, combinatorics algorithms. These are very useful many unchanging. I must concede that I do hold in low esteem theories of practice that are taught as a panacea but this is a tiny fraction of what a student will learn and likely any one learning the craft will simply pick this up from tutorials or youtube. It's not as if they are always bad rules of thumb either but that they can be done away with or violated once one knows what they are doing and has understood a bit more and got a feel for things.
  - fjcururuvy7 17d ago
    I think the problem is that software engineering isn't computer science. Other than practicing some leet code in between jobs, it's extremely rare any of that stuff comes up. The hard parts in my job isn't and hasn't been the computer science parts in a long time, or at least when it does come up it's not something I really think about much. The trade offs are almost always domain, business or product based. The technical solutions are just down stream of those constraints.

by kodoman 17d ago

fjcururuvy7 17d ago

Or maybe UML, separation of concerns, DRY and other clean code euphemisms just aren't all they're cracked up to be. The problem is a lot of the science might be correct but that doesn't make it pragmatic and more often than not, it's just counter productive.

kodoman 17d ago
Agreed UML is something I have never used or wanted to use. Z and all that stuff as well. DRY and clean code is clearly in the box of theory of practice to me and that stuff is not computer science but is the practical advice, rules of thumbs and heuristics that get developed. What is problematic is the worship of these theories of practice and their is many points where they break down and knowing when they don't apply or why their not entirely correct here is golden and fuzzy and ineffable or at least unteachable. But the things that are in a computer science course. Type theory, compatibility, time/space complexities, more general algorithmic analysis, Logical programming, logical inference algorithms, Low level fundamentals, Mathematical concepts and proofs, machine learning, different models of programming, combinatorics algorithms. These are very useful many unchanging. I must concede that I do hold in low esteem theories of practice that are taught as a panacea but this is a tiny fraction of what a student will learn and likely any one learning the craft will simply pick this up from tutorials or youtube. It's not as if they are always bad rules of thumb either but that they can be done away with or violated once one knows what they are doing and has understood a bit more and got a feel for things.
- fjcururuvy7 17d ago
  I think the problem is that software engineering isn't computer science. Other than practicing some leet code in between jobs, it's extremely rare any of that stuff comes up. The hard parts in my job isn't and hasn't been the computer science parts in a long time, or at least when it does come up it's not something I really think about much. The trade offs are almost always domain, business or product based. The technical solutions are just down stream of those constraints.