Hacker News Reader

Comment by Pasorrijer | Hacker News Reader

I think one reason for the negative comments (speaking as someone trained as a Systems Engineer, with 10+ years of experience and now working as a Consultant and performing Systems Engineering occasionally) is that the majority of the "Engineerings" choose to quantify anything fuzzy in a certain way, and then state that it doesn't matter. For example, the human factor. Whereas the reason Systems Engineering is so abstract and high level is the assumption that those unquantifiable factors have to be accounted for in "boxes and arrows", regardless of the fact that they can't be quantitatively engineered.... And many can't handle the fact that these things can't be quantitatively engineered [Edit to add the statement post ellipses]

View on HN

As a heavily 'left-brained' person with an engineering background, I've recently (in my middle age) started to appreciate those who pursue social sciences more. They were a group I used to look down on because of the lack of rigor in their work, but recently I have come to realize that the problem is that the atomic unit of their domain (a human mind) is orders of magnitude more complex than that atomic units of all my favorite disciplines (physics: forces, chemistry: actual atoms, programming: instructions). While people like myself dismiss the problem (read: run away from it), they at least possess the fortitude to attempt it, even while stumbling.

Personally, I still dismiss soft sciences a lot, despite having the same realization you have. Yes, the subject domain is much more complex than in physics or chemistry, which means it's much harder to apply any sort of rigor, and much harder to get an actual result. But that shouldn't be an excuse to stop trying! As the field gets more difficult - softer(!) - I'd expect the work to be done with much more care and at much slower rate. Instead, I see that the quality of work has been sacrificed. The replication crisis happened not because soft fields were difficult per se, but because the work done was sloppy. It is my impression that the soft fields don't respect the difficulty of their subject domains.

> which means it's much harder to apply any sort of rigor, and much harder to get an actual result. But that shouldn't be an excuse to stop trying!

By this comment, if you program, I sincerely hope you've never written a buggy line of code in your life. As well I expect you have fewer bugs per line of code as your programs get larger and more complex.

As well I'd expect your code experiences the opposite of "code rot" the more changing requirements you receive.

Of course I make bugs! But I strive to make less of them.

For instance, after I've reached programming maturity (i.e. the stage at which I'm not attached to a specific language, but are proficient in several, and can do basic work in any language you ask me to), I've learned to appreciate and make use of strong typing, precisely because it lets me add more (compiler-checked) rigor to my code. Even my Common Lisp code is as typed as the type system will allow me to (which is quite much). Programming this way is still difficult and fuzzy, but a little less fuzzy. Same with embracing certain styles and patterns of programming, that all help to narrow down the scope of things any piece of code could be doing at runtime.

I stand by my point: the more difficult your field is, the more care and rigor should be used in approaching it, if you care at all about making some kind of definitive statements about something that can survive the test of time.

>But that shouldn't be an excuse to stop trying!

I don't see much indication that people aren't trying.

The lack of rigor is pretty prevalent in life (legal systems, human communication, etc.) and it’s awesome because it adds a whole extra dimension of complexity that could not exist if things were rigorous.

For example, I can test whether my friend is sad about something without explicitly asking them and thus triggering them.

Or I try to see if someone is interested in me without explicitly asking and making it awkward for either of us.

Or a judge can choose to be more lenient to someone trespassing to save their dog.

It adds this huge “gray area” that can exist when things are wishy washy and it’s like the lubricant that smooths out unique situations that can’t possibly be covered in rigorous system.

Kind of the „common sense“ part, always prone to be hijacked by corruption

Do you think it makes sense to have formal training for Systems Engineering?

It relies a lot on experience, intuition, and dealing with uncertainty. The uncertainty makes it rather impossible to develop an intuition. To me that suggests that it should be learned rather as an apprentice where the master substitutes as a quicker feedback cycle compared to the real world where feedback comes back years later.

Only when we understand the field well enough that we know what the deliberate practice for training should be then it makes sense to turn it into a course.

That's an awesome question. I think that some aspect of systems thinking (such as defining requirements, or breaking complex problems down at a high level) should be included in all engineering disciplines, but I agree that it's definitely a field more suited to being something you transition to instead of starting in. Mostly just because of the volume of general knowledge required to understand the whole system

Reply on news.ycombinator.com