23 ms·

Being Slow to Criticise

181 points by ColinWright 7y ago

deleted 7y ago
[deleted]
PragmaticPulp 7y ago
There's another factor at play in these discussions: Cynicism tends to look smart to outside observers. Cynicism is often mistaken for competence to outside observers. If a piece of software has a specific problem, the person chanting "This software is garbage" is going to look smarter than the people saying "Hold on, maybe this software is this way for a reason". There are various (somewhat weak) studies on the topic. For example: https://www.ncbi.nlm.nih.gov/pubmed/29993325 https://www.ncbi.nlm.nih.gov/pubmed/29993325 > Four studies showed that laypeople tend to believe in cynical individuals' cognitive superiority. A further three studies based on the data of about 200,000 individuals from 30 countries debunked these lay beliefs as illusionary by revealing that cynical (vs. less cynical) individuals generally do worse on cognitive ability and academic competency tasks. Cross-cultural analyses showed that competent individuals held contingent attitudes and endorsed cynicism only if it was warranted in a given sociocultural environment. Less competent individuals embraced cynicism unconditionally, suggesting that-at low levels of competence-holding a cynical worldview might represent an adaptive default strategy to avoid the potential costs of falling prey to others' cunning. In toxic and mismanaged environments, being a cynic from the sidelines can be a better political strategy than being the positive person in the trenches trying to find solutions and compromises.
- TheOperator 7y ago
  Reading that study cynicism was essentially defined as "low trust in others" and competence was ability in a handful of cognitively intensive tasks.
- Hokusai 7y ago
  Cynism also has the advantage that no solution needs to be provided, so you are never wrong. > In toxic and mismanaged environments, being a cynic from the sidelines can be a better political strategy than being the positive person in the trenches trying to find solutions and compromises. Yes. In the best awesome places I have worked, there are great constructive discussions on how to solve problems. If anyone is an environment that cynism is rewarded, run from there. There are better places to be.
  - abnry 7y ago
    >If anyone is an environment that cynism is rewarded, run from there. There are better places to be. This is why I quit Twitter.
    - cutemonster 7y ago
      Quit the app? (Or quit the company as an employee?) Curious about Mastodon, if that's possibly a different experience
      - abnry 7y ago
        Quit the app as a user. It wasn't a platform thing, in terms of technical aspects although there is probably something to be said about how it shapes community, but it was the community itself.
- root_axis 7y ago
  Intersting. In my anecdotal experience cynics tend to speak in a very confident matter-of-fact tone that suggests others are fools for not embracing the cynical perspective. I imagine this gives cynicism an edge because people don't like to be perceived as too gullible or naive.
  - grahamburger 7y ago
    I have found that this can be a dangerous gamble on the part of the cynic. Often the cynic's argument can't even withstand a single clarifying question. The first person to ask "can you explain in detail why this won't work?" can often elevate themselves above the level of the cynic, sometimes humiliating the cynic in the process. I have experienced this from both perspectives and as a bystander. Today I try as much as I can to be the problem-solver instead of the cynic. I try to do it in a way that gives the cynic a way to save face, though - it's almost never a good strategy to humiliate a team member.
    - zimpenfish 7y ago
      > The first person to ask "can you explain in detail why this won't work?" Unfortunately, in some forums, that often leads to that person suffering a barrage of negativity whilst the cynic ignores the question in favour of blustering elsewhere.
      - tilolebo 7y ago
        Exactly, someone else will just pop in the thread and post a provocative/insulting GIF/pic, and that's it, you'll have lost the argument. I'm looking at you, Twitter...
- mewpmewp2 7y ago
  I think the same thing is going on with the commentary on economy currently. Whenever I browse around Reddit for example the comments that get upvoted are the cynical ones, "markets are irrational", "feds are pumping up the stocks" etc, but they do not put any real thought into what is happening with the markets and why.
  - gerland 7y ago
    That's a bit off-topic, but what do you think is happening? I'm considering buying some s&p500 based stock, but I'm a bit afraid. What do you, anonymous stranger on the interweb think?
    - mewpmewp2 7y ago
      I have many thoughts on this topic, I'm not an expert and many of these are theories up with so the may also be flat out wrong, but I just disagree with the sentiment that markets are irrational or it's just feds pumping up the stock. I think saying those things is dismissive and anti-intellectual. When I'm trying to think about the subject and whether I should invest myself, I'm trying to figure out what are the actual consequences of coronavirus long term and what in general are investor's motivations. Here are few assumptions I make: 1. Stock price is determined by an umbrella of possible consequences and chances for each consequence. These are just examples, but for example there might be 30% chance that we can manage coronavirus while reopening the economy, +50% chances that we will have a vaccine in 1 year period that we can mass-produce etc. For each of those consequences we can think of an appropriate SP500 price (I'm taking SP500 here as an example, but it could be any other index as well). If economy goes back to normal, the SP500 price could go to 3400 again. Investors will try to predict what are the odds and in total stock price should reflect what investors on average think the odds of something to happen are. 2. The way investors react to these possible consequences comes from that specific investor's expectations and long term strategy. It's important to know what is average investors expectations and risk tolerance. If SP500 is 2200 (which it was when people were expecting it to go to 1700) and you expect 90% of chances of SP500 going back to 3400 within 3 years you can determine that you have 90% chances of making 54% returns within 3 years which is crazy good. So at this point it makes sense for most investors to buy in, because even if it goes lower, you will still be making very good returns. Now that SP is at 2800-2900 I think it's still better to buy in than not, but you can't obviously expect as fantastic returns. I bought in and even with a little bit margin, but I have enough margin left to buy in more if stock should fall. I'm investing and looking at least 5-10 years ahead. So it makes sense for investors to buy in now that they are not crippled by fears of what coronavirus might do - it's already quite clear it's not the end of the world even if it might shake up economy further throughout this year. 3. There are possibly some positive long term effects of coronavirus. Increased productivity, tech and automation from having been forced to experiment with WFH etc. I think all of these might increase productivity. I'm speaking of those not to just sound optimistic, but these are something a lot of people don't mention. These are just rough thoughts I have right now, but in conclusion I have decided to buy in since I have determined that in 3-7 years there are very high chances of making very decent returns. I doubt corona can affect us for that long timeframe. Of course it's more risky than usual to buy in right now so if you have low risk tolerance it's up to you. If you possibly need that cash within 1-3 years, then maybe not buy in, but whether you should buy in right now should be determined with when you want to use that money and how much you are willing to risk. Usually more risk means more reward since only people who can handle that risk will be buying (so stocks will be more underpriced when there's more risk and uncertainty). And since I don't want to use that money before 5 years anyway, for me it definitely makes sense to take that risk. Also even if stocks fall just after you bought in you must be able to handle that and not think you did the wrong thing and sell. You likely wouldn't be able to sell in time anyway. Many people are fearful right now which means a lot of people are holding cash or shorting. Once fear subsides, stock will start to climb faster again so you should want to be in before general fear subsides..
- eeZah7Ux 7y ago
  You are confusing cynicism with expressing criticism. They are 100% orthogonal.
chrismsimpson 7y ago
Being slow to criticise, particularly with colleagues you have to work day in and day out with, is critically important. That said, much of the FOSS currently available is either itself crap, or built on libraries and/or toolkits that are crap. I cite specifically anything of the GTK flavour, many popular things built in C/C++, and to a lesser degree QT. Why is this? Writing capstone technology (compilers and languages) is very hard. Many industries start life fragmented, but looking now at the tech landscape, sadly there is more hegemony in the proprietary world than the open source one. If FOSS is ever to be adopted by a wider community that is inviting to newcomers (both users and hackers), this has to be addressed. It is not being addressed, and the power and elegance offered by the tech giants (Swift, C#/.NET etc.) continues to lap open source equivalents. One example I'll cite is Inkscape. I now honestly believe it would have resulted in better software if this has been written once per platform (WinForms/WPF + Cocoa) rather than with GTK. It's years between minor bug releases, and it gets slower with each release. The (just released) 1.0 is unbearably slow (i.e. unusable). I've spent many hours trying to get familiar with the codebase so I could contribute to it. There's no documentation to speak of for developers, and the little that I've grasped so far leads me to thing it's better left to rot. The core is based on Sodipodi, a project abandoned in 2003. FWIW I have started writing a clean room replacement in Swift/AppKit, but I'm considering altering this to Swift/UIKit for iPad so it'll be cross platform (albeit Apple only).
- frenchy 7y ago
  I'm going to guess you're pretty exclusively an Apple user. I think a big part of the problem is that a lot of the people developing FOSS don't have access to Apple's platforms for doing development, and in many cases, even testing. Because of the walls that Apple has set up for it's platform, doing so is often impractically expensive. I think this is part of what is meant by being slow to critisize. Yes, FOSS often sucks on Apple's platform, but it's also useful to understand the factors involved, and what motivates people. P.S. The best of luck in your endevors! I think the world of SVG editors could use some solid competiton.
- narag 7y ago
  That said, much of the FOSS currently available is either itself crap... I understood the article was about criticizing persons and their reasons for doing something. What you say is an opinion on results, an opinion that could be correct. But you can't make a convincing criticism of behaviour based on results, except with better results.
RickJWagner 7y ago
People who are slow to criticize seem wise to me. Maybe they've seen similar situations before, they might have ideas about an optimal outcome.
- cutemonster 7y ago
  Related: I think often when sbd has a seemingly silly idea, there's a good idea just nearby, when tweaking the initial idea a little bit Then good to keep {those who suggested the idea) happy so they'll help out with tweaking and improving the idea
bonestormii_ 7y ago
I love this short post. Software development is fundamentally hard, despite many frequent statements to the contrary by the "everyone should be a programmer" folks. It requires uncommon persistence, and a love (if not an aptitude) of abstract reasoning in pure form. I think the thought process goes like this: "What's he doing?" "He's doing THAT!?" "Why?!" "I don't understand why." "This software is garbage." Some people claim to be able to glance at code and know what it's doing quickly, but it's just not possible to ingest a few thousand lines of self-referencing logic and understand it quickly if it is doing much more than shuttling data between a database and some kind of display rendering. If you've learned to program, you must have learned patience for yourself. You have to show that same patience to the authors of other programs if you want to understand their work. There are many thoughts embedded in their code. It is deeply complex as the person who wrote it.
ohvirginia 7y ago
I see Colin is atoning and reforming from even 1 day ago https://news.ycombinator.com/item?id=23125032 https://news.ycombinator.com/item?id=23125032 This is good
- pm 7y ago
  Colin is talking about criticising implementation decisions in software, in particular unconstructive criticism bereft of context. Colin is criticising your idea, but is also trying to understand how you formed that idea in the first place, in an effort to hedge against the possibility it has good reasons he can't see. He's not just saying, "your idea is garbage".
  - ohvirginia 7y ago
    Weather good in SA yesterday, Adelaidian, also in QLD/ACT. Go out to enjoy it. Better than texting pulled into what you don't know. Yet, maybe you comment here to defend your hypocrisy, not Colin's.
- deleted 7y ago
  [deleted]
- ColinWright 7y ago
  This comment was flagged dead, and I have vouched for it. Please don't downvote it ... it clearly shows an underlying misunderstanding, and as such deserves to be answered. My comment that you reference was an attempt to find the merit in the idea that I couldn't see, but I assumed would be there because I was assuming the proposer thought it was a good one. I was starting from a position of "Well, this person thinks it's a good idea, but I can't see why, so let's see if we can find how it would work, and what problems it solves. Then we can address any potential drawbacks." It was intended to be an invitation to get some discussion about how it would work, what it would do, what problems it would solve, and where the value lay. I was surprised and disappointed that no reply was forthcoming, and the thread died. I guess I just wasn't clear enough, and for that I am saddened.
  - 7y ago
Daub 7y ago
Holding back on criticism is one of the founding principles of the brainstorming technique... that and listening.
- lmm 7y ago
  And research has shown that it's counterproductive. Culling bad ideas quickly makes for better results.
  - ColinWright 7y ago
    That's fascinating ... can you provide references for that research? We've found the careful controlling of criticism to be invaluable in getting ideas up front quickly so they can then be dissected, mutated, co-evolved, and their best points combined. Iterating quickly and ejecting bad ideas quickly has its place, yes, but not always. I'd be interested to see the underlying context for your statement here. Thanks.
    - hnick 7y ago
      This doesn't support the point but the conversation reminded me about something I read a while ago that is related. Maybe you will find it interesting. https://www.psychologicalscience.org/news/minds-business/theres-a-better-way-to-brainstorm.html https://www.psychologicalscience.org/news/minds-business/the... The researchers found that a problem with brainstorming is the verbal component - due to social factors and limited oral and aural bandwidth, less ideas get shared, and people forget what they were about to say. They decided 'brainwriting' is more effective, particularly 'asynchronous brainwriting' which alternates between writing your own ideas in a group, then reviewing others' ideas. This method would support want you want - getting all the ideas out quickly, because people are less likely to hold back, then iterating on them.
      - Daub 7y ago
        In the paper, group brainstorming was conducted between more than 50 individuals. I would say that 10 is the effective maximum.
andrewflnr 7y ago
On reflection, I have kind of an interesting relationship with this thesis. Whether you should be quick to criticize kind of depends on the purpose of the discussion. Maybe in the context of the person writing the code that kills webservers, it was a reasonable idea. It could well be true at the same time that the software creating that context is, in fact, garbage. I tend to think from the perspective of how to build systems tomorrow that are not garbage, so I lean towards labeling as garbage things that cause annoying code to have to be written; it's an optimistic perspective in a certain sense, that things can be better. But if you're going to bother judging past projects, which is already something to be careful with, it seems pretty clear as OP states that you'll learn more about by looking for reasons that the way they did things made sense at the time. With all the pesky humans involved, it may well be a sociological lesson rather than a technical one.
DoreenMichele 7y ago
Social stuff has gotten complicated by living in a world with a global internet. We each individually bring our personal experiences and prejudices to the table and often have no idea what the context is. I got my first experience as a moderator on an email list with about 300 members and they were all "gifted." It was a parenting list for people with gifted kids, basically, and every single person there was used to being the smartest person in the room. So if you disagreed, obviously, you must be an idiot who had no idea what you were talking about. It took a long time to lay some groundwork and convince people they were, for the first time in their lives, hanging out with 299 other people just as smart as they were who had read just as much as they had on the topic and so forth and, in some cases, drawn other conclusions. That felt like a long, hard haul to me and then I quit after about six months because I was relatively new to the forum and my boss basically told me I was stabbing her in the back for doing my job and I was all "I ain't being paid enough for this." because it was a volunteer position. I quit and let her know what she was doing wrong as a going away present, because I'm generous like that. I'm sure my analysis wasn't appreciated. It was most likely interpreted as sour grapes and as me pissing all over her as I left. HN is better than most places about this kind of thing, but it's just hard communicating on the internet and not knowing the same things about the people we are speaking with that we tend to know about people physically in the same room. We haven't gotten all that sorted out yet and we may never sort it out. If we don't sort it out, the result may be massive die back of the human race to a level we know how to cope with. The internet is our opportunity to sort a bunch of things that aren't working well, but I don't know if we are successfully tackling those questions. Perhaps this post by Colin is one small crumb that can move that forward. And perhaps not. Perhaps it will get lost in the crowd and make no real difference.
- ohvirginia 7y ago
  Good. You atone and reform by deletion http://archive.is/KxZff http://archive.is/KxZff My reply is Judging? You project and are unqualified. Victim blaming? OK when I'm a man? The bullied often bully, you hated men for years. Think on wrong you've done to men, you felt was justified by hatred. Yet it wasn't. I have nought for which to atone. Looks like you need to atone and reform. I have faith in you that you will and very soon. And you did.
hardwaregeek 7y ago
Empathy and patience are underrated qualities in developers. The empathy to not immediately blame the developers and the patience to find the actual reason behind the problem. Blaming developers reminds me of the Design of Everyday Things where Norman discusses human error. He makes the point that human error should be an extraordinarily rare cause of an incident. Instead one can always go further and find the root of the human error. Why was the code quality poor? Were the developers being rushed? Were proper standards not put into place? Did we hire the wrong people? Did we misunderstand the problem? Was there a miscommunication between management and developers?
- cutemonster 7y ago
  > "find the root of the human error" And sometimes there're many roots, like a chain with many weak links
ganzuul 7y ago
Another vector for unwarranted criticism to watch out for is self-insertion, not only in software. All of us (probably) constantly do self-insertion and imagine fictional situations where we are victims of some strange injustice. Hacking mostly in the evening, and at latitudes where the sun doesn't shine for much of the year, I was recently momentarily mad at Libreoffice Calc for having lackluster dark-mode support. But the vast majority of people who use spreadsheets I assume do so at day in well-lit offices so I was inserting myself in a context which basically didn't concern me. There are a lot of things which triggers us to self-insert, not all of it unwarranted or negative. Maybe one situation which causes problems is when people do it without an invitation...
Ma8ee 7y ago
On a related note, suppose that you already spent too much time to try to really understand the code and asked the developers for the motivations for their strange desing decisions. How do you present criticism in a constructive way then?
- superice 7y ago
  By showing you understand the constraints the developers were under, and acknowledging their frame of mind. Criticism is fine, giving it without understanding the context is not. If you are able to summarize the problem in such a way that the developers say 'That is right', and they are not correcting you further on your understanding of the problem, then any criticism from your side is not as much of an attack. By framing it like 'I might be missing some context here, I think X, Y, and Z were your reasons for choosing this approach, but I think there is a factor F you haven't considered' you are having an intelligent discussion instead of just burning the developers to the ground for missing some piece of information. You might still come to the conclusion the devs are dumb, but at the very least you have made a good impression by not barging in like you know better than the people that have probably spent a lot more time with the problem. Step one is showing that you understand the domain, and realistically, quite a few times you won't even get to the next step of asking whether they considered a factor that went unmentioned, since you've missed critical information in your assessment of the problem. To summarize: Interview the devs about their decision processes and the domain. Show you understand, and repeat the problem back to them in your own words. If they agree with your version, then and only then ask about things you think they missed, or decisions you still can't comprehend given your information. Reduce your ego, as hard a task as that might be.
  - cutemonster 7y ago
    Thanks for good advice > By showing you understand the constraints the developers were under And when you take this approach, maybe all of you together will discover that some of those constraints are the things you'd like to change
  - Ma8ee 7y ago
    As I said, I already spent too much time trying to understand their reasoning. In the end I just couldn’t, and I really tried, avoid the conclusion that they were incompetent. And I failed, even though I really tried, to present my criticism in a way that didn’t make my conclusion obvious. I really, really don’t like making people feel stupid.
l0b0 7y ago
Saying that some piece of software is "bad" (or any synonym of "bad") of course isn't helping anyone. It's demoralizing and counterproductive. I suspect a lot of the bad blood is because so much of the software world is like the faceless behemoths we all love to hate: - The process of reporting bugs is onerous for most big projects, especially old and/or big ones, which tend to have behemoth issue tracking systems and a bajillion rules (written and unwritten) about what should be in a report, how it should be structured, where it should be reported, and so on. Bonus points for having completely inscrutable fields (domain-specific tags like "T+" or "BZTM" being popular), a manual sign-up approval process, no way to upload files, or not responding to reports for anything older than HEAD even though it's a stable package in major distros. - The chance of success of a bug report (that is, it's fixed by the time I move to some other alternative) is effectively random. Even heavily funded projects like Firefox leave popular bug reports by the wayside for years, while lots of tiny projects fix even minor issues within days. - As users become more sophisticated they realize that almost all software is garbage by today's standards. If it's not garbage today it'll be garbage in a year, when it no longer works with any of the surrounding software ecosystem, doesn't implement the latest version of the relevant standards, doesn't use secure crypto primitives, emphasizes [old way of working] over [new way of working], you name it. Software can only stay ahead of the curve by being tiny and actively maintained, or by being really actively maintained.
deleted 7y ago
[deleted]
lmm 7y ago
Counterpoint: there is a practically infinite supply of possible projects to look at. Maybe we should be more eager to lay a program aside at the first major bug - there may well be five other programs that do the same thing - just as we should probably be more eager to give up on a bad book or movie these days. Maybe such an attitude would lead towards better priorities in software development - currently far too many projects prioritise advertisable features at the expense of working reliably.
madmax96 7y ago
What the author is really railing against is thoughtless critiques. Declaring software garbage is a usually useless contribution because it only identifies that software can be improved, which is almost always true. However, it fails to provide any concrete advise for improvement that could be debated. There's the saying "it's not science if people can't disagree with you." Seeing how engineering involves the application of science, it's not engineering either. Therefore, these kinds of comments have no place in a professional community. Being fast to critique _is_ good, provided the critiques are thoughtful. A thoughtful critique takes a clear stance, meaning it can be debated and (in an engineering or scientific setting) experimentally measured to verify it produces the intended effects. A thoughtful critique also poses questions not answered by the original body of work. In the example described here, fixing the software would have been ideal. However, we can imagine scenarios where this isn't possible (e.g. you have a binary from a now-defunct entity that you must continue using.) The original story should have explained this. If it didn't, the critique "fix the garbage software" isn't unreasonable, albeit badly phrased (instead, "why didn't they fix the software?")
- shoes_for_thee 7y ago
  I think what the author is railing against is the tendency to criticize something before becoming deeply familiar with the problem There's a tendency I've observed nearly everywhere I've worked where a developer wants to totally rewrite some piece of software because "it is garbage." In actuality, his motivations tend to be a combination of "other peoples' code is hard to read and this is not how I would have done it" and not having the depth of familiarity with a problem that you attain doing implementation work. In any cases, asking why something is a particular way is a good thing to do.
ken 7y ago
> Additionally, there might be time pressures, political pressures, engineering constraints, access problems, and more. All of those (except possibly "engineering constraints") are merely excuses for why it ended up being garbage, not reasons why it's not garbage. This conversation goes both ways. When someone calls my work garbage, I can sit there and try to come up with excuses, or I can say "yes it is!" and we can move on towards a solution. Just because someone takes a swing doesn't mean you need to fight them. Curiously, I only see the author's response in software. In every other field I've worked in, an experienced person is free to call something garbage (or worse), and the recipient of this criticism is expected to not waste everyone's time by making excuses. You'd think the internet would give us a thicker skin, not a thinner one.
- 6510 7y ago
  This is really about maturity I think? With children we do something like: thoughts > filter > communication > thoughts With grown ups it should work like: thoughts > communication > filter > thoughts You want the full spectrum of gradients of terribility. If I wrote a "steaming pile of crap" I don't want to hear "it is not very good". "not very good" is reserved for things that are "not very good". food half frozen != under cooked The alternative is teaching people not to give you feedback because you are emotional unstable and might take it the wrong way. Just because someone is a dick doesn't mean they are wrong. You have to adjust for their lack of social skills. You want to own the filter, don't require others to maintain it for you. That is a terrible idea! To them the trash talk is treasure.
  - goto11 7y ago
    > If I wrote a "steaming pile of crap" I don't want to hear "it is not very good". I don't see how either statement is of any use for you?
    - 6510 7y ago
      With the first I want to know why immediately with the later I will eventually ask for clarification. It is also an invitation for critical examination. I do some accounting for who says what. How much they normally complaint? How often are they right? How do they deal with similar feedback? There is this hilarious place few get to visit where everyone is complaining about everything all of the time while the mood is just wonderful. The work delivered is of exceptional quality.
siscia 7y ago
I find it very very true, however. The time necessary to understand why the fence was put up, it is usually greater than the time necessary to push down the fence, test the system, and put back up the fence if necessary.
- ColinWright 7y ago
  Except that you don't always know all the ways the system needs to be tested. I've come across code that was broken, seriously broken, multiple thousands of pounds broken, because someone replaced apparently pointless code with something simpler, tested every case they thought of, and deployed it. Are your tests really complete? Have you tested everything? Perhaps we simply work in different fields, and there are things that matter to me that you would shrug off and not care about.
  - siscia 7y ago
    Indeed it is a fine balance. However, what I am trying to convey is that the burder of explaining and testing the code, and why the code is needed, should be on who put it out first. If we are not brave and decisive when we decide to cut code, the complexity of the codebase will just explode in no time. It is already extremely difficult to simplify and remove code, if the person doing this job is also the one that need to figure out, from scratch without documentation, why the code was put there in the first place, the simplification is never going to happen.
    - ColinWright 7y ago
      > ... the burden of explaining and testing the code, and why the code is needed, should be on who put it out first. Yes. But what happens when that code is there, live, working, and the originator is no longer available, and you need to enhance it. You come across a complex section and you can't really see why it's written like that. It feels like you're suggesting that one should just replace it with the simpler version you think will do the job just as well, and see what breaks. Due to my usual context, that approach fills me with horror. I've seen it go wrong too many times ever to be comfortable with it. Admittedly, if you're producing simple web sites then usually it won't be a problem, but when there are potentially millions of dollars of revenue at risk when a condition happens that you didn't anticipate and which was part of the reason the original code was so hairy, you become a little more wary of the "move fast and break things, then fix them" approach. > If we are not brave and decisive when we decide to cut code, the complexity of the codebase will just explode in no time. And if you are brave and decisive and cut code, and it turns out that the complexity was there for a reason you didn't understand, then that can be a company-terminating move. Again, our contexts are different, and yes, I do understand the need for controlling complexity in code, and simplifying where possible. Properly understanding and analysing the risks is something I rarely see. I suspect we'd actually agree in a given context, I'm just horrified to watch people unthinkingly advocating the approach in places where it doesn't apply. I'm not claiming you're one of them, quite possibly you'd do the risk analysis and understand the context, but I've seen it too often to take for granted that otherwise clever people won't do it. "We'll just re-write it, it won't take long, how hard could it be?"
arminiusreturns 7y ago
I agree with this but I have to admit it is hard as hell to practice. If you can become slow to criticize though, when you do it people tend to pay more attention, a great upside to the effort required.
- BeetleB 7y ago
  > I agree with this but I have to admit it is hard as hell to practice. You may want to self-analyze your need to criticize. What is criticizing satisfying in you? It must be something otherwise you wouldn't have the urge to do it. It varies from person to person, but for a lot of academic (and perhaps tech) folks, there is a strong history in their training to be correct (in both research and classes) - therefore they are hyperaware of things that seem off. In the work environment, though, the focus is on being useful, which has overlap with correctness, but the two occasionally differ. A lot of times such people tend to be correct but not useful. Pointing out a flaw in something where there would be no significant impact were the flaw absent is the opposite of being useful. Unfortunately, people in the audience often get fooled by this and give the comment more weight than it deserves.
michele_f 7y ago
So true.

181 points by ColinWright 7y ago

deleted 7y ago

[deleted]

There's another factor at play in these discussions: Cynicism tends to look smart to outside observers. Cynicism is often mistaken for competence to outside observers. If a piece of software has a specific problem, the person chanting "This software is garbage" is going to look smarter than the people saying "Hold on, maybe this software is this way for a reason". There are various (somewhat weak) studies on the topic. For example: https://www.ncbi.nlm.nih.gov/pubmed/29993325 https://www.ncbi.nlm.nih.gov/pubmed/29993325 > Four studies showed that laypeople tend to believe in cynical individuals' cognitive superiority. A further three studies based on the data of about 200,000 individuals from 30 countries debunked these lay beliefs as illusionary by revealing that cynical (vs. less cynical) individuals generally do worse on cognitive ability and academic competency tasks. Cross-cultural analyses showed that competent individuals held contingent attitudes and endorsed cynicism only if it was warranted in a given sociocultural environment. Less competent individuals embraced cynicism unconditionally, suggesting that-at low levels of competence-holding a cynical worldview might represent an adaptive default strategy to avoid the potential costs of falling prey to others' cunning. In toxic and mismanaged environments, being a cynic from the sidelines can be a better political strategy than being the positive person in the trenches trying to find solutions and compromises.

TheOperator 7y ago
Reading that study cynicism was essentially defined as "low trust in others" and competence was ability in a handful of cognitively intensive tasks.
Hokusai 7y ago
Cynism also has the advantage that no solution needs to be provided, so you are never wrong. > In toxic and mismanaged environments, being a cynic from the sidelines can be a better political strategy than being the positive person in the trenches trying to find solutions and compromises. Yes. In the best awesome places I have worked, there are great constructive discussions on how to solve problems. If anyone is an environment that cynism is rewarded, run from there. There are better places to be.
- abnry 7y ago
  >If anyone is an environment that cynism is rewarded, run from there. There are better places to be. This is why I quit Twitter.
  - cutemonster 7y ago
    Quit the app? (Or quit the company as an employee?) Curious about Mastodon, if that's possibly a different experience
    - abnry 7y ago
      Quit the app as a user. It wasn't a platform thing, in terms of technical aspects although there is probably something to be said about how it shapes community, but it was the community itself.
root_axis 7y ago
Intersting. In my anecdotal experience cynics tend to speak in a very confident matter-of-fact tone that suggests others are fools for not embracing the cynical perspective. I imagine this gives cynicism an edge because people don't like to be perceived as too gullible or naive.
- grahamburger 7y ago
  I have found that this can be a dangerous gamble on the part of the cynic. Often the cynic's argument can't even withstand a single clarifying question. The first person to ask "can you explain in detail why this won't work?" can often elevate themselves above the level of the cynic, sometimes humiliating the cynic in the process. I have experienced this from both perspectives and as a bystander. Today I try as much as I can to be the problem-solver instead of the cynic. I try to do it in a way that gives the cynic a way to save face, though - it's almost never a good strategy to humiliate a team member.
  - zimpenfish 7y ago
    > The first person to ask "can you explain in detail why this won't work?" Unfortunately, in some forums, that often leads to that person suffering a barrage of negativity whilst the cynic ignores the question in favour of blustering elsewhere.
    - tilolebo 7y ago
      Exactly, someone else will just pop in the thread and post a provocative/insulting GIF/pic, and that's it, you'll have lost the argument. I'm looking at you, Twitter...
mewpmewp2 7y ago
I think the same thing is going on with the commentary on economy currently. Whenever I browse around Reddit for example the comments that get upvoted are the cynical ones, "markets are irrational", "feds are pumping up the stocks" etc, but they do not put any real thought into what is happening with the markets and why.
- gerland 7y ago
  That's a bit off-topic, but what do you think is happening? I'm considering buying some s&p500 based stock, but I'm a bit afraid. What do you, anonymous stranger on the interweb think?
  - mewpmewp2 7y ago
    I have many thoughts on this topic, I'm not an expert and many of these are theories up with so the may also be flat out wrong, but I just disagree with the sentiment that markets are irrational or it's just feds pumping up the stock. I think saying those things is dismissive and anti-intellectual. When I'm trying to think about the subject and whether I should invest myself, I'm trying to figure out what are the actual consequences of coronavirus long term and what in general are investor's motivations. Here are few assumptions I make: 1. Stock price is determined by an umbrella of possible consequences and chances for each consequence. These are just examples, but for example there might be 30% chance that we can manage coronavirus while reopening the economy, +50% chances that we will have a vaccine in 1 year period that we can mass-produce etc. For each of those consequences we can think of an appropriate SP500 price (I'm taking SP500 here as an example, but it could be any other index as well). If economy goes back to normal, the SP500 price could go to 3400 again. Investors will try to predict what are the odds and in total stock price should reflect what investors on average think the odds of something to happen are. 2. The way investors react to these possible consequences comes from that specific investor's expectations and long term strategy. It's important to know what is average investors expectations and risk tolerance. If SP500 is 2200 (which it was when people were expecting it to go to 1700) and you expect 90% of chances of SP500 going back to 3400 within 3 years you can determine that you have 90% chances of making 54% returns within 3 years which is crazy good. So at this point it makes sense for most investors to buy in, because even if it goes lower, you will still be making very good returns. Now that SP is at 2800-2900 I think it's still better to buy in than not, but you can't obviously expect as fantastic returns. I bought in and even with a little bit margin, but I have enough margin left to buy in more if stock should fall. I'm investing and looking at least 5-10 years ahead. So it makes sense for investors to buy in now that they are not crippled by fears of what coronavirus might do - it's already quite clear it's not the end of the world even if it might shake up economy further throughout this year. 3. There are possibly some positive long term effects of coronavirus. Increased productivity, tech and automation from having been forced to experiment with WFH etc. I think all of these might increase productivity. I'm speaking of those not to just sound optimistic, but these are something a lot of people don't mention. These are just rough thoughts I have right now, but in conclusion I have decided to buy in since I have determined that in 3-7 years there are very high chances of making very decent returns. I doubt corona can affect us for that long timeframe. Of course it's more risky than usual to buy in right now so if you have low risk tolerance it's up to you. If you possibly need that cash within 1-3 years, then maybe not buy in, but whether you should buy in right now should be determined with when you want to use that money and how much you are willing to risk. Usually more risk means more reward since only people who can handle that risk will be buying (so stocks will be more underpriced when there's more risk and uncertainty). And since I don't want to use that money before 5 years anyway, for me it definitely makes sense to take that risk. Also even if stocks fall just after you bought in you must be able to handle that and not think you did the wrong thing and sell. You likely wouldn't be able to sell in time anyway. Many people are fearful right now which means a lot of people are holding cash or shorting. Once fear subsides, stock will start to climb faster again so you should want to be in before general fear subsides..
eeZah7Ux 7y ago
You are confusing cynicism with expressing criticism. They are 100% orthogonal.

chrismsimpson 7y ago

Being slow to criticise, particularly with colleagues you have to work day in and day out with, is critically important. That said, much of the FOSS currently available is either itself crap, or built on libraries and/or toolkits that are crap. I cite specifically anything of the GTK flavour, many popular things built in C/C++, and to a lesser degree QT. Why is this? Writing capstone technology (compilers and languages) is very hard. Many industries start life fragmented, but looking now at the tech landscape, sadly there is more hegemony in the proprietary world than the open source one. If FOSS is ever to be adopted by a wider community that is inviting to newcomers (both users and hackers), this has to be addressed. It is not being addressed, and the power and elegance offered by the tech giants (Swift, C#/.NET etc.) continues to lap open source equivalents. One example I'll cite is Inkscape. I now honestly believe it would have resulted in better software if this has been written once per platform (WinForms/WPF + Cocoa) rather than with GTK. It's years between minor bug releases, and it gets slower with each release. The (just released) 1.0 is unbearably slow (i.e. unusable). I've spent many hours trying to get familiar with the codebase so I could contribute to it. There's no documentation to speak of for developers, and the little that I've grasped so far leads me to thing it's better left to rot. The core is based on Sodipodi, a project abandoned in 2003. FWIW I have started writing a clean room replacement in Swift/AppKit, but I'm considering altering this to Swift/UIKit for iPad so it'll be cross platform (albeit Apple only).

frenchy 7y ago
I'm going to guess you're pretty exclusively an Apple user. I think a big part of the problem is that a lot of the people developing FOSS don't have access to Apple's platforms for doing development, and in many cases, even testing. Because of the walls that Apple has set up for it's platform, doing so is often impractically expensive. I think this is part of what is meant by being slow to critisize. Yes, FOSS often sucks on Apple's platform, but it's also useful to understand the factors involved, and what motivates people. P.S. The best of luck in your endevors! I think the world of SVG editors could use some solid competiton.
narag 7y ago
That said, much of the FOSS currently available is either itself crap... I understood the article was about criticizing persons and their reasons for doing something. What you say is an opinion on results, an opinion that could be correct. But you can't make a convincing criticism of behaviour based on results, except with better results.

RickJWagner 7y ago

People who are slow to criticize seem wise to me. Maybe they've seen similar situations before, they might have ideas about an optimal outcome.

cutemonster 7y ago
Related: I think often when sbd has a seemingly silly idea, there's a good idea just nearby, when tweaking the initial idea a little bit Then good to keep {those who suggested the idea) happy so they'll help out with tweaking and improving the idea

bonestormii_ 7y ago

I love this short post. Software development is fundamentally hard, despite many frequent statements to the contrary by the "everyone should be a programmer" folks. It requires uncommon persistence, and a love (if not an aptitude) of abstract reasoning in pure form. I think the thought process goes like this: "What's he doing?" "He's doing THAT!?" "Why?!" "I don't understand why." "This software is garbage." Some people claim to be able to glance at code and know what it's doing quickly, but it's just not possible to ingest a few thousand lines of self-referencing logic and understand it quickly if it is doing much more than shuttling data between a database and some kind of display rendering. If you've learned to program, you must have learned patience for yourself. You have to show that same patience to the authors of other programs if you want to understand their work. There are many thoughts embedded in their code. It is deeply complex as the person who wrote it.

ohvirginia 7y ago

I see Colin is atoning and reforming from even 1 day ago https://news.ycombinator.com/item?id=23125032 https://news.ycombinator.com/item?id=23125032 This is good

pm 7y ago
Colin is talking about criticising implementation decisions in software, in particular unconstructive criticism bereft of context. Colin is criticising your idea, but is also trying to understand how you formed that idea in the first place, in an effort to hedge against the possibility it has good reasons he can't see. He's not just saying, "your idea is garbage".
- ohvirginia 7y ago
  Weather good in SA yesterday, Adelaidian, also in QLD/ACT. Go out to enjoy it. Better than texting pulled into what you don't know. Yet, maybe you comment here to defend your hypocrisy, not Colin's.
deleted 7y ago
[deleted]
ColinWright 7y ago
This comment was flagged dead, and I have vouched for it. Please don't downvote it ... it clearly shows an underlying misunderstanding, and as such deserves to be answered. My comment that you reference was an attempt to find the merit in the idea that I couldn't see, but I assumed would be there because I was assuming the proposer thought it was a good one. I was starting from a position of "Well, this person thinks it's a good idea, but I can't see why, so let's see if we can find how it would work, and what problems it solves. Then we can address any potential drawbacks." It was intended to be an invitation to get some discussion about how it would work, what it would do, what problems it would solve, and where the value lay. I was surprised and disappointed that no reply was forthcoming, and the thread died. I guess I just wasn't clear enough, and for that I am saddened.
- 7y ago

Daub 7y ago

Holding back on criticism is one of the founding principles of the brainstorming technique... that and listening.

lmm 7y ago
And research has shown that it's counterproductive. Culling bad ideas quickly makes for better results.
- ColinWright 7y ago
  That's fascinating ... can you provide references for that research? We've found the careful controlling of criticism to be invaluable in getting ideas up front quickly so they can then be dissected, mutated, co-evolved, and their best points combined. Iterating quickly and ejecting bad ideas quickly has its place, yes, but not always. I'd be interested to see the underlying context for your statement here. Thanks.
  - hnick 7y ago
    This doesn't support the point but the conversation reminded me about something I read a while ago that is related. Maybe you will find it interesting. https://www.psychologicalscience.org/news/minds-business/theres-a-better-way-to-brainstorm.html https://www.psychologicalscience.org/news/minds-business/the... The researchers found that a problem with brainstorming is the verbal component - due to social factors and limited oral and aural bandwidth, less ideas get shared, and people forget what they were about to say. They decided 'brainwriting' is more effective, particularly 'asynchronous brainwriting' which alternates between writing your own ideas in a group, then reviewing others' ideas. This method would support want you want - getting all the ideas out quickly, because people are less likely to hold back, then iterating on them.
    - Daub 7y ago
      In the paper, group brainstorming was conducted between more than 50 individuals. I would say that 10 is the effective maximum.

andrewflnr 7y ago

On reflection, I have kind of an interesting relationship with this thesis. Whether you should be quick to criticize kind of depends on the purpose of the discussion. Maybe in the context of the person writing the code that kills webservers, it was a reasonable idea. It could well be true at the same time that the software creating that context is, in fact, garbage. I tend to think from the perspective of how to build systems tomorrow that are not garbage, so I lean towards labeling as garbage things that cause annoying code to have to be written; it's an optimistic perspective in a certain sense, that things can be better. But if you're going to bother judging past projects, which is already something to be careful with, it seems pretty clear as OP states that you'll learn more about by looking for reasons that the way they did things made sense at the time. With all the pesky humans involved, it may well be a sociological lesson rather than a technical one.

DoreenMichele 7y ago

Social stuff has gotten complicated by living in a world with a global internet. We each individually bring our personal experiences and prejudices to the table and often have no idea what the context is. I got my first experience as a moderator on an email list with about 300 members and they were all "gifted." It was a parenting list for people with gifted kids, basically, and every single person there was used to being the smartest person in the room. So if you disagreed, obviously, you must be an idiot who had no idea what you were talking about. It took a long time to lay some groundwork and convince people they were, for the first time in their lives, hanging out with 299 other people just as smart as they were who had read just as much as they had on the topic and so forth and, in some cases, drawn other conclusions. That felt like a long, hard haul to me and then I quit after about six months because I was relatively new to the forum and my boss basically told me I was stabbing her in the back for doing my job and I was all "I ain't being paid enough for this." because it was a volunteer position. I quit and let her know what she was doing wrong as a going away present, because I'm generous like that. I'm sure my analysis wasn't appreciated. It was most likely interpreted as sour grapes and as me pissing all over her as I left. HN is better than most places about this kind of thing, but it's just hard communicating on the internet and not knowing the same things about the people we are speaking with that we tend to know about people physically in the same room. We haven't gotten all that sorted out yet and we may never sort it out. If we don't sort it out, the result may be massive die back of the human race to a level we know how to cope with. The internet is our opportunity to sort a bunch of things that aren't working well, but I don't know if we are successfully tackling those questions. Perhaps this post by Colin is one small crumb that can move that forward. And perhaps not. Perhaps it will get lost in the crowd and make no real difference.

ohvirginia 7y ago
Good. You atone and reform by deletion http://archive.is/KxZff http://archive.is/KxZff My reply is Judging? You project and are unqualified. Victim blaming? OK when I'm a man? The bullied often bully, you hated men for years. Think on wrong you've done to men, you felt was justified by hatred. Yet it wasn't. I have nought for which to atone. Looks like you need to atone and reform. I have faith in you that you will and very soon. And you did.

hardwaregeek 7y ago

Empathy and patience are underrated qualities in developers. The empathy to not immediately blame the developers and the patience to find the actual reason behind the problem. Blaming developers reminds me of the Design of Everyday Things where Norman discusses human error. He makes the point that human error should be an extraordinarily rare cause of an incident. Instead one can always go further and find the root of the human error. Why was the code quality poor? Were the developers being rushed? Were proper standards not put into place? Did we hire the wrong people? Did we misunderstand the problem? Was there a miscommunication between management and developers?

cutemonster 7y ago
> "find the root of the human error" And sometimes there're many roots, like a chain with many weak links

ganzuul 7y ago

Another vector for unwarranted criticism to watch out for is self-insertion, not only in software. All of us (probably) constantly do self-insertion and imagine fictional situations where we are victims of some strange injustice. Hacking mostly in the evening, and at latitudes where the sun doesn't shine for much of the year, I was recently momentarily mad at Libreoffice Calc for having lackluster dark-mode support. But the vast majority of people who use spreadsheets I assume do so at day in well-lit offices so I was inserting myself in a context which basically didn't concern me. There are a lot of things which triggers us to self-insert, not all of it unwarranted or negative. Maybe one situation which causes problems is when people do it without an invitation...

Ma8ee 7y ago

On a related note, suppose that you already spent too much time to try to really understand the code and asked the developers for the motivations for their strange desing decisions. How do you present criticism in a constructive way then?

superice 7y ago
By showing you understand the constraints the developers were under, and acknowledging their frame of mind. Criticism is fine, giving it without understanding the context is not. If you are able to summarize the problem in such a way that the developers say 'That is right', and they are not correcting you further on your understanding of the problem, then any criticism from your side is not as much of an attack. By framing it like 'I might be missing some context here, I think X, Y, and Z were your reasons for choosing this approach, but I think there is a factor F you haven't considered' you are having an intelligent discussion instead of just burning the developers to the ground for missing some piece of information. You might still come to the conclusion the devs are dumb, but at the very least you have made a good impression by not barging in like you know better than the people that have probably spent a lot more time with the problem. Step one is showing that you understand the domain, and realistically, quite a few times you won't even get to the next step of asking whether they considered a factor that went unmentioned, since you've missed critical information in your assessment of the problem. To summarize: Interview the devs about their decision processes and the domain. Show you understand, and repeat the problem back to them in your own words. If they agree with your version, then and only then ask about things you think they missed, or decisions you still can't comprehend given your information. Reduce your ego, as hard a task as that might be.
- cutemonster 7y ago
  Thanks for good advice > By showing you understand the constraints the developers were under And when you take this approach, maybe all of you together will discover that some of those constraints are the things you'd like to change
- Ma8ee 7y ago
  As I said, I already spent too much time trying to understand their reasoning. In the end I just couldn’t, and I really tried, avoid the conclusion that they were incompetent. And I failed, even though I really tried, to present my criticism in a way that didn’t make my conclusion obvious. I really, really don’t like making people feel stupid.

l0b0 7y ago

Saying that some piece of software is "bad" (or any synonym of "bad") of course isn't helping anyone. It's demoralizing and counterproductive. I suspect a lot of the bad blood is because so much of the software world is like the faceless behemoths we all love to hate: - The process of reporting bugs is onerous for most big projects, especially old and/or big ones, which tend to have behemoth issue tracking systems and a bajillion rules (written and unwritten) about what should be in a report, how it should be structured, where it should be reported, and so on. Bonus points for having completely inscrutable fields (domain-specific tags like "T+" or "BZTM" being popular), a manual sign-up approval process, no way to upload files, or not responding to reports for anything older than HEAD even though it's a stable package in major distros. - The chance of success of a bug report (that is, it's fixed by the time I move to some other alternative) is effectively random. Even heavily funded projects like Firefox leave popular bug reports by the wayside for years, while lots of tiny projects fix even minor issues within days. - As users become more sophisticated they realize that almost all software is garbage by today's standards. If it's not garbage today it'll be garbage in a year, when it no longer works with any of the surrounding software ecosystem, doesn't implement the latest version of the relevant standards, doesn't use secure crypto primitives, emphasizes [old way of working] over [new way of working], you name it. Software can only stay ahead of the curve by being tiny and actively maintained, or by being really actively maintained.

deleted 7y ago

[deleted]

lmm 7y ago

Counterpoint: there is a practically infinite supply of possible projects to look at. Maybe we should be more eager to lay a program aside at the first major bug - there may well be five other programs that do the same thing - just as we should probably be more eager to give up on a bad book or movie these days. Maybe such an attitude would lead towards better priorities in software development - currently far too many projects prioritise advertisable features at the expense of working reliably.

madmax96 7y ago

What the author is really railing against is thoughtless critiques. Declaring software garbage is a usually useless contribution because it only identifies that software can be improved, which is almost always true. However, it fails to provide any concrete advise for improvement that could be debated. There's the saying "it's not science if people can't disagree with you." Seeing how engineering involves the application of science, it's not engineering either. Therefore, these kinds of comments have no place in a professional community. Being fast to critique _is_ good, provided the critiques are thoughtful. A thoughtful critique takes a clear stance, meaning it can be debated and (in an engineering or scientific setting) experimentally measured to verify it produces the intended effects. A thoughtful critique also poses questions not answered by the original body of work. In the example described here, fixing the software would have been ideal. However, we can imagine scenarios where this isn't possible (e.g. you have a binary from a now-defunct entity that you must continue using.) The original story should have explained this. If it didn't, the critique "fix the garbage software" isn't unreasonable, albeit badly phrased (instead, "why didn't they fix the software?")

shoes_for_thee 7y ago
I think what the author is railing against is the tendency to criticize something before becoming deeply familiar with the problem There's a tendency I've observed nearly everywhere I've worked where a developer wants to totally rewrite some piece of software because "it is garbage." In actuality, his motivations tend to be a combination of "other peoples' code is hard to read and this is not how I would have done it" and not having the depth of familiarity with a problem that you attain doing implementation work. In any cases, asking why something is a particular way is a good thing to do.

ken 7y ago

> Additionally, there might be time pressures, political pressures, engineering constraints, access problems, and more. All of those (except possibly "engineering constraints") are merely excuses for why it ended up being garbage, not reasons why it's not garbage. This conversation goes both ways. When someone calls my work garbage, I can sit there and try to come up with excuses, or I can say "yes it is!" and we can move on towards a solution. Just because someone takes a swing doesn't mean you need to fight them. Curiously, I only see the author's response in software. In every other field I've worked in, an experienced person is free to call something garbage (or worse), and the recipient of this criticism is expected to not waste everyone's time by making excuses. You'd think the internet would give us a thicker skin, not a thinner one.

6510 7y ago
This is really about maturity I think? With children we do something like: thoughts > filter > communication > thoughts With grown ups it should work like: thoughts > communication > filter > thoughts You want the full spectrum of gradients of terribility. If I wrote a "steaming pile of crap" I don't want to hear "it is not very good". "not very good" is reserved for things that are "not very good". food half frozen != under cooked The alternative is teaching people not to give you feedback because you are emotional unstable and might take it the wrong way. Just because someone is a dick doesn't mean they are wrong. You have to adjust for their lack of social skills. You want to own the filter, don't require others to maintain it for you. That is a terrible idea! To them the trash talk is treasure.
- goto11 7y ago
  > If I wrote a "steaming pile of crap" I don't want to hear "it is not very good". I don't see how either statement is of any use for you?
  - 6510 7y ago
    With the first I want to know why immediately with the later I will eventually ask for clarification. It is also an invitation for critical examination. I do some accounting for who says what. How much they normally complaint? How often are they right? How do they deal with similar feedback? There is this hilarious place few get to visit where everyone is complaining about everything all of the time while the mood is just wonderful. The work delivered is of exceptional quality.

siscia 7y ago

I find it very very true, however. The time necessary to understand why the fence was put up, it is usually greater than the time necessary to push down the fence, test the system, and put back up the fence if necessary.

ColinWright 7y ago
Except that you don't always know all the ways the system needs to be tested. I've come across code that was broken, seriously broken, multiple thousands of pounds broken, because someone replaced apparently pointless code with something simpler, tested every case they thought of, and deployed it. Are your tests really complete? Have you tested everything? Perhaps we simply work in different fields, and there are things that matter to me that you would shrug off and not care about.
- siscia 7y ago
  Indeed it is a fine balance. However, what I am trying to convey is that the burder of explaining and testing the code, and why the code is needed, should be on who put it out first. If we are not brave and decisive when we decide to cut code, the complexity of the codebase will just explode in no time. It is already extremely difficult to simplify and remove code, if the person doing this job is also the one that need to figure out, from scratch without documentation, why the code was put there in the first place, the simplification is never going to happen.
  - ColinWright 7y ago
    > ... the burden of explaining and testing the code, and why the code is needed, should be on who put it out first. Yes. But what happens when that code is there, live, working, and the originator is no longer available, and you need to enhance it. You come across a complex section and you can't really see why it's written like that. It feels like you're suggesting that one should just replace it with the simpler version you think will do the job just as well, and see what breaks. Due to my usual context, that approach fills me with horror. I've seen it go wrong too many times ever to be comfortable with it. Admittedly, if you're producing simple web sites then usually it won't be a problem, but when there are potentially millions of dollars of revenue at risk when a condition happens that you didn't anticipate and which was part of the reason the original code was so hairy, you become a little more wary of the "move fast and break things, then fix them" approach. > If we are not brave and decisive when we decide to cut code, the complexity of the codebase will just explode in no time. And if you are brave and decisive and cut code, and it turns out that the complexity was there for a reason you didn't understand, then that can be a company-terminating move. Again, our contexts are different, and yes, I do understand the need for controlling complexity in code, and simplifying where possible. Properly understanding and analysing the risks is something I rarely see. I suspect we'd actually agree in a given context, I'm just horrified to watch people unthinkingly advocating the approach in places where it doesn't apply. I'm not claiming you're one of them, quite possibly you'd do the risk analysis and understand the context, but I've seen it too often to take for granted that otherwise clever people won't do it. "We'll just re-write it, it won't take long, how hard could it be?"

arminiusreturns 7y ago

I agree with this but I have to admit it is hard as hell to practice. If you can become slow to criticize though, when you do it people tend to pay more attention, a great upside to the effort required.

BeetleB 7y ago
> I agree with this but I have to admit it is hard as hell to practice. You may want to self-analyze your need to criticize. What is criticizing satisfying in you? It must be something otherwise you wouldn't have the urge to do it. It varies from person to person, but for a lot of academic (and perhaps tech) folks, there is a strong history in their training to be correct (in both research and classes) - therefore they are hyperaware of things that seem off. In the work environment, though, the focus is on being useful, which has overlap with correctness, but the two occasionally differ. A lot of times such people tend to be correct but not useful. Pointing out a flaw in something where there would be no significant impact were the flaw absent is the opposite of being useful. Unfortunately, people in the audience often get fooled by this and give the comment more weight than it deserves.

michele_f 7y ago

So true.