> Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers
This is indeed so, most people are developers/programmers rather than software engineers. As a discipline, writing/crafting code still lacks the systematic approach
of other engineering disciplines.
If I ask for a house to be built for me, people give me a plan as well as cost & time estimates, as part of a pretty standardized process. For sofware, there is much of a zig-zag route towards a foggy end goal in many projects.
That's why I'm working on a methodology to make things more systematic (there are of course many people working on methodology, some heavy like UML, some rather light/"agile", my focus is on methodology for data-intensive systems - systems that require machine learning components, which imposes a rather special list of process requirements on the project, for which nobody appears to have written up detailed guidelines/best practices, so that's ongoing).
> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.
I've interviewed a few hundred people in recent years, and been interviewed a few times myself. I agree most people use a broken process. My idea for making it better is:
(a) cover a range of areas: motivation/goals - interpersonal - project experience - management - algorithms & data structures - coding practice. No silly logical riddles, but examples that are common in the daily life. So in case they really have been doing what their CV says, they should not need to have to practice for any of it.
> Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers
This is indeed so, most people are developers/programmers rather than software engineers. As a discipline, writing/crafting code still lacks the systematic approach of other engineering disciplines.
If I ask for a house to be built for me, people give me a plan as well as cost & time estimates, as part of a pretty standardized process. For sofware, there is much of a zig-zag route towards a foggy end goal in many projects.
That's why I'm working on a methodology to make things more systematic (there are of course many people working on methodology, some heavy like UML, some rather light/"agile", my focus is on methodology for data-intensive systems - systems that require machine learning components, which imposes a rather special list of process requirements on the project, for which nobody appears to have written up detailed guidelines/best practices, so that's ongoing).
> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.
I've interviewed a few hundred people in recent years, and been interviewed a few times myself. I agree most people use a broken process. My idea for making it better is: (a) cover a range of areas: motivation/goals - interpersonal - project experience - management - algorithms & data structures - coding practice. No silly logical riddles, but examples that are common in the daily life. So in case they really have been doing what their CV says, they should not need to have to practice for any of it.