6 ms·

> The software engineers' body of knowledge can change 52 times in a year Nah, those changes are only in the surface, at the most shallow level. There's alway

by whstl 10mo ago

> The software engineers' body of knowledge can change 52 times in a year Nah, those changes are only in the surface, at the most shallow level. There's always new techniques, materials and tools in structural engineering as well. Foundations take a lifetime to change.

kayo_20211030 10mo ago
Respectfully, I disagree. You're correct on the facts, but any "new techniques, materials and tools" need to be communicated to the brick layers. That takes time and effort i.e. it all needs to be actively managed. The brick layers have to be able to work with those new techniques and materials. I don't want some of them using method #1 over here, and method #2 over there, unless I'm wholly conversant with the methods, and fully confident that it'll all mesh eventually. The system i.e. the whole shebang has to work coherently to serve its purpose.
- whstl 10mo ago
  > Respectfully, I disagree. You're correct on the facts, but I'm fine with the disagreement if you say I'm correct. ¯\_(ツ)_/¯ > any "new techniques, materials and tools" need to be communicated to the brick layers Same for software. > That takes time and effort i.e. it all needs to be actively managed. The brick layers have to be able to work with those new techniques and materials. Same for software. > I don't want some of them using method #1 over here, and method #2 over there, unless I'm wholly conversant with the methods, and fully confident that it'll all mesh eventually. The system i.e. the whole shebang has to work coherently to serve its purpose. Same for software. Virtually every profession has a body of knowledge that's constantly getting updated. Only software engineers seem to have this faulty assumption that they must apply it all immediately. Acknowledging it's a false assumption leads to a better life.
  - kayo_20211030 10mo ago
    Then we're in violent agreement. The challenge would be to control the pace of the evolution of the body of knowledge, but more importantly, its application, to a pace that's consistent with the pace of the system you're building. > faulty assumption that they must apply it all immediately No truer word was ever said. Everyone is attracted to shiny things.
    - whstl 10mo ago
      Ah nice, then yes, we agree!
RaftPeople 10mo ago
> Nah, those changes are only in the surface, at the most shallow level. Very strongly disagree. There are limitless methods of solving problems with software (due to very few physical constraints) and there are an enormous number of different measures of whether it's "good" or "bad". It's both the blessing and curse of software.
- whstl 10mo ago
  Once again, that's only true at the surface level. If you dig deeper you'll realize that it's possible to categorize techniques, tools, libraries, algorithms, recipes, whatever. And if you dig even deeper, you'll realize that there is foundational knowledge that lets you understand a lot of things that people complain about being too new. The biggest curse of software is people saying "no" to education and knowledge.
  - RaftPeople 10mo ago
    > Once again, that's only true at the surface level. Can you provide concrete examples of the things that you think are foundational in software? I'm thinking beyond "be organized so it's easier for someone to understand", which applies to just about everything we do (e.g. modularity, naming, etc.) For every different approach like OOP, functional, relation DB, object DB, enterprise service bus + canonical documents, microservices, cloud, on prem, etc. etc., they are just options with pros and cons. With each approach the set of trade-offs is dependent on the context that the approach is applied into, it's not an absolute set of trade-offs, it's relative. A critical skill that takes a long time to develop is to see the problem space and do a reasonably good job of identifying how the different approaches fit in with the systems and organizational context. Here's a real example: A project required a bunch of new configuration capabilities to be added to a couple systems using the normal configuration approach found in ERP systems (e.g. flags and codes attached to entities in the system controlling functional flow and data resolution, etc.). But for some of them a more flexible "if then" type capability made sense when analyzing the types of situations the business would encounter in these areas. For these areas, the naive/simple approach would have been possible but would have been fragile and difficult to explain to the business how to get the different configurations in different places to come together to produce the desired result. There is no simple rule you can train someone on to spot when this is the right approach and when it is not. It's heavily dependent on the business context and takes experience.

by whstl 10mo ago

kayo_20211030 10mo ago

Respectfully, I disagree. You're correct on the facts, but any "new techniques, materials and tools" need to be communicated to the brick layers. That takes time and effort i.e. it all needs to be actively managed. The brick layers have to be able to work with those new techniques and materials. I don't want some of them using method #1 over here, and method #2 over there, unless I'm wholly conversant with the methods, and fully confident that it'll all mesh eventually. The system i.e. the whole shebang has to work coherently to serve its purpose.

whstl 10mo ago
> Respectfully, I disagree. You're correct on the facts, but I'm fine with the disagreement if you say I'm correct. ¯\_(ツ)_/¯ > any "new techniques, materials and tools" need to be communicated to the brick layers Same for software. > That takes time and effort i.e. it all needs to be actively managed. The brick layers have to be able to work with those new techniques and materials. Same for software. > I don't want some of them using method #1 over here, and method #2 over there, unless I'm wholly conversant with the methods, and fully confident that it'll all mesh eventually. The system i.e. the whole shebang has to work coherently to serve its purpose. Same for software. Virtually every profession has a body of knowledge that's constantly getting updated. Only software engineers seem to have this faulty assumption that they must apply it all immediately. Acknowledging it's a false assumption leads to a better life.
- kayo_20211030 10mo ago
  Then we're in violent agreement. The challenge would be to control the pace of the evolution of the body of knowledge, but more importantly, its application, to a pace that's consistent with the pace of the system you're building. > faulty assumption that they must apply it all immediately No truer word was ever said. Everyone is attracted to shiny things.
  - whstl 10mo ago
    Ah nice, then yes, we agree!

RaftPeople 10mo ago

> Nah, those changes are only in the surface, at the most shallow level. Very strongly disagree. There are limitless methods of solving problems with software (due to very few physical constraints) and there are an enormous number of different measures of whether it's "good" or "bad". It's both the blessing and curse of software.

whstl 10mo ago
Once again, that's only true at the surface level. If you dig deeper you'll realize that it's possible to categorize techniques, tools, libraries, algorithms, recipes, whatever. And if you dig even deeper, you'll realize that there is foundational knowledge that lets you understand a lot of things that people complain about being too new. The biggest curse of software is people saying "no" to education and knowledge.
- RaftPeople 10mo ago
  > Once again, that's only true at the surface level. Can you provide concrete examples of the things that you think are foundational in software? I'm thinking beyond "be organized so it's easier for someone to understand", which applies to just about everything we do (e.g. modularity, naming, etc.) For every different approach like OOP, functional, relation DB, object DB, enterprise service bus + canonical documents, microservices, cloud, on prem, etc. etc., they are just options with pros and cons. With each approach the set of trade-offs is dependent on the context that the approach is applied into, it's not an absolute set of trade-offs, it's relative. A critical skill that takes a long time to develop is to see the problem space and do a reasonably good job of identifying how the different approaches fit in with the systems and organizational context. Here's a real example: A project required a bunch of new configuration capabilities to be added to a couple systems using the normal configuration approach found in ERP systems (e.g. flags and codes attached to entities in the system controlling functional flow and data resolution, etc.). But for some of them a more flexible "if then" type capability made sense when analyzing the types of situations the business would encounter in these areas. For these areas, the naive/simple approach would have been possible but would have been fragile and difficult to explain to the business how to get the different configurations in different places to come together to produce the desired result. There is no simple rule you can train someone on to spot when this is the right approach and when it is not. It's heavily dependent on the business context and takes experience.