[crimsonalucard]

Software engineering is easy. Most people are familiar with it as an aspect of canned design principles to ensure safety and scalability. You can read about it all in books or internet articles and come up with it on your own.

Have unit testing, have integration testing... make it modular... SOLID, write layers, yada yada yada also very easy.

I always hear people say that Computer science != software engineering but really it's the same thing at the upper echelons. Rather than using your gut and all these anecdotal "principles" spewed out by people like Martin Fowler, design pattern books, or books on testing and agile you can actually use theory and science to guide your software engineering decisions.

Let's put it this way. Software engineering is the only engineering discipline where people can get away with not knowing science and mathematics and still build systems that can run. The effective and elite software engineer lets theory and science guide his decisions as well to make systems that are better.

I do agree with you that fizzbuzz is missing something.

[AnimalMuppet]

This is so over-the-top that I can't tell if it's parody, trolling, or just horribly mistaken.

In case you're serious, though, you clearly have no clue what software engineering is. Yes, it includes some of the things you mention. No, it's not the same thing as CS at the upper echelons. Yes, you should include theory and science in your software engineering decisions, but no, just (CS) theory and science isn't going to be enough.

BTW, because I don't know how to contact you to tell you this: Your HN profile says "Actively searching for opportunities. email me if interested", but doesn't actually provide an email address.

[crimsonalucard]

>This is so over-the-top that I can't tell if it's parody, trolling, or just horribly mistaken.

I'm totally serious. Not trolling at all.

>In case you're serious, though, you clearly have no clue what software engineering is.

The term is so hand wavy. You can read this: https://www.wikiwand.com/en/Software_engineering

Just go to the "Subdisciplines" section in the wiki

Literally every example I mentioned is covered by a "subdiscipline" of software engineering. I'll quote the part that covers my examples:

"Software design:[1][23] The process of defining the architecture, components, interfaces, and other characteristics of a system or component. It is also defined as the result of that process. Software construction:[1][23] The detailed creation of working, meaningful software through a combination of programming (aka coding), verification, unit testing, integration testing, and debugging. Software testing:[1][23] An empirical, technical investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software maintenance:[1][23] The totality of activities required to provide cost-effective support to software."

What happened here is that I never had a strict definition of software engineering in my head. I do know that a big aspect of it usually has little to do with the theoretical side of things, so in my example I just mentioned all the "technical" terminology people throw around that has little basis in rigor or theory. Then when you said I have no idea what it is, I looked it up, and the definition literally covers almost everything that has to do with software including my examples.

There is literally zero chance you could have known that I have "have no clue what software engineering is" because my examples are covered by the definition stated in the wiki. That is zero chance unless you have no clue yourself.

A more accurate explanation is this: "software engineering" is a vague hand-wavy term. Sort of like how "Science" doesn't always involve the "Scientific method." You have some super clear definition of the term in your head, but clearly from this wiki not everybody thinks about it that way.

>Yes, you should include theory and science in your software engineering decisions, but no, just (CS) theory and science isn't going to be enough.

When did I say only CS theory is enough? Many aspects of software and the real world don't have any science or theory to describe it. Usually when you encounter such an aspect of the real world the vernacular changes from "deriving" a solution to "designing" one. My emphasis is that many engineers are "designing" things that are ultimately covered by theory and ultimately can be "derived," they simply turn to "design" either because they are unaware of theory or the theory is too hard.

We are in agreement on the point you mentioned, but I never said all you need is theory. Humanities theories about the universe are prove-ably incomplete and unprovable in general, therefore we have no choice but to exit the theoretical world for many engineering problems.

>No, it's not the same thing as CS at the upper echelons.

By upper echelons I mean you've basically learned most of it, the only thing left is the theoretical part. The theoretical part is harder and usually something a software engineer gets into once he's figured out how the rest of the non-theoretical parts work. You'll note that "mathematics" encompasses "software engineering" as defined in the wiki. I'm also not sure why you disagree with me nor am I clear about your own definition of software engineering, so please explain if you can.

>BTW, because I don't know how to contact you to tell you this: Your HN profile says "Actively searching for opportunities. email me if interested", but doesn't actually provide an email address.

Thanks. I think at one point I had it up there. I forgot why it was removed. I never got a contact from here anyway.