Programmers: Stop Calling Yourselves Engineers

> In 2013, the National Council of Examiners of Engineers and Surveyors (NCEES), which all 50 states use for licensure examination, began offering testing for software engineers. The exams were produced in collaboration with the IEEE, who maintains a Software Engineering Body of Knowledge (SWEBOK).

What would such a test look like? The NCEES sample questions appear to be paywalled. The SWEBOK link 404s, but I found a pdf with some info: https://ieeecs-media.computer.org/media/education/swebok/swe...

Given how vast the field of software engineering is, would the test be similar to FAANG interviews where you need to solve some algorithmic leetcode puzzle? Or would it require knowledge of a specific programming language and all its pitfalls?

Very good article. The standards of rigor in the software industry are way below what is expected of a guy who fixes gas boilers, let alone more complex life critical systems.

And I am glad that the author mentioned Agile, which is pure scam, which only proliferates because

1. frees one from solving hard problems, replacing them with blather along the lines of "face to face communication instead of documentation" or "people over processes"

2. appeals to managerial sensitivities, so various unemployable MBAs can become "scrum masters" or "agile coaches" in tech teams, where normally they have nothing to contribute, and where they drive away the best people or at least waste their time

Engineering is applied science. As an Electrical Engineer who is also a Functional Safety engineer that is expected to define and produce software to a level of detail and rigour that often corresponds to less than a line of code per day across multi year projects, it is hard to see the "move fast and break things" crowd as Engineers.

Not to say that they have not achieved some amazing and useful things, but I remember one of my lecturers at Uni saying, "At many times during your career you may well encounter unqualified and/or inexperienced people who can seemingly deliver comparable results by taking extreme or unwarranted gambles, but it is the engineer who should be able to be relied upon to do these things for the benefit of society consistently and safely, to a known budget and schedule".

Now many people would (maybe rightly) think that is fantasy land, but there is an art to navigating the conflicting requirements and expectations within a defined budget up front when you are creating things with a very real potential to directly kill people if they go wrong. But this also brings a certain amount of conservatism that seems limiting at times of extremely rapid progress within a field of endeavour, such as we have seen in SV for the last few decades.

I wish it was more official. I consider myself an engineer 10 years later; understanding what it means and what it takes to ensure properly developed and maintained software over many years, even via multiple teams.