If you are in a context where your software has significant implications on the state of a physical system, you must be willing to work with the other engineers to make sure you've accommodated all the eventualities you can.
Part of being an Engineer is knowing what you don't know, yet following through and making sure you connect with the people who do in order to ensure all relevant questions are asked and answered.
IDE's, compilers, and other tools of the software engineering profession should absolutely not be treated as the tools of a privileged class.
However, certain contexts in which software can be applied should be subject to an expectation of higher scrutiny, and entail compulsory cross-disciplinary knowledge acquisition and application of expertise.
You want to hack kernel code? Knock yourself out!
You want to make that code responsible for operating an airplane? Bust out The Complete Engineer's Guide to Jargon, and don thy pocket protector, because it's gonna be a bumpy ride to build the consensus that that piece of software you wrote is is actually the right tool for the job.
You're mot getting it.
It's not about having/being a PE.
It's about knowing when the stakes are high enough where you need to talk with them, and make sure that you are making full use of their expertise in their subject area, and that they have full use of your understanding of writing software to ensure all your bases, behaviors, inputs/outputs, and edge cases are covered by tests, implementation, and appropriate requirements.
That means, for example, looking at the MCAS requirements, scratching your chin, picking up the phone, and calling the System Engineer the requirements percolated down from to figure out what happens on the path from sensor to entry point? What other pieces of data may be appropriate to include?
If you have no tolerance for asking meddlesome questions in the process of making a system which as written, has the capacity to pitch a plane into the ground, you are probably not ready to be put in charge of that implementation.
Write your Linux kernel in your own time however you want. But there is a time and a place for everything, and implementing hacks in a flight control system (which you as an individual should know is covered by regulatiin), is not the time to "Yes" Man. If you spend 90% of your time talking to people until the design is so solidified enough that everyone will have the schematic pop up in their dreams until the end of their days; then you're doing it right.
And at the end of the day, if you throw up your hands and hit the "Fine! I won't question this!" button regardless of that situation, and code that piece of software that enables an unsafe design to kill 300+ people... Then congratulations, you just learned this life lesson the hard way. By being a contributory factor to the deaths of 300+ people.
Engineering done wrong kills people. Fact of the territory. Please don't skimp when it truely matters. Even if no one may find out in reality, go into every project assuming once you die, you'll have to answer for every decision you made in life and ask, if I was taken to task for this, would I truly be comfortable that I've asked all the right questions?
If you can sleep at night without doing that on a Flight Control System... Please don't seek employment in the writing software for the aviation field any more critical than the infotainment system.
I'm not trying to be elitist. It just is that complex, and the consequences of a shoddy job are that catastrophic.
You can't fool physics. She is the coldest, most evil bitch imaginable.
I hope this fully answers your question.