18 ms·

I’ve made a conscious effort to stop apologizing for bugs in my code

130 points by dsr12 7y ago

ilaksh 7y ago
I agree about not apologizing for bugs. But I disagree about it being something special to leaders. And the way he says it, makes it sound like maybe he thinks leaders shouldn't apologize in general. Which I think is a fairly common belief that leaders use to justify not admitting they made a mistake. And is 100% different from not apologizing for bugs. Since as he points out, bugs are not mistakes, they are a normal part of development. When the manager makes a significant mistake it's not like a bug, it's a poor judgement that probably affected everyone. And sometimes if it's a very negative affect then an apology is warranted. But at least, it's usually necessary to acknowledge when you had people going in the wrong direction.
- deleted 7y ago
  [deleted]
Negitivefrags 7y ago
So sure, bugs happen, regardless of how good you are. But there really are some people who constantly make mistakes, and those that rarely do. There are people on my team where, when there is a bug, I just start looking at diffs of what they have committed because more likely than not, they caused the problem. I think it's important to reinforce an attitude of trying to become better and people who give a shit when they make mistakes tend to also be the ones who make less of them.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
- erikbye 7y ago
  > There are people on my team where, when there is a bug, I just start looking at diffs of what they have committed because more likely than not, they caused the problem. If you can tell the bug from looking at diffs, why was the bug not caught in code review or by tests? Most obvious bugs should be caught this way.
  - lidHanteyk 7y ago
    In my experience, it's because Thing 1 and Thing 2 can review each others' code, and have no compunctions about potential bugginess. Somebody else gets to pick up after both of them, and is always outvoted during team code review. It's like giving a minority report, honestly.
    - danenania 7y ago
      Code review also isn't great at catching the kinds of edge cases that lead to many production bugs. Even tests only help you so much, because if you forget about input X or state Y or api result Z while writing the code, you're likely to forget about it when writing tests too. This is why bugs are more or less inevitable in systems beyond a certain level of complexity that are being actively worked on, and why engineers who think very carefully about anything that could go wrong will produce far fewer bugs than sloppy engineers who try to use process as a safety net.
- Libeste 7y ago
  It's more important to identify the root of the problem and actually solve it. Even if these people suck at coding and are still committing code without someone else double-checking their work, they're not the real problem.
malikolivier 7y ago
As a manager, I've always striven to apologize for my errors. I do agree that errors are unavoidable and are bound to happen. That's why I actually never cared at all whether programmers apologize for bugs. Fixing bugs is also part of the software development process after all. However, I've always believed an apology is important to show humility to my team mates. As a manager, I do not want to appear entitled. Of course, as soon as the error is uncovered, we should prioritize it and fix it. But I do not believe that proceeding to fixing an error is orthogonal to apologizing for it. We are trying our best to build a company without a guilt culture. In such a position, is apologizing a bad move as a leader? What would you do?
- lenzm 7y ago
  I'm a manager and I appoligize if it was a stupid mistake made from carelessnes. Apologize if you did something you wouldn't want other people doing. I think context matters too. The industry you're in (what are the consequences of bugs) as well as the part of the codebase (presentation or data integrity) change the acceptability of bugs.
jon889 7y ago
Maybe don’t apologise for it, but I definitely think it’s useful to acknowledge if it was your code as it removes an awkwardness around it. Obviously this doesn’t have to be done for every little bug but if there’s a discussion around one then owning it can help.
Angostura 7y ago
He says that this is a fallacy: > It reinforces the idea that any one person or piece of code can be blamed for a given failure. Why is that a fallacy?
- ithkuil 7y ago
  Probably because there is always a bigger picture: culture, process (e.g. testing, code review, time pressure, feature centric performance metrics). Surely, the person making the mistake is the proximal cause for a given bug, and surely all other things being equal personal attitude matters (i.e. a more careless person is going to make more mistakes), but if you zoom out to the big picture you see other responsibilities and more importantly you see opportunities for improvement that vastly exceed the playoffs of "just putting more care" into each commit.
  - Angostura 7y ago
    Understood. Thanks for the explanation. I have to say I don’t intuitively like the position, because taken broadly you could conclude that no-one in an organisation is ever personally responsible for their actions, because some system should have prevented the mistake. This feels wrong
    - ithkuil 7y ago
      Indeed, it does feel wrong because it is, technically, wrong. The intent of a "no blame culture" however is to find a new sweet spot on the myriad of tradeoffs an engineering organization does, as an many paradigm shifts we do, it is accompanying with a certain amount of bullshit-sounding maxims meant to be thought provoking and dislodge the readers from their suboptimal local maximums.
- redis_mlc 7y ago
  Conceptually, there's supposed to be a process that reduces errors, rather than relying on each individual to be infallible.
- lenzm 7y ago
old-engineer 7y ago
Would you be ok with your dentist being OK with her slip-ups? “I really should have checked the x-ray better before I extracted your front tooth. But you know, I’m not sorry. It was an external constraint — there was a queue of patients waiting”. I can’t believe how low we let this profession sink. I hope in 15 years we will look at thies era like we look at the Wild West today. Exciting from a distance but nobody would really like to live like that.
- sairamkunala 7y ago
  This comparison is like comparing apples to oranges. I believe we need to get the "context" before judging any situation.
  - old-engineer 7y ago
    What I think should be common in these two cases is the attitude of a professional towards their work. Building software should be an engineering discipline with all its perks and responsibilities just like building bridges. We rarely see it and it propagates to the craftsmen who seriously believe that good quality software is impossible to write under the slightest of constraints. Like business pressure. We had this ability in the past when programming was way more difficult, tedious and error prone. Look what IBM did with their “Clean Room” approach. I’m sure we still have it at many places but we choose to spread the myth that it cannot be done. This call to stop apologizing is the next step towards not even trying.
    - sairamkunala 7y ago
      > What I think should be common in these two cases is the attitude of a professional towards their work. I think everyone would not deny this fact. Engineering is more of a discipline. But if you see things practically, this issue of "bad" code may not happen for various number of cases. For example, unclear project requirements, use cases etc., That is where 'context' of what happened helps to better understand the situation. Building bridges are not done agile and it has a learnings from decades or even centuries. Computer Engineering is mostly agile where you push changes based on changing requirements.
yborg 7y ago
This sentiment reminds me of Gerald Weinberg's observation of four plus decades ago - "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." I was trained as a computer engineer, and the difference between those who were taught to approach software development as a craft and those who think bugs are ok and it's really about feeling good about myself at the end of the day is clear and obvious in most organizations and in the product that comes out of them.
- danenania 7y ago
  At the same time, if programmers had to deal with the same kinds of rigid constraints as builders, writing a simple MVP would cost millions, and we'd have a lot less new technology in the world.
yxhuvud 7y ago
No, I'm not going to stop taking responsibility for my actions.
thdrdt 7y ago
Well there are multiple kinds of bugs. You did not test it? Apologize. You were sloppy? Apologize. In most other cases I can agree with the author. All I can add is that, as a freelancer, I always explain (like they are 5) what went wrong. My customers don't care about the details but they like it when they know I made an effort of creating good software (bugs included).
- aeno 7y ago
  > You did not test it? Apologize. Not on every case. I once had a customer who literally removed the "Testing" part of my offer because it seemed to expensive to him. As testing often takes a considerable amount of time I do list it explicitly in an offer and don't "hide" it in the numbers for the other tasks.
  - catalogia 7y ago
    Imagine if electricians let their customers opt out of electrical code compliance...
fredsted 7y ago
I think it's worth acknowledging over your customers that the bug has caused them lost time or other kinds of issues. Whether you do that with an apology, it doesn't really matter, but I know I'd personally feel better when a vendor emphasizes with me. Something you definitely don't want is to sound like it's an inconvenience for you that they're reporting bugs. Bug reports are extremely helpful and you should be grateful that they're taking the time to report them to you.
- erikbye 7y ago
  > I think it's worth acknowledging over your customers that the bug has caused them lost time or other kinds of issues. As a company, by some PR representative, yeah, sure, maybe, but individual developers should not apologize.
  - fredsted 7y ago
    I guess it depends. As a solo entrepreneur, I do it all the time, because I care about my customers. Working at Instagram, probably not, since it wouldn't be my job to handle support.
abete 7y ago
Bugs categories are also important. My project and my leadership was destroyed when a non-technical wanna-be "operation" manager without experience in software development, started to see only bugs and reduce all development to bug fixing. Some "bugs" are in reality wrong or misunderstood requirements. Some are missing features. Sometimes the joke "it's not a bug it's a feature" is real. Sometimes "bugs" are edge case we didn't want to solve immediately, until the edge case it's not edge anymore. I think what is dangerous it's seeing ONLY bugs, focus dev ONLY on bugs. Shift a little the point of view from bug fixing to software evolution.
kinkrtyavimoodh 7y ago
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.
- catmanjan 7y ago
  I have never heard of a plumber, dentist or electrician apologizing for anything - unless you count court orders...
  - kinkrtyavimoodh 7y ago
    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.
    - lvturner 7y ago
      Mine has - my plumber didn't apologise, but he did instruct me over the phone how to properly apply PTFE tape.
    - stanmancan 7y ago
      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.
      - 7y ago
jwr 7y ago
I earn a living from my SaaS. I am a solo founder, responsible for everything. I wrote all the code. My customers pay subscription fees because the software makes their work easier (it's a B2B SaaS, https://partsbox.com/ https://partsbox.com/). Bugs are solely my responsibility: there is no one else to blame. And bugs mean that my customers paid money for a product which did not work as intended (certainly not as I intended it to work). I feel it is definitely right to apologize for bugs! I disagree with the author: if I worked at a workshop and dropped a hammer onto my customer's foot, I should apologize. No matter what the reason: I could be clumsy, or you could say that no one could be expected to never drop a tool — still, an apology is in order, because I did drop that hammer, and it made my customer's day worse. Therefore, I always apologize for bugs. What I did, however, learn to do, and it is quite important, is not to apologize when you are not sorry. An example is when a customer is unhappy with the pricing, or complains about a missing feature. Many people will begin a reply with "I'm sorry, but…", and it's the wrong thing to do. I only say I'm sorry when I really am.
- cl3misch 7y ago
  I think the article is talking about (not) apologizing to your coworkers, not costumers.
  - dingaling 7y ago
    Co-workers are customers too. Everyone who has a dependency on your code is a customer.
brujoand 7y ago
If you fuck up I don't really care about an apology. I want to know: 1. How will you fix it? 2. How will you prevent it from happening again? An apology, in my head atleast, is for when you have caused emotional distress to someone and there isn't much you can physically do to fix it other than to convey how you now feel about what you have done. When you make a practical mistake an apology is implied by you fixing it.
- twic 7y ago
  There are perhaps two parts to an apology. One is an acknowledgement that you did something wrong, and that you should not have done it. The other is a sort of ritualistic, performative (in the original sense!) use of language that may make someone feel better. This is the difference between: "I made a mistake when i dereferenced that null pointer" and: "I'm sorry i dereferenced that null pointer" I absolutely agree with you that the ritualistic part is pointless, and perhaps harmful if it is performed instead of actually fixing the problem (see also "thoughts and prayers"). But i wouldn't want to stop doing the acknowledgement part.
  - zeroimpl 7y ago
    I wouldn’t refer to the first stage as an apology, it is simply an acknowledgement. I very rarely apologize for a bug at work. I don’t expect others to apologize to me either. Apologies should be reserved for personal/relationship things, like forgetting to invite somebody to a meeting.
Kapura 7y ago
Shipping with bugs is not an inevitability. Bugs come from code being used in cases other than the ones that the programmer anticipated. But it is possible to understand how code will be used. You can test against it, either manually or with some automated testing tool. And you can produce code that behaves the way you expect it to every time you run it. Every once and a while you might mistype >= as <=, but you can catch it and fix it with only a modicum of effort. But you first need to believe it is in your own power to write less buggy code. If you can identify patterns that frequently produce bugs, you can try to avoid them (e.g. copying & pasting: very buggy!). You can identify, isolate, and document footguns and complex API. And you can be proactive in simplifying systems when feasible to do so. Don't beat yourself up if you accidentally have a bad commit, but don't excuse sloppy behavior. Demand better from yourself. Don't produce garbage software.
diebeforei485 7y ago
Particularly for entry-level folks: if your code passed code review, it means others didn't catch the bug either. The company could apologize to customers if needed. But it would be insane to make the individual developer apologize to customers.
KhalPanda 7y ago
A lot of the replies and analogies here are interpreting this as a business-consumer apology. Of course if a business has disrupted a customer's experience through buggy software they should issue post-mortem/apologies/etc. But I read this as though the author is saying apologies to fellow teammates shouldn't be necessary, which I do at least in part agree with.
deleted 7y ago
[deleted]
twelve40 7y ago
This reads a bit like one of those feel-good "managers should be good to employees! agree?" posts on linkedin. The bugs I see in PRs from even some mature people are things like input_array[0] without checking the array for null or size. Anyone beyond cs101 can tell you this is unacceptable and careless, and the author likely had a "fuck it" attitude, and was in a hurry to get back to Netflix or whatever was really on their mind. Should we expect for them to go into a full-on dogeza Japanese kneeling bow apology? Of course not. But there are many cases where a person glaringly half-assed something, cut corners, quietly committed something directly to master. And yes, this person should feel some kind of regret, or should be brought to stop such behavior because it is extremely destructive and is totally avoidable and caused not by overworking or accident but by persistent carelessness and neglect, so it cannot just be cheerfully swept under the rug.
- commandlinefan 7y ago
  > there are many cases ... where a developer was given 30 JIRA tickets each "sprint" and whose "performance" was evaluated entirely on how many they completed.
- roosterdawn 7y ago
  Why doesn't your team have a process (integration tests, etc) that makes it impossible to check in something like `input_array[0]` without breaking a build? Why is it allowed to directly push to master? How does the old saying go? The road to where is paved with good intentions? You could engage in moralizing against "carelessness" and "neglect" and presuming that a teammate somehow cares more about watching Netflix than doing their job (which they presumably outperformed other candidates to even get), and maybe that will make you feel better. You are the good, careful, model employee, and that other one -- they're careless, slovenly, apathetic and lazy. But if that's the case, how did they get past the door in the interview process? If the whole company is like that, why do you work there as opposed to a company where the bar is higher? Something does not add up. In all likelihood, your explanation is a rationalization and not the most obvious answer, which is that your process could be improved but it hasn't been because such investments are not viewed by your companies executives as improving the long term bottom line to be worth the short term investment cost. Take a look at history and figure out how companies in the industry have solved this problem before by building more bulletproof runbooks, processes and tools. These companies, as they approach enormous scale, necessarily have to determine how to deal with employee reversion to mean. It turns out, surprisingly, that process eats good intentions and care for breakfast. You'd be surprised at how quickly those good intentions become useless if your company is successful and you hit hypergrowth and scale. It's ironic that for a profession where it is so tractable to automate away mundane or repetitive tasks, where we study spacetime complexity in data structures and algorithms, that we have so many practitioners that default to witch hunting and moralizing and seem unable to apply spacetime complexity or procedural analysis to their own software development lifecycle. I expect to see this trend change as our still young industry continues to mature.
h91wka 7y ago
To commenters who compare work of programmer with the work of civil engineer: There is an explanation to this discrepancy. Risk = probability of fault * cost of fault. Programmers usually work with the data. Data has a pretty very unique property that it is easily and cheaply copied and restored. It also means data can be replicated more easily, which allows to build systems with large amount of redundancy. Therefore, price of a software bug is usually orders of magnitude less than the price of breaking something in the physical world. This allows to drive up probability of fault parameter and allows for much faster evolution and less regulation.
- mdtusz 7y ago
  I think a part that needs to be considered in the comparison is also the concept of safety factors. Many structural engineering projects are built with a safety factor greater than 1, which allows for - as you'd imagine - safety. In software, it could absolutely be done that every function has explicit validation checks for each input, and that more safety, error handling, and checking is written. The economics just don't make that viable though except in the most extreme situations where this is required. In aerospace, with the exception of the recent Boeing debacle, there's been very few software related issues (that I know of) relative to the number of CPU cycles run and flights taken - I'd be willing to be there's far more mechanical issues that cause grounding and maintenance cycles. Now look at civil engineering and infrastructure. How many roads do we drive over daily filled with potholes? How many bridges get patches and repairs every few years because of concrete cracking and rebar rusting? (I live in Quebec, so there may be bias in this statement). Maintenance like this is just paying down tech-debt - the same as in any field. Software absolutely can be built to a high level of robustness (and it is) - it's just not economically sensible in most cases.
- cryptonector 7y ago
  Replication costs have nothing to do with anything here. The damage caused by a software bug can range from nil (even negative, since a bug might have desirable effects) to incalculable. Consider a bug in software used for landing SpaceX boosters... Or a bug in a trading platform. Or a bug in an automated medicine dispenser. Or... You can compare the work of a programmer to the work of a civil engineer, but it's true that it's difficult because most bugs cost little, much software is not positioned to cause much damage if buggy, software bugs are so prevalent, and it's so difficult to write bug-free code. But the cost of replication of software has nothing to do with any of this.
bryanrasmussen 7y ago
I wish I could find that one guy I worked with about 19 years ago that tried to load an ActiveX component in his VbScript running in Netscape and send him this article, true he never apologized - but I just want to make sure he doesn't feel bad about never apologizing.
gwbas1c 7y ago
The biggest career lesson that I've had is that 80% of development is testing. Should you apologize for bugs? No. But if you're doing professional quality work, (as opposed to prototyping or researching,) a large portion of your time (as a developer) should be writing automated tests (like unit tests) to test the code you write.
freediver 7y ago
Bugs are the responsibility of the process that brought them there. In most cases it is shared responsibility. Why doesn't your dentist mess up 1 out of 5 interventions? They have gone through years of strict training and there are giant liabilities in place. In development? A lot of self-taught developers, who can always jump to a next gig because of never-ending demand. This sets up the scene for a totally different scenario - never-ending stream of bugs. If you want your team to have less bugs, then as a manager make sure you have a process in place that optimizes for that. Start with your hiring process and add requirements for code quality practices. Then build a process that includes strict commit guidelines, documentation, code reviews and QA process. Most importantly, add time to estimates that ensures all of the above is checked properly. After all that is in place, define in a clear way some sort of liability for bugs. Your dentist goes through all of that, why not your developers doing arguably equally important work?
- ht85 7y ago
  Are there 100% medical procedures with 100% success rate? To me it seems that failures happens pretty often, generally due to incompetence, limitations in the science regarding the problem or insufficient resources. Seems very similar to bugs to me. The question is how bad is failure, obviously if someone's health is at risk, you have a much bigger incentive to have processes on the safer side. Maybe you feel "bugs" are more frequent in software because the software you're referring to has an incentive towards innovating rather than stability. I'm sure if you studied software used in critical systems, the failure rate would be more in line with a procedure at a dentist. You can't justify the kind of cost that kind of development has for most apps.
- wooby 7y ago
  I believe the answer to your question of why developers don't generally treat quality the way dentists do is one of economics. The world needs enough software, and the world's requirements for quality are low enough, and the average developer writes reliable-enough code, that in most cases money can be made without special attention to quality. In some domains, quality is paramount. I imagine that quality and bug mitigation are the primary concerns of someone who manages, say, an X-ray machine firmware project, or avionics software. Software for these purposes that is not extremely reliable cannot compete in that market. For other kinds of software people are paid to write -- like social networks for pets -- reliability is a much lower priority. Certain kinds of software needs to be rewritten constantly to meet the demands of highly-evolving markets. Games are an example of this. Reliability is important, but not paramount, because the underlying business can only continue to compete by at some point stopping work on the reliability of existing games, and moving on to developing new games. I'm sympathetic to the respect you have for the value of high quality software. But the reality is, the value of quality varies dramatically within the software industry -- much more than it does within, say, dentistry, or medicine, or aviation. Fewer bugs isn't necessarily the primary concern of those using and buying any particular kind of software.
jes5199 7y ago
there is an assumption here that I want to challenge: that code can be correct. Code is _always_ a flawed approximation of an ideal system. You can move bugs around, but you cannot get rid of them: software _is_ bugs.
twic 7y ago
> Through this lens, apologizing for bugs may seem innocuous. But it contributes to a bunch of cultural anti-patterns: > * 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. Imagine writing this. Imagine actually sitting down at your keyboard and writing down that people should not be striving to write bug-free code.
- flohofwoe 7y ago
  Doh, of course no programmer intentionally writes buggy code, yet there isn't a single programmer in the world who doesn't write buggy code (and everybody who claims to write 'bug-free code' is either very inexperienced or a goddam liar). The point is to not have a "shame culture" for writing bugs, because they are normal part of the workflow. Instead focus on efficiently identifying and fixing bugs (efficient debugging is an important skill that's unfortunately often neglected). Otherwise you end up with people writing overly defensive code, and get into a situation like the Stalin-era airplane designers who each made their own parts just a bit stronger then necessary because they feared ending up in Gulag or against the wall if it was "their part" that broke. End result was planes that were so much more heavier than planned that they were essentially useless for the tasks they were designed for.
  - twic 7y ago
    Of course we have to accept that bugs will be written. But that doesn't mean we shouldn't feel bad about writing bugs! Feeling bad is an excellent motivator to write fewer bugs! John Carmack put this better than i can [1]: > Left to themselves, most people have a tremendous ability to ignore their flaws, and it hampers their growth. A bit of shame is often a positive motivation. I am ashamed of a lot of code I wrote last year. I have reasons why it is the way it is, some of which are defensible, but some are just “WTF was I thinking?” If you don’t have nagging bits of guilt about your recent body of work, it might well be a benefit for someone to point out problems in terms that break through your defenses. [1] https://www.wanzafran.com/posts/2020/shame-and-code/ https://www.wanzafran.com/posts/2020/shame-and-code/
Buttons840 7y ago
Here's a thought experiment. You write some code and a code reviewer points out that you used an API incorrectly, which you did because the documentation and test environments are out of sync with the production API. You will, of course, modify your code to use the API correctly, but will you "apologize"? Now again, you call the API incorrectly, but your company doesn't do code reviews and they just ship the code. Your code ends up causing a lot of headache for everyone after it runs in production for a month doing the wrong things. Do you "apologize"? Note, what you did is exactly the same in both scenerios. Should you apologize? Are you the only one who needs to apologize? Should everyone apologize? Like, do you all sit in a room together and go through a strange routine where everyone around the table takes turns saying "I'm sorry". I'm surprised by all the disagreement over this post, so I wonder what people would think of these scenarios.
- catalogia 7y ago
  > You write some code and a code reviewer points out that you used an API incorrectly, which you did because the documentation is out of sync with the actual API. You will, of course, fix the mistake, but will you "apologize"? If it was feasible for me to catch the erroneous API behavior through testing, before code review, I would see no reason to not apologize. Your second scenario is not even remotely ambiguous, of course I'd apologize if I caused other people that much hassle.
  - kragen 7y ago
    It's always feasible to find a bug by testing. Even in the case where your code relies on some accidentally convenient behavior that might disappear in the next version of the API, you could have reimplemented the API as a stub in your test from only the documented interface. But it's often more efficient to find bugs through code review.
- bradhe 7y ago
  Why is apologizing (that is, accepting responsibility) for an error that you made--in either case, it's an error that you made--such a problem? This seems to come from a place of deep insecurity. Stop tying your identity to your work.
mannykannot 7y ago
> It reinforces the idea that any one person or piece of code can be blamed for a given failure. Short of malice, this is never the case. If I make an off-by-one error, where, other than me, did it come from? > 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. If I make an off-by-one error, I could have done better. > 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. It is not about shame, it is about responsibility. > 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... We should all aspire to do better. > ...They may feel ashamed if their code has bugs. See my previous comment on shame. About the only thing that annoys me at work is people trying to deny responsibility for their actions (or lack of them.)
- vb6sp6 7y ago
  > About the only thing that annoys me at work is people trying to deny responsibility for their actions (or lack of them.) Someone once said "There is a difference between 10 years of experience and 1 year of experience 10 times". The best developers I know always take responsibility and try to do better.
  - ignoramous 7y ago
    The point being made is how bugs invoke an automatic admission of guilt in developers, and absence of which shouldn't be seen as not taking responsibility, especially when tranches and layers in the system (built over the years, say) could have made the entire debugging and development process cumbersome, uneasy, unconventional, unyielding, dense, exhausting, and frustrating. Taking responsibility might involve any among: - documenting the behaviour for future maintainers. - writing tests. - identifying and pushing the management to fix technical debts. - digging up the root-cause to fix deeper flaws, if any. - advocating for saner development and deployment practices. - ...
- iamthepieman 7y ago
Traster 7y ago
Every once in a while a barrista is going to forget to you wanted soy in your triple venti no-foam soy latte instead of whole milk. They're serving a thousand drinks a day and the impact of getting the order wrong is tiny. They're still going to apologize to the customer who got the wrong drink. Because sometimes mistakes are acceptable, expected on occassion, and still worth apologizing for when they happen. I don't always say sorry when I do something wrong, I sometimes say sorry when what I've done has a bad impact on someone.
- PaulOlteanu 7y ago
  On the other hand, I (and probably a good amount of other people) say thanks after getting our coffee, but I think it would be pretty ridiculous to expect to be thanked for every feature I create.
eximius 7y ago
This seems to conflate ownership/responsibility with admitting a flaw in yourself. If someone points out a bug, I say thank you. People make mistakes. I am a person. I make mistakes. This is not controversial, it is expected. We should still strive to avoid them and are allowed to be annoyed with ourselves when we make them, but it doesn't make us bad people.
dilap 7y ago
I am in complete disagreement with this sentiment! If you're using my code and hit a bug, I am, genuinely, sorry. The goal state is craft software that works properly. That is not an unreasonable goal! Of course, mistakes will happen, but you should be sorry, and you should think about what would have avoided it (better programming methodology? better testing?). Aim to create high-quality software that delights its users!
- zeroimpl 7y ago
  Apologizing and feeling sorry are two different things. If you say sorry for every bug, the word will lose meaning.
  - dilap 7y ago
    I'm not like on my knees begging for forgiveness, but I feel regret that an unfortunate thing happened. To me it's a similar situation to if I, say, accidentally spilled your drink; something of that nature. (I guess different people could attach different amounts of significance to the word. To me it simply means, "I feel sympathy that this unfortunate thing happened, and I wish it had not.")
JoeAltmaier 7y ago
Switch from apologizing, to thanking the person that found the issue. Profoundly different effect. One is all-about-you. The other is a team-building action, recognizing the folks who normally get a lot of grief(denial; accusations; ignoring their input). Testers respond amazingly when they're heard and treated seriously. It is so profound, let me tell you an anecdote. My test lead had gone to a conference (they have them!) He was in a bar at the end of the evening, shooting the breeze about all the type-A developers they have to deal with, with a group of attendees. He told the group "I have a guy in my company, I find a bug, he thanks me! Then works closely to categorize and then fix it. No complaining; no yelling. He just says Thank You! and gets on with it. Says I saved him embarrassment if the bug had gone any further, and saved the company money." Another guy in the group, from a different company in a different state, said "I know who you're talking about. I'll write his name on this napkin, you tell me if I'm right". He wrote my name and passed it over. They had never met; never working the same companies at all. Were in different places in their careers. But I had worked with both of them. One of them, 8 years before. But still, still I was the only developer either of them had ever dealt with, that responded positively to a bug report. Think about it, and then go thank your tester.
- fishmaster 7y ago
  That definitely happened.
  - hkai 7y ago
    It probably didn't happen but i like the story anyway.
    - JoeAltmaier 7y ago
      Yes, it did happen. One had gone from our startup, to a senior test Engineer at Microsoft. The other has gone thru Engineering test lead, to VP Engineering, to owner/operator of a Falafel joint. Anyway it was 15 years ago. Things were different then.
- kqr 7y ago
nogabebop23 7y ago
Maybe as a Canadian we've eroded the stigma with apologizing. Saying you're sorry is not about taking blame or responsibility; this attitude is what stops an overly litigious society from saying "sorry". It's an empathetic response that says "I am putting myself in a different context and trying to understand how it feels". This makes it perfectly appropriate to say "I am sorry" a lot more than we do: when learning about a friend's bad-luck circumstances, a customer's poor experience or adding a bug to your code.
andersource 7y ago
It's interesting how polarizing this article is. After zigzagging several times while reading the comments I just think that reality is more nuanced than "never apologize" or "apologize", and it simply depends on the context. It seems to me that most comments with a strong opinion (including the article) have a specific scenario in mind, involving assumptions about the dev's intentions to write good code, the bug's effect, how easy it would have been to avoid the bug, and who is this person we're considering to apologize to (coworker / manager / customer / QA who found the bug). In some situations apologizing feels right, in others it doesn't, so there's not much sense in generalizing from a single scenario to the general case. I think ultimately it comes down to matching expectations: almost all people involved in software development expect bugs. The question is how much effort do they expect me to put into reducing the quantity and severeness of those bugs. When I go to a dentist I expect them to make every possible effort to avoid harming me; generally this is not the expectation of software developers going about their day. A feature that takes one hour with reasonable effort at ensuring quality could easily take a day or a week if you make _every possible effort_ to ensure it is bug-free. Different pieces of code (at different times) could have different amounts of impact, so it takes a wider understanding of the code's context to decide how much effort I'm going to put into chasing bugs. When in doubt, I match expectations with the relevant stakeholder(s). Then the situations where apologizing feels right are either those where I didn't meet the expectations, e.g. I was in a hurry to push so I didn't take the time to properly test and I should have known better (not very frequent); or situations where I didn't take the time to properly match expectations (though sometimes that's on the other party, but it takes two to match expectations). One other thing regarding responsibility - I think that taking responsibility and apologizing are different things. Sure, you can take responsibility by apologizing, but there are other ways too. When something breaks in my apartment and I call my landlord, they (usually) take full responsibility and make sure the problem is fixed, but so far they never apologized, and it would feel funny if they did.
joesb 7y ago
While I agree with not "blaming" people for the mistake as if it's their fault as a person. I disagree with all of his reasoning and the action he choose not to do in this case. I also take the position of "criticizing the idea/code, not the people" when it comes to other people's work. I rarely have a problem with criticizing myself. Especially when it comes to "your" own code. You should be able to apologize for your mistake. > It reinforces the idea that any one person or piece of code can be blamed for a given failure. Short of malice, this is never the case. You can be attributed to your action. If you can be attributed to the good things in your work, then you can be attributed to bugs. Unless you are claiming that you have no control what so ever about how your code turns out, at which point, what are the different from you and a typewriter? The thing is, you can be attributed for an instance of error. You can be blamed for the error you did. But you should never be categories as "the error". > 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. Yes. There are instances that I could have written it better. > 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. > 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. I take the approach and culture of "be strict with yourself but be kind to others". When I talks about other people's bug I always criticize the bugs itself and talks about problem and process in general without tying it to them. But when I talked about my code, I will also express what I could have done better or what is the pros and cons of my coding decision. The thing is there's different between people striving to better themselves, and people blaming others for not being better. You should strive to be better, while at the same times not being a snob or looking down on other for not being perfect. In every day's life there's no permanently good people or bad people. There's bad action that people do. You should still be able to attribute a certain instance of event to a person. You just don't have to hold grudge and judge them forever based on it. I am probably reaching it here, but I feel that the author is the kind of person that can't take criticism of his idea well because he feel that his idea is himself. Your idea and action is yours. But your idea and action is not who you are. If you think it is yourself, then you become blindly defensive and either never acknowledge that you did it, like the author did, or never change.
chadlavi 7y ago
People were apologizing? My instinct is always more like, "oh, nice catch!"
zerpelin68 7y ago
This touchy-feely analytical approach to not worrying about emotional and exemplary damage resulting from not knowing any better is hard to take. The self importance of not worrying is conducive to the sloppy industry the NG works in. No one can be held responsible for not knowing what they should know because they aren't expected to know it. They are semi-functional components in a dysfunctional machine.

130 points by dsr12 7y ago

I agree about not apologizing for bugs. But I disagree about it being something special to leaders. And the way he says it, makes it sound like maybe he thinks leaders shouldn't apologize in general. Which I think is a fairly common belief that leaders use to justify not admitting they made a mistake. And is 100% different from not apologizing for bugs. Since as he points out, bugs are not mistakes, they are a normal part of development. When the manager makes a significant mistake it's not like a bug, it's a poor judgement that probably affected everyone. And sometimes if it's a very negative affect then an apology is warranted. But at least, it's usually necessary to acknowledge when you had people going in the wrong direction.

deleted 7y ago
[deleted]

Negitivefrags 7y ago

So sure, bugs happen, regardless of how good you are. But there really are some people who constantly make mistakes, and those that rarely do. There are people on my team where, when there is a bug, I just start looking at diffs of what they have committed because more likely than not, they caused the problem. I think it's important to reinforce an attitude of trying to become better and people who give a shit when they make mistakes tend to also be the ones who make less of them.

deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
erikbye 7y ago
> There are people on my team where, when there is a bug, I just start looking at diffs of what they have committed because more likely than not, they caused the problem. If you can tell the bug from looking at diffs, why was the bug not caught in code review or by tests? Most obvious bugs should be caught this way.
- lidHanteyk 7y ago
  In my experience, it's because Thing 1 and Thing 2 can review each others' code, and have no compunctions about potential bugginess. Somebody else gets to pick up after both of them, and is always outvoted during team code review. It's like giving a minority report, honestly.
  - danenania 7y ago
    Code review also isn't great at catching the kinds of edge cases that lead to many production bugs. Even tests only help you so much, because if you forget about input X or state Y or api result Z while writing the code, you're likely to forget about it when writing tests too. This is why bugs are more or less inevitable in systems beyond a certain level of complexity that are being actively worked on, and why engineers who think very carefully about anything that could go wrong will produce far fewer bugs than sloppy engineers who try to use process as a safety net.
Libeste 7y ago
It's more important to identify the root of the problem and actually solve it. Even if these people suck at coding and are still committing code without someone else double-checking their work, they're not the real problem.

malikolivier 7y ago

As a manager, I've always striven to apologize for my errors. I do agree that errors are unavoidable and are bound to happen. That's why I actually never cared at all whether programmers apologize for bugs. Fixing bugs is also part of the software development process after all. However, I've always believed an apology is important to show humility to my team mates. As a manager, I do not want to appear entitled. Of course, as soon as the error is uncovered, we should prioritize it and fix it. But I do not believe that proceeding to fixing an error is orthogonal to apologizing for it. We are trying our best to build a company without a guilt culture. In such a position, is apologizing a bad move as a leader? What would you do?

lenzm 7y ago
I'm a manager and I appoligize if it was a stupid mistake made from carelessnes. Apologize if you did something you wouldn't want other people doing. I think context matters too. The industry you're in (what are the consequences of bugs) as well as the part of the codebase (presentation or data integrity) change the acceptability of bugs.

jon889 7y ago

Maybe don’t apologise for it, but I definitely think it’s useful to acknowledge if it was your code as it removes an awkwardness around it. Obviously this doesn’t have to be done for every little bug but if there’s a discussion around one then owning it can help.

Angostura 7y ago

He says that this is a fallacy: > It reinforces the idea that any one person or piece of code can be blamed for a given failure. Why is that a fallacy?

ithkuil 7y ago
Probably because there is always a bigger picture: culture, process (e.g. testing, code review, time pressure, feature centric performance metrics). Surely, the person making the mistake is the proximal cause for a given bug, and surely all other things being equal personal attitude matters (i.e. a more careless person is going to make more mistakes), but if you zoom out to the big picture you see other responsibilities and more importantly you see opportunities for improvement that vastly exceed the playoffs of "just putting more care" into each commit.
- Angostura 7y ago
  Understood. Thanks for the explanation. I have to say I don’t intuitively like the position, because taken broadly you could conclude that no-one in an organisation is ever personally responsible for their actions, because some system should have prevented the mistake. This feels wrong
  - ithkuil 7y ago
    Indeed, it does feel wrong because it is, technically, wrong. The intent of a "no blame culture" however is to find a new sweet spot on the myriad of tradeoffs an engineering organization does, as an many paradigm shifts we do, it is accompanying with a certain amount of bullshit-sounding maxims meant to be thought provoking and dislodge the readers from their suboptimal local maximums.
redis_mlc 7y ago
Conceptually, there's supposed to be a process that reduces errors, rather than relying on each individual to be infallible.
lenzm 7y ago

old-engineer 7y ago

Would you be ok with your dentist being OK with her slip-ups? “I really should have checked the x-ray better before I extracted your front tooth. But you know, I’m not sorry. It was an external constraint — there was a queue of patients waiting”. I can’t believe how low we let this profession sink. I hope in 15 years we will look at thies era like we look at the Wild West today. Exciting from a distance but nobody would really like to live like that.

sairamkunala 7y ago
This comparison is like comparing apples to oranges. I believe we need to get the "context" before judging any situation.
- old-engineer 7y ago
  What I think should be common in these two cases is the attitude of a professional towards their work. Building software should be an engineering discipline with all its perks and responsibilities just like building bridges. We rarely see it and it propagates to the craftsmen who seriously believe that good quality software is impossible to write under the slightest of constraints. Like business pressure. We had this ability in the past when programming was way more difficult, tedious and error prone. Look what IBM did with their “Clean Room” approach. I’m sure we still have it at many places but we choose to spread the myth that it cannot be done. This call to stop apologizing is the next step towards not even trying.
  - sairamkunala 7y ago
    > What I think should be common in these two cases is the attitude of a professional towards their work. I think everyone would not deny this fact. Engineering is more of a discipline. But if you see things practically, this issue of "bad" code may not happen for various number of cases. For example, unclear project requirements, use cases etc., That is where 'context' of what happened helps to better understand the situation. Building bridges are not done agile and it has a learnings from decades or even centuries. Computer Engineering is mostly agile where you push changes based on changing requirements.

yborg 7y ago

This sentiment reminds me of Gerald Weinberg's observation of four plus decades ago - "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." I was trained as a computer engineer, and the difference between those who were taught to approach software development as a craft and those who think bugs are ok and it's really about feeling good about myself at the end of the day is clear and obvious in most organizations and in the product that comes out of them.

danenania 7y ago
At the same time, if programmers had to deal with the same kinds of rigid constraints as builders, writing a simple MVP would cost millions, and we'd have a lot less new technology in the world.

yxhuvud 7y ago

No, I'm not going to stop taking responsibility for my actions.

thdrdt 7y ago

Well there are multiple kinds of bugs. You did not test it? Apologize. You were sloppy? Apologize. In most other cases I can agree with the author. All I can add is that, as a freelancer, I always explain (like they are 5) what went wrong. My customers don't care about the details but they like it when they know I made an effort of creating good software (bugs included).

aeno 7y ago
> You did not test it? Apologize. Not on every case. I once had a customer who literally removed the "Testing" part of my offer because it seemed to expensive to him. As testing often takes a considerable amount of time I do list it explicitly in an offer and don't "hide" it in the numbers for the other tasks.
- catalogia 7y ago
  Imagine if electricians let their customers opt out of electrical code compliance...

fredsted 7y ago

I think it's worth acknowledging over your customers that the bug has caused them lost time or other kinds of issues. Whether you do that with an apology, it doesn't really matter, but I know I'd personally feel better when a vendor emphasizes with me. Something you definitely don't want is to sound like it's an inconvenience for you that they're reporting bugs. Bug reports are extremely helpful and you should be grateful that they're taking the time to report them to you.

erikbye 7y ago
> I think it's worth acknowledging over your customers that the bug has caused them lost time or other kinds of issues. As a company, by some PR representative, yeah, sure, maybe, but individual developers should not apologize.
- fredsted 7y ago
  I guess it depends. As a solo entrepreneur, I do it all the time, because I care about my customers. Working at Instagram, probably not, since it wouldn't be my job to handle support.

abete 7y ago

Bugs categories are also important. My project and my leadership was destroyed when a non-technical wanna-be "operation" manager without experience in software development, started to see only bugs and reduce all development to bug fixing. Some "bugs" are in reality wrong or misunderstood requirements. Some are missing features. Sometimes the joke "it's not a bug it's a feature" is real. Sometimes "bugs" are edge case we didn't want to solve immediately, until the edge case it's not edge anymore. I think what is dangerous it's seeing ONLY bugs, focus dev ONLY on bugs. Shift a little the point of view from bug fixing to software evolution.

kinkrtyavimoodh 7y ago

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.

catmanjan 7y ago
I have never heard of a plumber, dentist or electrician apologizing for anything - unless you count court orders...
- kinkrtyavimoodh 7y ago
  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.
  - lvturner 7y ago
    Mine has - my plumber didn't apologise, but he did instruct me over the phone how to properly apply PTFE tape.
  - stanmancan 7y ago
    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.
    - 7y ago

jwr 7y ago

I earn a living from my SaaS. I am a solo founder, responsible for everything. I wrote all the code. My customers pay subscription fees because the software makes their work easier (it's a B2B SaaS, https://partsbox.com/ https://partsbox.com/). Bugs are solely my responsibility: there is no one else to blame. And bugs mean that my customers paid money for a product which did not work as intended (certainly not as I intended it to work). I feel it is definitely right to apologize for bugs! I disagree with the author: if I worked at a workshop and dropped a hammer onto my customer's foot, I should apologize. No matter what the reason: I could be clumsy, or you could say that no one could be expected to never drop a tool — still, an apology is in order, because I did drop that hammer, and it made my customer's day worse. Therefore, I always apologize for bugs. What I did, however, learn to do, and it is quite important, is not to apologize when you are not sorry. An example is when a customer is unhappy with the pricing, or complains about a missing feature. Many people will begin a reply with "I'm sorry, but…", and it's the wrong thing to do. I only say I'm sorry when I really am.

cl3misch 7y ago
I think the article is talking about (not) apologizing to your coworkers, not costumers.
- dingaling 7y ago
  Co-workers are customers too. Everyone who has a dependency on your code is a customer.

brujoand 7y ago

If you fuck up I don't really care about an apology. I want to know: 1. How will you fix it? 2. How will you prevent it from happening again? An apology, in my head atleast, is for when you have caused emotional distress to someone and there isn't much you can physically do to fix it other than to convey how you now feel about what you have done. When you make a practical mistake an apology is implied by you fixing it.

twic 7y ago
There are perhaps two parts to an apology. One is an acknowledgement that you did something wrong, and that you should not have done it. The other is a sort of ritualistic, performative (in the original sense!) use of language that may make someone feel better. This is the difference between: "I made a mistake when i dereferenced that null pointer" and: "I'm sorry i dereferenced that null pointer" I absolutely agree with you that the ritualistic part is pointless, and perhaps harmful if it is performed instead of actually fixing the problem (see also "thoughts and prayers"). But i wouldn't want to stop doing the acknowledgement part.
- zeroimpl 7y ago
  I wouldn’t refer to the first stage as an apology, it is simply an acknowledgement. I very rarely apologize for a bug at work. I don’t expect others to apologize to me either. Apologies should be reserved for personal/relationship things, like forgetting to invite somebody to a meeting.

Kapura 7y ago

Shipping with bugs is not an inevitability. Bugs come from code being used in cases other than the ones that the programmer anticipated. But it is possible to understand how code will be used. You can test against it, either manually or with some automated testing tool. And you can produce code that behaves the way you expect it to every time you run it. Every once and a while you might mistype >= as <=, but you can catch it and fix it with only a modicum of effort. But you first need to believe it is in your own power to write less buggy code. If you can identify patterns that frequently produce bugs, you can try to avoid them (e.g. copying & pasting: very buggy!). You can identify, isolate, and document footguns and complex API. And you can be proactive in simplifying systems when feasible to do so. Don't beat yourself up if you accidentally have a bad commit, but don't excuse sloppy behavior. Demand better from yourself. Don't produce garbage software.

diebeforei485 7y ago

Particularly for entry-level folks: if your code passed code review, it means others didn't catch the bug either. The company could apologize to customers if needed. But it would be insane to make the individual developer apologize to customers.

KhalPanda 7y ago

A lot of the replies and analogies here are interpreting this as a business-consumer apology. Of course if a business has disrupted a customer's experience through buggy software they should issue post-mortem/apologies/etc. But I read this as though the author is saying apologies to fellow teammates shouldn't be necessary, which I do at least in part agree with.

deleted 7y ago

[deleted]

twelve40 7y ago

This reads a bit like one of those feel-good "managers should be good to employees! agree?" posts on linkedin. The bugs I see in PRs from even some mature people are things like input_array[0] without checking the array for null or size. Anyone beyond cs101 can tell you this is unacceptable and careless, and the author likely had a "fuck it" attitude, and was in a hurry to get back to Netflix or whatever was really on their mind. Should we expect for them to go into a full-on dogeza Japanese kneeling bow apology? Of course not. But there are many cases where a person glaringly half-assed something, cut corners, quietly committed something directly to master. And yes, this person should feel some kind of regret, or should be brought to stop such behavior because it is extremely destructive and is totally avoidable and caused not by overworking or accident but by persistent carelessness and neglect, so it cannot just be cheerfully swept under the rug.

commandlinefan 7y ago
> there are many cases ... where a developer was given 30 JIRA tickets each "sprint" and whose "performance" was evaluated entirely on how many they completed.
roosterdawn 7y ago
Why doesn't your team have a process (integration tests, etc) that makes it impossible to check in something like `input_array[0]` without breaking a build? Why is it allowed to directly push to master? How does the old saying go? The road to where is paved with good intentions? You could engage in moralizing against "carelessness" and "neglect" and presuming that a teammate somehow cares more about watching Netflix than doing their job (which they presumably outperformed other candidates to even get), and maybe that will make you feel better. You are the good, careful, model employee, and that other one -- they're careless, slovenly, apathetic and lazy. But if that's the case, how did they get past the door in the interview process? If the whole company is like that, why do you work there as opposed to a company where the bar is higher? Something does not add up. In all likelihood, your explanation is a rationalization and not the most obvious answer, which is that your process could be improved but it hasn't been because such investments are not viewed by your companies executives as improving the long term bottom line to be worth the short term investment cost. Take a look at history and figure out how companies in the industry have solved this problem before by building more bulletproof runbooks, processes and tools. These companies, as they approach enormous scale, necessarily have to determine how to deal with employee reversion to mean. It turns out, surprisingly, that process eats good intentions and care for breakfast. You'd be surprised at how quickly those good intentions become useless if your company is successful and you hit hypergrowth and scale. It's ironic that for a profession where it is so tractable to automate away mundane or repetitive tasks, where we study spacetime complexity in data structures and algorithms, that we have so many practitioners that default to witch hunting and moralizing and seem unable to apply spacetime complexity or procedural analysis to their own software development lifecycle. I expect to see this trend change as our still young industry continues to mature.

h91wka 7y ago

To commenters who compare work of programmer with the work of civil engineer: There is an explanation to this discrepancy. Risk = probability of fault * cost of fault. Programmers usually work with the data. Data has a pretty very unique property that it is easily and cheaply copied and restored. It also means data can be replicated more easily, which allows to build systems with large amount of redundancy. Therefore, price of a software bug is usually orders of magnitude less than the price of breaking something in the physical world. This allows to drive up probability of fault parameter and allows for much faster evolution and less regulation.

mdtusz 7y ago
I think a part that needs to be considered in the comparison is also the concept of safety factors. Many structural engineering projects are built with a safety factor greater than 1, which allows for - as you'd imagine - safety. In software, it could absolutely be done that every function has explicit validation checks for each input, and that more safety, error handling, and checking is written. The economics just don't make that viable though except in the most extreme situations where this is required. In aerospace, with the exception of the recent Boeing debacle, there's been very few software related issues (that I know of) relative to the number of CPU cycles run and flights taken - I'd be willing to be there's far more mechanical issues that cause grounding and maintenance cycles. Now look at civil engineering and infrastructure. How many roads do we drive over daily filled with potholes? How many bridges get patches and repairs every few years because of concrete cracking and rebar rusting? (I live in Quebec, so there may be bias in this statement). Maintenance like this is just paying down tech-debt - the same as in any field. Software absolutely can be built to a high level of robustness (and it is) - it's just not economically sensible in most cases.
cryptonector 7y ago
Replication costs have nothing to do with anything here. The damage caused by a software bug can range from nil (even negative, since a bug might have desirable effects) to incalculable. Consider a bug in software used for landing SpaceX boosters... Or a bug in a trading platform. Or a bug in an automated medicine dispenser. Or... You can compare the work of a programmer to the work of a civil engineer, but it's true that it's difficult because most bugs cost little, much software is not positioned to cause much damage if buggy, software bugs are so prevalent, and it's so difficult to write bug-free code. But the cost of replication of software has nothing to do with any of this.

bryanrasmussen 7y ago

I wish I could find that one guy I worked with about 19 years ago that tried to load an ActiveX component in his VbScript running in Netscape and send him this article, true he never apologized - but I just want to make sure he doesn't feel bad about never apologizing.

gwbas1c 7y ago

The biggest career lesson that I've had is that 80% of development is testing. Should you apologize for bugs? No. But if you're doing professional quality work, (as opposed to prototyping or researching,) a large portion of your time (as a developer) should be writing automated tests (like unit tests) to test the code you write.

freediver 7y ago

Bugs are the responsibility of the process that brought them there. In most cases it is shared responsibility. Why doesn't your dentist mess up 1 out of 5 interventions? They have gone through years of strict training and there are giant liabilities in place. In development? A lot of self-taught developers, who can always jump to a next gig because of never-ending demand. This sets up the scene for a totally different scenario - never-ending stream of bugs. If you want your team to have less bugs, then as a manager make sure you have a process in place that optimizes for that. Start with your hiring process and add requirements for code quality practices. Then build a process that includes strict commit guidelines, documentation, code reviews and QA process. Most importantly, add time to estimates that ensures all of the above is checked properly. After all that is in place, define in a clear way some sort of liability for bugs. Your dentist goes through all of that, why not your developers doing arguably equally important work?

ht85 7y ago
Are there 100% medical procedures with 100% success rate? To me it seems that failures happens pretty often, generally due to incompetence, limitations in the science regarding the problem or insufficient resources. Seems very similar to bugs to me. The question is how bad is failure, obviously if someone's health is at risk, you have a much bigger incentive to have processes on the safer side. Maybe you feel "bugs" are more frequent in software because the software you're referring to has an incentive towards innovating rather than stability. I'm sure if you studied software used in critical systems, the failure rate would be more in line with a procedure at a dentist. You can't justify the kind of cost that kind of development has for most apps.
wooby 7y ago
I believe the answer to your question of why developers don't generally treat quality the way dentists do is one of economics. The world needs enough software, and the world's requirements for quality are low enough, and the average developer writes reliable-enough code, that in most cases money can be made without special attention to quality. In some domains, quality is paramount. I imagine that quality and bug mitigation are the primary concerns of someone who manages, say, an X-ray machine firmware project, or avionics software. Software for these purposes that is not extremely reliable cannot compete in that market. For other kinds of software people are paid to write -- like social networks for pets -- reliability is a much lower priority. Certain kinds of software needs to be rewritten constantly to meet the demands of highly-evolving markets. Games are an example of this. Reliability is important, but not paramount, because the underlying business can only continue to compete by at some point stopping work on the reliability of existing games, and moving on to developing new games. I'm sympathetic to the respect you have for the value of high quality software. But the reality is, the value of quality varies dramatically within the software industry -- much more than it does within, say, dentistry, or medicine, or aviation. Fewer bugs isn't necessarily the primary concern of those using and buying any particular kind of software.

jes5199 7y ago

there is an assumption here that I want to challenge: that code can be correct. Code is _always_ a flawed approximation of an ideal system. You can move bugs around, but you cannot get rid of them: software _is_ bugs.

twic 7y ago

> Through this lens, apologizing for bugs may seem innocuous. But it contributes to a bunch of cultural anti-patterns: > * 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. Imagine writing this. Imagine actually sitting down at your keyboard and writing down that people should not be striving to write bug-free code.

flohofwoe 7y ago
Doh, of course no programmer intentionally writes buggy code, yet there isn't a single programmer in the world who doesn't write buggy code (and everybody who claims to write 'bug-free code' is either very inexperienced or a goddam liar). The point is to not have a "shame culture" for writing bugs, because they are normal part of the workflow. Instead focus on efficiently identifying and fixing bugs (efficient debugging is an important skill that's unfortunately often neglected). Otherwise you end up with people writing overly defensive code, and get into a situation like the Stalin-era airplane designers who each made their own parts just a bit stronger then necessary because they feared ending up in Gulag or against the wall if it was "their part" that broke. End result was planes that were so much more heavier than planned that they were essentially useless for the tasks they were designed for.
- twic 7y ago
  Of course we have to accept that bugs will be written. But that doesn't mean we shouldn't feel bad about writing bugs! Feeling bad is an excellent motivator to write fewer bugs! John Carmack put this better than i can [1]: > Left to themselves, most people have a tremendous ability to ignore their flaws, and it hampers their growth. A bit of shame is often a positive motivation. I am ashamed of a lot of code I wrote last year. I have reasons why it is the way it is, some of which are defensible, but some are just “WTF was I thinking?” If you don’t have nagging bits of guilt about your recent body of work, it might well be a benefit for someone to point out problems in terms that break through your defenses. [1] https://www.wanzafran.com/posts/2020/shame-and-code/ https://www.wanzafran.com/posts/2020/shame-and-code/

Buttons840 7y ago

Here's a thought experiment. You write some code and a code reviewer points out that you used an API incorrectly, which you did because the documentation and test environments are out of sync with the production API. You will, of course, modify your code to use the API correctly, but will you "apologize"? Now again, you call the API incorrectly, but your company doesn't do code reviews and they just ship the code. Your code ends up causing a lot of headache for everyone after it runs in production for a month doing the wrong things. Do you "apologize"? Note, what you did is exactly the same in both scenerios. Should you apologize? Are you the only one who needs to apologize? Should everyone apologize? Like, do you all sit in a room together and go through a strange routine where everyone around the table takes turns saying "I'm sorry". I'm surprised by all the disagreement over this post, so I wonder what people would think of these scenarios.

catalogia 7y ago
> You write some code and a code reviewer points out that you used an API incorrectly, which you did because the documentation is out of sync with the actual API. You will, of course, fix the mistake, but will you "apologize"? If it was feasible for me to catch the erroneous API behavior through testing, before code review, I would see no reason to not apologize. Your second scenario is not even remotely ambiguous, of course I'd apologize if I caused other people that much hassle.
- kragen 7y ago
  It's always feasible to find a bug by testing. Even in the case where your code relies on some accidentally convenient behavior that might disappear in the next version of the API, you could have reimplemented the API as a stub in your test from only the documented interface. But it's often more efficient to find bugs through code review.
bradhe 7y ago
Why is apologizing (that is, accepting responsibility) for an error that you made--in either case, it's an error that you made--such a problem? This seems to come from a place of deep insecurity. Stop tying your identity to your work.

mannykannot 7y ago

> It reinforces the idea that any one person or piece of code can be blamed for a given failure. Short of malice, this is never the case. If I make an off-by-one error, where, other than me, did it come from? > 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. If I make an off-by-one error, I could have done better. > 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. It is not about shame, it is about responsibility. > 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... We should all aspire to do better. > ...They may feel ashamed if their code has bugs. See my previous comment on shame. About the only thing that annoys me at work is people trying to deny responsibility for their actions (or lack of them.)

vb6sp6 7y ago
> About the only thing that annoys me at work is people trying to deny responsibility for their actions (or lack of them.) Someone once said "There is a difference between 10 years of experience and 1 year of experience 10 times". The best developers I know always take responsibility and try to do better.
- ignoramous 7y ago
  The point being made is how bugs invoke an automatic admission of guilt in developers, and absence of which shouldn't be seen as not taking responsibility, especially when tranches and layers in the system (built over the years, say) could have made the entire debugging and development process cumbersome, uneasy, unconventional, unyielding, dense, exhausting, and frustrating. Taking responsibility might involve any among: - documenting the behaviour for future maintainers. - writing tests. - identifying and pushing the management to fix technical debts. - digging up the root-cause to fix deeper flaws, if any. - advocating for saner development and deployment practices. - ...
iamthepieman 7y ago

Traster 7y ago

Every once in a while a barrista is going to forget to you wanted soy in your triple venti no-foam soy latte instead of whole milk. They're serving a thousand drinks a day and the impact of getting the order wrong is tiny. They're still going to apologize to the customer who got the wrong drink. Because sometimes mistakes are acceptable, expected on occassion, and still worth apologizing for when they happen. I don't always say sorry when I do something wrong, I sometimes say sorry when what I've done has a bad impact on someone.

PaulOlteanu 7y ago
On the other hand, I (and probably a good amount of other people) say thanks after getting our coffee, but I think it would be pretty ridiculous to expect to be thanked for every feature I create.

eximius 7y ago

This seems to conflate ownership/responsibility with admitting a flaw in yourself. If someone points out a bug, I say thank you. People make mistakes. I am a person. I make mistakes. This is not controversial, it is expected. We should still strive to avoid them and are allowed to be annoyed with ourselves when we make them, but it doesn't make us bad people.

dilap 7y ago

I am in complete disagreement with this sentiment! If you're using my code and hit a bug, I am, genuinely, sorry. The goal state is craft software that works properly. That is not an unreasonable goal! Of course, mistakes will happen, but you should be sorry, and you should think about what would have avoided it (better programming methodology? better testing?). Aim to create high-quality software that delights its users!

zeroimpl 7y ago
Apologizing and feeling sorry are two different things. If you say sorry for every bug, the word will lose meaning.
- dilap 7y ago
  I'm not like on my knees begging for forgiveness, but I feel regret that an unfortunate thing happened. To me it's a similar situation to if I, say, accidentally spilled your drink; something of that nature. (I guess different people could attach different amounts of significance to the word. To me it simply means, "I feel sympathy that this unfortunate thing happened, and I wish it had not.")

JoeAltmaier 7y ago

Switch from apologizing, to thanking the person that found the issue. Profoundly different effect. One is all-about-you. The other is a team-building action, recognizing the folks who normally get a lot of grief(denial; accusations; ignoring their input). Testers respond amazingly when they're heard and treated seriously. It is so profound, let me tell you an anecdote. My test lead had gone to a conference (they have them!) He was in a bar at the end of the evening, shooting the breeze about all the type-A developers they have to deal with, with a group of attendees. He told the group "I have a guy in my company, I find a bug, he thanks me! Then works closely to categorize and then fix it. No complaining; no yelling. He just says Thank You! and gets on with it. Says I saved him embarrassment if the bug had gone any further, and saved the company money." Another guy in the group, from a different company in a different state, said "I know who you're talking about. I'll write his name on this napkin, you tell me if I'm right". He wrote my name and passed it over. They had never met; never working the same companies at all. Were in different places in their careers. But I had worked with both of them. One of them, 8 years before. But still, still I was the only developer either of them had ever dealt with, that responded positively to a bug report. Think about it, and then go thank your tester.

fishmaster 7y ago
That definitely happened.
- hkai 7y ago
  It probably didn't happen but i like the story anyway.
  - JoeAltmaier 7y ago
    Yes, it did happen. One had gone from our startup, to a senior test Engineer at Microsoft. The other has gone thru Engineering test lead, to VP Engineering, to owner/operator of a Falafel joint. Anyway it was 15 years ago. Things were different then.
kqr 7y ago

nogabebop23 7y ago

Maybe as a Canadian we've eroded the stigma with apologizing. Saying you're sorry is not about taking blame or responsibility; this attitude is what stops an overly litigious society from saying "sorry". It's an empathetic response that says "I am putting myself in a different context and trying to understand how it feels". This makes it perfectly appropriate to say "I am sorry" a lot more than we do: when learning about a friend's bad-luck circumstances, a customer's poor experience or adding a bug to your code.

andersource 7y ago

It's interesting how polarizing this article is. After zigzagging several times while reading the comments I just think that reality is more nuanced than "never apologize" or "apologize", and it simply depends on the context. It seems to me that most comments with a strong opinion (including the article) have a specific scenario in mind, involving assumptions about the dev's intentions to write good code, the bug's effect, how easy it would have been to avoid the bug, and who is this person we're considering to apologize to (coworker / manager / customer / QA who found the bug). In some situations apologizing feels right, in others it doesn't, so there's not much sense in generalizing from a single scenario to the general case. I think ultimately it comes down to matching expectations: almost all people involved in software development expect bugs. The question is how much effort do they expect me to put into reducing the quantity and severeness of those bugs. When I go to a dentist I expect them to make every possible effort to avoid harming me; generally this is not the expectation of software developers going about their day. A feature that takes one hour with reasonable effort at ensuring quality could easily take a day or a week if you make _every possible effort_ to ensure it is bug-free. Different pieces of code (at different times) could have different amounts of impact, so it takes a wider understanding of the code's context to decide how much effort I'm going to put into chasing bugs. When in doubt, I match expectations with the relevant stakeholder(s). Then the situations where apologizing feels right are either those where I didn't meet the expectations, e.g. I was in a hurry to push so I didn't take the time to properly test and I should have known better (not very frequent); or situations where I didn't take the time to properly match expectations (though sometimes that's on the other party, but it takes two to match expectations). One other thing regarding responsibility - I think that taking responsibility and apologizing are different things. Sure, you can take responsibility by apologizing, but there are other ways too. When something breaks in my apartment and I call my landlord, they (usually) take full responsibility and make sure the problem is fixed, but so far they never apologized, and it would feel funny if they did.

joesb 7y ago

While I agree with not "blaming" people for the mistake as if it's their fault as a person. I disagree with all of his reasoning and the action he choose not to do in this case. I also take the position of "criticizing the idea/code, not the people" when it comes to other people's work. I rarely have a problem with criticizing myself. Especially when it comes to "your" own code. You should be able to apologize for your mistake. > It reinforces the idea that any one person or piece of code can be blamed for a given failure. Short of malice, this is never the case. You can be attributed to your action. If you can be attributed to the good things in your work, then you can be attributed to bugs. Unless you are claiming that you have no control what so ever about how your code turns out, at which point, what are the different from you and a typewriter? The thing is, you can be attributed for an instance of error. You can be blamed for the error you did. But you should never be categories as "the error". > 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. Yes. There are instances that I could have written it better. > 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. > 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. I take the approach and culture of "be strict with yourself but be kind to others". When I talks about other people's bug I always criticize the bugs itself and talks about problem and process in general without tying it to them. But when I talked about my code, I will also express what I could have done better or what is the pros and cons of my coding decision. The thing is there's different between people striving to better themselves, and people blaming others for not being better. You should strive to be better, while at the same times not being a snob or looking down on other for not being perfect. In every day's life there's no permanently good people or bad people. There's bad action that people do. You should still be able to attribute a certain instance of event to a person. You just don't have to hold grudge and judge them forever based on it. I am probably reaching it here, but I feel that the author is the kind of person that can't take criticism of his idea well because he feel that his idea is himself. Your idea and action is yours. But your idea and action is not who you are. If you think it is yourself, then you become blindly defensive and either never acknowledge that you did it, like the author did, or never change.

chadlavi 7y ago

People were apologizing? My instinct is always more like, "oh, nice catch!"

zerpelin68 7y ago

This touchy-feely analytical approach to not worrying about emotional and exemplary damage resulting from not knowing any better is hard to take. The self importance of not worrying is conducive to the sloppy industry the NG works in. No one can be held responsible for not knowing what they should know because they aren't expected to know it. They are semi-functional components in a dysfunctional machine.