Hacker News Reader

Comment by diafygi | Hacker News Reader

It's great to hear there is now a PE test for software engineering!

> 5. Avoid deceptive acts.

Knowingly programming dark patterns into apps is breaking rule #5. If you're a chemical engineer and your employer tells you to put a misleading label on a batch of chemicals, you can feel very confident saying no to that. The chemical engineering community and culture strongly discourages the "just following orders" excuse, and they push for openly fighting management on unethical or misleading practices.

However, if you are a software engineer and get assigned to program a misleading pattern into an app, most people just do it. Also, slapping together a shitty program due to lack of resources is common, too. It seems that management is the driver of quality and ethics in software engineering. I hope someday, like in other engineering sectors, software engineers have the culture and confidence to stand up to management on ethical matters.

View on HN

Why is it a good idea to have a software engineering test?

How does a test make you ethical? Norms keep folks ethical.

I see these tests as mostly a protection against new people entering a field.

It's also standard to lock folks into working under "qualified engineers" for a number of years, which seems unnecessarily burdensum and counterproductive for an expanding field.

That said, I put the term "Software Engineering" right up there with "Computer Science" in terms of descriptive value.

I prefer "Software Developer" myself.

What helps with this is that in traditional engineering practice, the recipient of engineering services is typically qualified to judge whether the product is fit for purpose. When I have a contractor doing design/build/commissioning of a high-voltage substation, it's my responsibility as the owner's engineer to specify appropriate codes and standards for the contractor to meet and audit/witness their work to a sufficient extent to satisfy myself that it is being done properly.

In software, you can often have people with no technical knowledge managing software procurements. In traditional engineering we understand the importance of the owner's engineer(s) and site representatives to completing a job properly.

>the recipient of engineering services is typically qualified to judge whether the product is fit for purpose.

I'm not so sure. Most people who want a building made, for instance, wouldn't know if the electrician did it right, or if the foundation was laid using the best methods, or if the right materials were used.

Instead, you have a inspector come and verify the work.

That's simply inaccurate.

When you are constructing a building, the owner hires engineers to oversee the work done by the general contractor. There are a lot of intricate details here, but the work is exactly as the parent to your comment described.

My brother is one of the owners rep for structural work on a 60 story building going up in Manhattan right now. They're pouring an 8' thick foundation tomorrow. The people involved are all engineers working for the developer, and the inspectors aren't showing up until after the fact.

It really depends on who you consider to be the recipient of the engineering services. The customer can't be trusted to evaluate the quality of the software, so they can't evaluate whether or not you've met your ethical obligations. You need a third party to look over the code.

It really depends on the company, there are some like that. It definitely has been like that at Microsoft in the past, but they are changing so who knows where that is going. On the other end of the spectrum at DocuSign many of the engineers would try to find potential places customer data might be handled wrong so the data could be secured. It depends on the company and even the department, but some do have that openness. It helps that it is really easy to find another job in software engineering these days so the downside of standing up on ethical matters is fairly small.

Reply on news.ycombinator.com