Hacker News Reader

Comment by kinkrtyavimoodh | Hacker News Reader

Why do software engineers constantly try to project that they are a special snowflake of a profession?

Would you accept such nonsense from your plumber, or your dentist, or your electrician?

Software engineering is one of the most fundamental building blocks of modern civilization, and yet it continues to be so fragile because of this kind of cavalier attitude.

Also, apologizing doesn't mean you have a moral failing. It means accepting at least partial responsibility, and being humble about it. Any good org knows that you don't just design your system with the hope that people won't screw up, you need to design it to work despite some amount of screwing up. But in either case, it is still both an individual and collective responsibility.

View on HN

> Would you accept such nonsense from your plumber, or your dentist, or your electrician?

This would be a reasonable comparison if 90% of software developers could reliably produce bug-free code. This would be a (maybe less) reasonable comparison if 75% of software developers could reliably produce bug-free code. This would be a middling comparison if 50% of software developers could reliably produce bug-free code. This is a completely unreasonable comparison given that there have been 0 software developers ever, in the history of software, who have been able to reliably produce bug-free code. So yes, software development is orders of magnitude more difficult than plumbing, dentistry or electrician(-ing?). If you think it isn't, please feel free to jump in and prove all of us wrong.

Everybody makes mistakes, but that's no reason to never apologize.

Look, if I genuinely screwed something up, sure, I'll apologize and either way I'll fix it. But if I didn't test some corner case because the software takes 30 minutes to build, another 30 minutes to start up, and can't be run without a live database and crashes with an out of memory error after it runs for more than 30 more minutes and no time has ever been allocated to improving the code quality because that's "low priority to the business" and the fix was one of the 20 I had assigned to me in this two-week "sprint", then I don't owe anybody an apology. If you think you can find somebody better, be my guest.

Yea, this is a really bizarre article.

>It reinforces the idea that any one person or piece of code can be blamed for a given failure.

That can absolutely be the case. How could it not sometimes be the case?

>Short of malice, this is never the case.

Never? Outside of somebody deliberately harming a system, there has never once been such an instance?

>It gives the impression that, when you wrote the code, you should have written it better. This is a counterfactual that rarely holds up to examination.

Lots of assertions in this piece with no supporting information. There are plenty of reasons substandard code is written by some individuals. Laziness is a big one. Apathy is another.

>It positions shame as the correct emotion to feel about bugs in your code: if you were a better engineer – a better teammate – the bug wouldn’t exist.

Call it whatever you want, but concern is certainly warranted.

>If you’re a more senior engineer on your team, the effects of these anti-patterns are magnified: people see you apologizing for bugs, so they think that they should be striving to write bug-free code. They may feel ashamed if their code has bugs.

People look up to experienced individuals within their profession. In fact, I would argue that it is even more important these senior individuals are able to accept responsibility and act accordingly; that's setting an example, something from which everyone will benefit.

I think the important point is to let go of ego issues. A bug is a technical problem, how do we address a technical problem? By being level-headed and not playing the blame game. Being sorry doesn't add any relevant information and generate a strange atmosphere, like admitting a moral failing really. Any matter of substandard performance is better dealt by the management, well outside the scope of bug fixing.

Refusing to accept responsibility for your own errors is more an ego problem than the alternative.

No, elaborate insistence on repentance rituals, shaming, and ideologies of "personal responsibility" over systems thinking and data driven improvement is all about ego.

I don't think anyone is argue for one instead of the other.

Why not a little bit of both? Can we not think about system and data driven improvement while also at the same time apologize for our mistake?

This is not a cavalier attitude. The article is not minimizing the harm caused by bugs. It is attempting to direct the blame away from individuals and towards systemic causes of defects. This is necessary to be able to effectively address them.

"Just be more careful" has pretty much proven not to be a successful strategy to reduce defects.

>Why do software engineers constantly try to project that they are a special snowflake of a profession?

I agree but this point is orthogonal to the main point. Plumbers and electricians build to code in an environment where physical reality remains constant and they operate on expected inputs. A civil engineer is not held to account for a failure if gravity suddenly reverses itself. If I shock a circuit board with static electricity and it fails is that an electrical engineer's fault? If I put 20,000 psi through a household plumbing system and it fails is it the plumber's fault? These designs are only expected to operate in a narrow range on a small number of expected inputs / variables and that is easier.

Software can basically expect infinite permutations of inputs at any time and is expected to give good outputs and no bugs 100% of the time?

(IMO / 2 cents) because as a software developer, you can create a huge amount of functionality in a short amount of time if you cut some corners. This just isn't the case, doesn't have nearly the fast return-on-investment that you get in other fields of engineering.

I mean in electrical engineering, idea-to-working-prototype involves a lot of design and assembly first. In structural engineering, you just can't build a bridge on your own. It goes on.

While in software development, I can cough up ten distinct features in a day if not more without forward design or testing.

When you design a hammer and sell it to the end user, there are limitations on how they can use it. You simply cannot encompass and address every situation that the end user would subject the hammer to. What if they left the hammer in a hot 1500 C oven? The designer cannot design it such that it can universally work in every situation. There are usage guidelines and limitations.

A hammer that melts in a furnace is considered a bug?

The possibilities and test paths a piece of code can possibly take exceeds a very large number in a complex software application.

Is it really a bug when your software crashes when there is no memory available? Usually, this isn’t considered one.

Actually situations like this are still considered a bug in software. It is always the responsibility of the software to be resilient against externalities.

Zoom should work and gracefully fail if there is not a single microphone device found on the client’s PC.

No, it continues to be so fragile because software engineers build virtual machines with enormous numbers of moving parts that need to change all the time but nobody wants to pay the price for exhaustive testing (not to speak of the price of formal verification).

We are pretty good at writing software with a very small number of bugs, it just costs a few orders of magnitude more than normal software.

This is the same thing I was thinking. We write imperfect software because the market (and the law) does not incentivize the significant extra work required for perfect software. Blaming individual engineers or organizations for that doesn't make any sense.

Its because software is always "new"

Imagine if an electricians invented new types of wires for every job they did

I'm not sure why software is the way it is, maybe it will be more like a trade in a few decades...

No it's because a piece of software with a few hundred thousand lines of code has a state space that boggles the mind. And then that software interacts with a dozen other services of similar size. And then new features need to be added every few weeks. It's completely incomparable to wiring up a normal house.

In buildings with nontrivial electrical systems, shit hits the fan really quickly too. Just look at the absolute mess that is the fire prevention system in Berlin's new airport for example.

I see what you're saying, but I think electronics is equally or more complex than software, but over a longer time period

Copper, plastic, other things which I have no authority to talk about, were all complex at one point in time

You do make a good point about scope creep, I wonder if the early days of electronic had a similar problem because nobody knew what they wanted or what was possible?

Very interesting to think about IMO

I'd think so. If you were to install one of Tesla's early first AC motors, it'd sometimes do unexpected things or stop working intermittently, I suppose

I have never heard of a plumber, dentist or electrician apologizing for anything - unless you count court orders...

This is about the dynamic between people within the organization (coworkers, boss, etc.), not about external communication to customers. That is, we aren't talking about whether an individual software engineer should apologize to the customer or the end user.

So the analogous question would be whether someone who has worked as a plumber has ever heard a coworker plumber apologize for messing up a job. I'm hoping the answer to that is yes. A plumber apologizing directly to a customer would be more analogous to a company making a public announcement about a bug, which is a different issue than how responsibility is determined within a team.

And yet my house has never caught fire due to a miswiring or got flooded due to a misplumbing but let me not even count the ways in which software has failed me.

Maybe there's a reason you rarely hear one category apologizing and hear the other category coming up with excuses.

> but let me not even count the ways in which software has failed me.

Failed you? This sounds either very entitled or sensational. Has software caused you major grief in any way financial or the loss of limbs or loved ones? While this happens, very few people are affected by bugs in such a way, at least confirmed.

When someone pays for software, they are perfectly entitled to expect it to be fit for purpose. Failures don't have to cause major grief for me to be justifiably irritated and to expect redress. A conscientious developer should apologize for wasting people's time or selling them products that don't do what they are supposed to.

>Failed you? This sounds either very entitled or sensational. Has software caused you major grief in any way financial or the loss of limbs or loved ones? While this happens, very few people are affected by bugs in such a way, at least confirmed.

Many people have been significantly affected by software bugs. Therac-25[1] is one I constantly remind myself of; it killed 5 people. Here's a list for further reading: https://en.wikipedia.org/wiki/List_of_software_bugs

I'm not sure what your definition of "very few people" is but we'd all do well to aim for 0 adversely-affected people as a result from using software we write.

[1]https://en.wikipedia.org/wiki/Therac-25

Read my reply again, note especially the part "While this happens". Obviously I am acutely aware of what you are saying, no matter how many Wikipedia articles you link, so your comment is not only superfluous but also makes no sense, as I was asking OP if he was personally affected in such a way because he seemed bitter. Your reply does not answer this, and you should let him answer for himself.

> I'm not sure what your definition of "very few people"

I think my definition is about the same as every accepted definition of "very few", the number of people affected by such bugs falls within this definition, considering how many users software has.

> Many people have been significantly affected by software bugs. Therac-25[1] is one I constantly remind myself of; it killed 5 people.

5 does not fit the definition many in anyone's book.

>5 does not fit the definition many in anyone's book.

...

>I was asking OP if he was personally affected

So 5 people dead is insignificant, but a single person, adversely affected, is cause for concern?

There're billions of people using software, divide 5 by that.

> 5 does not fit the definition many in anyone's book.

Well, IIRC, there's Watership Down, a literal book, but I assume you meant that figuratively.

not to split hairs here, but according to the Wikipedia article, Therac-25 only killed 3 people.

Plumbing and electrical doesn’t change all too often. Once you learn the ins and outs it doesn’t change much over your career. Not the case with software development.

And when they do change there are very straightforward guides to the changes, when and where you can/should/must use new materials, and so on.

I know people who’ve programmed microcontrollers in C all their lives and still written bugs. It’s not like switching tooling once in a while is the source of bugs.

Still you insure your house for those things though. I think you are comparing apples with oranges here.

The worst thing code I have written ever did was cause a small power outage. But that was a one-time thing, I haven't had the opportunity to write code that even could do that in years.

Mine has - my plumber didn't apologise, but he did instruct me over the phone how to properly apply PTFE tape.

Plenty of people are hurt or killed through clerical errors by medical professionals, but you're not going to get anyone admitting that. Even for something simple, if you have any accusation to make in a medical context, it's probably time to evaluate your options and consider a new doctor, and only then make your accusation.

There always will be good and bad craftsmen. I once overheard my electrician demanding the guy installing the alarm system to lay his cables properly.

With plumbing the tools of the trade have been the same for 100+ years. Pipes, wrenches, valves. It seems like every two years in the software engineering realm you have to learn to use a completely new tool in order to be valuable to a company.

Depends on the project, but I'd wager, that software development is a _bit_ more complex than plumbing in many cases.

Make sure you're comparing them equally here. So don't compare the plumber coming to your house to fix a problem with the sink, with a software engineer working at a airspace center for example. The home-plumber vs the home-hacker and the enterprise-plumber vs the enterprise-developer is a more fair comparison, and while I'm not a plumber, I think you underestimate the complexity they deal with when working on a larger scale.

>Depends on the project, but I'd wager, that software development is a _bit_ more complex than plumbing in many cases.

This is an incredibly ignorant statement. Have you worked in that profession? Any professional engineering roles?

But that all doesn't really matter because the statement becomes meaningless when qualified with "Depends on the project[...]"

I've worked as a structural engineer (EIT) before. There are some situations where structures are complex (earthquake modelling and really large bridges) but honestly software is way, way more complex than structures. I'm not saying I agree with the contributed article (I think people should be sorry for bugs they missed, at least to a point) but I have some empathy for the fact that even seasoned developers let bugs in despite all the tests, and lints, and monitoring, and best practices. Sometimes you just don't anticipate something and nobody else around you did either. It's a more complex domain than the forces in the physical world, and unlike the physical world in most cases, the same mistake goes to everyone. One electrician screws up one time and one house burns down to the ground. One software engineer screws up one time and well everyone's shit breaks at the same time.

I think it's normal to assume averages when comparing things.

I would be interested in some experiments of average developers learning average plumbing vs average plumbers learning average development. I'd wager theres an order of magnitude difference in the results(time spent, quality etc).

Really incredible, when you have to go through university for at least 5 years, with heavy technical and at least for me mathematical lectures. Also incredible, when the complexity of IT systems is ever rising. Incredible, when we basically have to build mathematically correct systems, to make sure things work exactly like they should, including weird user wanted behavior, just for historical reasons. Also weird, that working in IT often requires a degree and that degree has requirements in educational background, which do not exist for plumbing.

Besides all this incredibility, yes, I do work professionally in an engineering role.

Limiting a statement is not the same as a completely making it meaningless. Of course there are plumbing projects, which are more complex than a static blog. Besides that, I would also like to remind you of the little part of the phrase "I'd wager that". I did not know, that it is an "ignorant" statement, to express ones believes.

> Would you accept such nonsense from your plumber, or your dentist, or your electrician?

In the UK...

Dentists: you have to have a BDS or BChD degree from a dental school at a university

Plumbers: have to get NVQ diploma as well as pass Gas Safe accreditation to fit boilers and heating systems, plus get a CSCS card to work on construction sites

Electricians: have to get an NVQ diploma, and to work in construction, they must also have an ECS card to work on a building site

Software developers: [this is left blank as an exercise for the reader]

> Software developers: [this is left blank as an exercise for the reader]

In fact, there's a (very popular) school of though that the more credentials you have, the less qualified you are to develop software: https://blog.alinelerner.com/how-different-is-a-b-s-in-compu...

I hear from plumbers and electicians all the time that the last guy to work on something was an idiot. Medical errors are routine and managed through a combination of procedure and insurance, not by admonishing doctors.

“Thanks for reporting this, I’ll take care of it” is accepting responsibility while avoiding a morality judgement.

I totally agree with you. In fact, some branches of software engineering do have equally high standards as other engineering fields. If you write the software for a medical device or an airplane, you better make sure it doesn't have any critical bugs, otherwise people will die. If you write audio software for professional musicians, you better make sure that it doesn't have any critical bugs, so you don't ruin a live show. I think people claiming that nobody can write bug free code and you shouldn't even try simply work in environments where failures don't cause irreversible harm.

Everything exists in an economic context. Errors in plumbing, dentistry, and electrical work can result in thousands or hundreds of thousands of dollars in damage, and they often can't roll out a fix in a matter of hours. Some software bugs can also result in lots of damage (financial/health data security, etc), and we do take those bugs seriously via compliance (although compliance isn't a guarantee for good software just like it's not a guarantee for good dentistry). But no one is going to pay for the effort required to perfect every software release, nor should they.

Yeah I'd accept it from my dentist. A couple of years ago, they gave me a dental crown for one of my upper right molars. Two months later, it chipped. It felt weird in my mouth.

Why wouldn't this be acceptable? They source that crown from a supplier, and apparently there was a fault with it.

Did they apologize and try to fix it? This is not about being perfect. The parent post is fundamentally about caring about your mistakes.

Sure you have a point, but then I do not force my plumber to do his job in far less than the time required, keep changing the plumbing requirements and make him start before the final requirements are seven known.

What makes you think only software engineers face time and planning constraints?

You are right. This is the flip side of not treating software as an engineering discipline. But both parties are at fault. The business treats us like non-engineers and we don’t behave like ones.

Reply on news.ycombinator.com