This is just passing the buck. If the boss tells you to write credit card stealing software or to DDOS your competitor are you just going to do it? As professionals, we need to push back and refuse when we know our practices are letting critical bugs go to production, just like (I assume) we'd push back if we were asked to build something unethical. And we should be accountable if we don't.

If a civil engineer signs off on a bridge and it collapses during rush hour, he doesn't get to just say, "Whelp, boss rushed me, blame him."

> If a civil engineer signs off on a bridge and it collapses during rush hour, he doesn't get to just say, "Whelp, boss rushed me, blame him."

He doesn't but this is actually a problem. Ideally, he doesn't get to say this because he chose to rush and if he'd said "No" instead then the boss can't do anything about it. In reality, especially in the US, his boss will just fire him and hire somebody else more co-operative and he knows it.

Without a strong, legally supported and well resourced professional organisation behind people with an obligation like this, they will get exploited and then blamed by people who are insulated from the effects.

Do you see such an organisation for software engineers in the United States of America? Or even most of Europe? Because I do not.

I fully agree a strong, organized professional organization for software developers would solve a lot of problems the craft faces. If we had something like the Bar Association or the Medical Board, would we have to keep implementing FizzBuzz and reversing linked lists every interview just to prove a basic level of competence?

Not, but then the "Software Developer Board" would apply those as certification tests instead.

But you'd take the exam once rather than having to do it every few years when you want to change jobs.

> Do you see such an organisation for software engineers in the United States of America? Or even most of Europe? Because I do not.

The problem is that medicine and law move orders of magnitude more slowly than software, at the moment. Software is evolving unbelieveably faster, and its problems are far more diverse. As it settles down, if it ever does, we may be able to calcify roles more formally, and then regulate those roles. But at the moment it's the wild west.

Your example is so decoupled from reality that it's misleading. Most catastrophic problems in large systems aren't "I made a thing and it's buggy," or "I made a thing that steals SSNs." Most of them are some variation of "It used to work this way, but this upstream dependency changed in a way that we are ok with, and now it works a different way, and we have no visibility into what that may change for downstream dependencies, so hopefully they are aware of the same things we are and act accordingly." Bugs can come from many different people signing off on changes that are often, in isolation, fine.

Imagine if all buildings had to constantly be retrofitted to support a new structures on, below, inside of, around, and next to them, and every retrofit had a different engineer/architect/etc. No civil engineer would ever sign off on anything.

Yours is a good example! I have in a past life actually used the "you wouldn't bolt a new floor onto a building" argument successfully to push against feature creep.

I think even a small amount of accountability would definitely start some much-needed conversations at software companies about things like "do we really need to retrofit this thing onto that working thing?" and "do we fully understand our dependencies and the consequence of merging from them?" and software quality would be better for it. If the consequence of a bug is low, go for it--the accountability should be low, too.

EDIT, just to add another example. I remember when I felt rushed and checked in some client code that did not implement exponential backoff for request failures--it just retried. Of course that code made it to production and our customers started DDOSing our server when a brief outage happened. I felt terrible about it and honestly believe I should have been fired for it. Yes, management rushed me, but they're not the ones that wrote the code. They're not the ones that made an amateur-hour error. It was me.

> I felt terrible about it and honestly believe I should have been fired for it. > Yes, management rushed me, but they're not the ones that wrote the code

If you felt so strongly about it, you could have quit. Why wait on management to fire you?

It's fairly easy to blame engineers for everything that goes wrong. Engineering doesn't work in a vacuum, the system and processes have to have guardrails in place that prevent lapses in quality, including security, from reaching the customer. When such guardrails have been systematically dismantled in favour of "improving productivity", the management - which removed the guardrails - becomes the culpable entity.

Interesting. Great that you want to take full responsibility for your work. There is always two sides to a coin though. Strange to me that you scapegoat yourself that hard. Reminds me of the story, where someones error cost the compny millions. He gets called in his superiors office. He says something about resignation. His boss responds: "What? We just invested millions in your education". Every error we still have to make, is a treasure waiting to be dug up IMHO.

> Yours is a good example! I have in a past life actually used the "you wouldn't bolt a new floor onto a building" argument successfully to push against feature creep.

I've seen a few houses built on top of apartment buildings though.

> had to constantly be retrofitted

There’s your problem. You can’t constantly change software contracts without causing bugs. If you’re liable for the code chances are things will slow a bit. Good! We need to develop software slower.

> You can’t constantly change software contracts without causing bugs

You can't write software without causing bugs. Static requirements or not. The software that goes into aid/space-crafts is written this way, and it still breaks occasionally. Sometimes bugs are circumvented with hardware because it's cheaper and more reliable than making the software change.

Buildings have fault tolerances. You can use the wrong amount of something, or put something in the wrong place, and have it still work. If buildings had to be designed and built exactly corrects or they fell apart, we wouldn't have buildings.

> We need to develop software slower

To each his own. Most software is fine having bugs. I'd rather have a modern web browser with a few bugs than have an ascii-only command line browser that works flawlessly. The U.S. economy would agree with me there. The software in your pacemaker or car, sure, balance safety and speed to save the most lives/time, but most software operates in domains with far lower stakes.

> If a civil engineer signs off on a bridge and it collapses during rush hour, he doesn't get to just say, "Whelp, boss rushed me, blame him."

I'm willing to bet that the civil engineer in that case has much better whistle-blowing protections, or at the very least, some comfort that if they get fired and someone else replaces them that's willing to do it... that person will be the unhireable one in the future.

> This is just passing the buck. If the boss tells you to write credit card stealing software or to DDOS your competitor are you just going to do it?

This is already illegal. Holding the makers of things more accountable would do nothing for you in this example.

At a properly licensed engineering firm, the managers are senior engineers who review and sign off.

Keyword being properly. Too many companies push their engineers into people management.

Which is weird. Your best people should remain engineers. Have them indeed sign off on these things.

> Your best people should remain engineers. Have them indeed sign off on these things.

I agree; the problem with an engineer track is that the salary ceiling is too low, and you have to move to management to get higher salary. but then you end up not using your engineering skills, and waste potential.

What needs to happen is a way for people management to be done without a hierarchical structure. Aka, the senior engineer sits not under their manager, but that the manager is subservient.

Joel spolsky have written about this "problem" already in the last couple of decade: https://www.joelonsoftware.com/2009/03/09/how-to-be-a-progra...

> To make sure that the debate happens respectfully and on a rational basis of facts, it’s absolutely critical that the program managers and developers be peers. If developers report to the program manager, at some point during the debate the program manager is going to get sick of the whole thing and just say, “OK, enough talking, now we do it my way.”

The salary range in a professional track does not _have_ to be too low. That's a choice, a value judgment, by management. Some companies do things differently. In at least one company I know, the professional track runs parallel to the management track: engineers can earn as much or more than senior managers, architects as much as directors. It's all up to whether the organization really values the services it's independent contributors provide. Sadly, many companies are not only indifferent, but hostile to the whole concept: playing at cost reduction theater and outsourcing to satisfy the avarice of simpleton investors. Bottom line is that tech pros need to take charge of their own futures and avoid the latter kinds of companies like the plague, when they have a choice. People need to make a habit of asking questions about professional compensation structures during interviews.

Indeed. I haven't worked at a company that was managed (partially) by engineers. Sure, there were tech leads, but as soon as it came to product and account management and "up", it was business school. Must be some corollary of Peter's Principle.

I don't think pushing a good engineer to also take on management work is such a bad idea. I've actually had quite a lot of success with that system.

The much worse idea is to promote BAD engineers to full time management positions, which seems to be the way most sub par and mediocre companies do it right now.

The problem is when this is the only path to growth. You basically cap out as Senior Engineer.

Is that an argument for the former or the latter?

I think that the choice should be up to the person. But there almost never is a non-managerial path.

The meme is that great engineers make bad people managers. They can still be engineering managers, and have a business/HR people run the org and try to make underling engineers productive, while the lead engineer is responsible for certifying whatever gets engineered.

I don't think this is black or white. I've found out that brilliant engineers actually can be incredible people managers if you help them develop those soft skills. Sure there is the age old adage that "I am a brilliant engineer just pay me more for my engineering work" but this has two aspects. For one you definitely can do it if your org is big and rich enough. But on the other side, software is a product of people interacting. If your engineering importance rises you still will have to deal with lots if people. So are you really staying purely an engineer then?