So how do you avoid getting nerd-sniped when something really is just bad? There's an analogue of the Bullshit Asymmetry Principle here; any of us could slap out some code in half an hour (no doubt many of us have, myself included) and then any of us could spend days or weeks trying to understand why we did it that way. Taking the time to understand bad software is, like up-front planning, one of those things that sounds worthy and wise, but I suspect it's actually a poor use of time on the whole.
> So how do you avoid getting nerd-sniped when something really is just bad?
This is not logic, where existence of a counterexample invalidates the general argument.
One reason for looking at even genuinely bad code is that it may express domain knowledge that you are currently unaware of.
Jon Bentley told the story of a Bell Labs researcher who found that his fast and correct algorithm for something or other had been "fixed" and "improved" so much that it was no longer efficient (a few comments may have helped here - though not necessarily - but that is a discussion for another time.)
The same way you avoid getting sucked into anything - go in knowing how much time and effort you're willing to expend and cut your losses when you hit the limit.
Sometimes, it helps to just put in the comments why you did something that you know is not optimal.
Often you'll write "bad" code just because it makes sense. I had to update something last week where the requirements changed dramatically from when they were written. It's nobody's fault. When the requirements were written, we did really understand the problem. After the customer got the code in their hand, they wanted to extend it in a way that wasn't obvious to us or them. I could have done a multi-month refactoring to make it clean and pretty, but that didn't make any business sense, so I did some surgical changes. To avoid someone coming back next year and thinking WTF, I added this to the comment (most of the details left out for anonymity)
//...Not how I would design it from scratch, but a nice evolutionary change.
Now next year when someone else looks at it (or even next-year me), we won't waste time thinking if we should refactor it, because it's obvious that we already looked at the pros and cons and decided not to.
Especially now, jammed together as we are in the global village, I suspect criticism is something we should only use defensively. Even criticism of ideas should be restricted to ideas we don't like but can't seem to avoid. Bearing in mind that if criticisms fail then perhaps the idea is a good one after all.
I delivered crap multiple times during my career. Sometimes I was forced to by external factors, sometime I was not in a good mental shape, sometime there was no time to do anything more than pile some garbage on top and duct-tape it together.
Sometimes I didn't even knew it at the time, I thought I was doing fine. Sometimes I delivered a good thing that aged bad and turned to garbage or the environment in which it functioned changed.
So yeah, I am no longer quick to judge others by the work they did especially if I don't know the circumstances. But I am of the firm opinion that we should try to be honest and say when something is garbage. It might be justified that it is garbage and the producer might not have any fault, but it's still garbage. We might not have time to take out the garbage, we might even sweep it under the rug for a while, or even permanently. Be honest though, call it what it is. How else are we going to learn to do better or appreciate the gems by contrast?
I think it is more that software is going to be "garbage" regardless (whatever that means, if the software writer disagrees with the user about what the software should do it is unclear who has the most right to call themselves correct).
A generally good software system is agnostic about the quality of its components. There are going to be bugs everywhere and it is important to guarantee outcomes. The pinnacle of this thinking is something like TCP creating a reliable connection out of fallible parts. It doesn't matter that the parts are unreliable, we get a reliable outcome because the system has realistic expectations of its components. This instance has overtones of the same thinking.
Also, Chesterton's fence is often a red herring that leads to poor practices. It is appropriate to just break things that look suspicious if the risk of failure is low. When it turns out the strange construction is needed, repair the damage done and add a comment or documentation.
When I was junior, I didn't respect much what came before...As I got experiences, I understood this need. I respect what came before, often people are surprised when I take that line.
The only problem is when people continue to do shit (even when hand carried through everything) and still have Pikachu faces when things go wrong, well these people and projects don't deserve respect.
Can't imagine why this, a public link to precisely what the parent comment mentions, is [dead] - unless it's the complete lack of karma on the account.
Several month old account with no comments and their first comment includes a link. It seems to be a spam filter thing as I've seen similar things happen to other old-but-rarely-used accounts with few comments.
in my opinion, this tendency to label anything less-than-ideal as 'garbage' is an outdated leftover of a time when assholish (and unrealistic) perfectionism was admired in software engineering, or at least looked up to as 'good engineering'.
This binary outlook is what leads to people who don't understand the reasons behind why existing code is the way it is to criticize. Frankly, when someone does it (and I have done it, lots of times, to my chagrin now) its a pretty good marker of engineering immaturity.
This is different than looking at something and identifying ways it could be better, btw. The latter is value-neutral and judgement-free.
Absolutely. And people with the best intentions can produce crap sometimes. That’s just reality. There’s a reason for that old saying about good intentions.
I recently had a small rant on Twitter about a certain web technology; I used the word "crap."
One of the main authors of the tech spotted my post and replied saying my rant was offensive and that they had worked hard and done the best they could.
It had been a long time since I felt that much shame in myself. It could have been me pouring myself into something and then the other guy calls it crap.
Because you have empathy you have learned a lesson. Lots of us make that mistake and learn from it. I'm glad you came clean about it. Now don't be shy about criticizing, just be more thoughtful about it.
There's a difference between being slow to criticize and completely withholding criticism. I agree that software is written by smart people, working under constraints.
But so what? If it sucks, it sucks, and we should call it out as such! How will we ever improve anything if we can't highlight what's wrong with the current solution?
My go-to example in this regard is the Microsoft Office ribbon. I remember, when the ribbon was introduced, I saw a presentation from a Microsoft employee (I can't remember if he was a developer or a product manager) going over the extensive testing that Microsoft did with focus groups to "prove" that the new UI was superior to the previous menu-based one. I remembered being both very impressed with the ostensible rigor of the process, and disappointed with the result. All that work, all that testing to delude themselves into believing that a UI where elements moved around, and weren't in predictable locations was going to be something that users (especially experienced users) would prefer.
And sure enough, even to this day, I still see users (both new and experienced) struggling with the ribbon. It sucks! And the fact that I know a lot of very smart people worked on it doesn't change that fact. In fact, it makes it worse. It would be one thing if such a horrid design were the result of a haphazard design process, implemented by incompetents. But it's not. It's the result of a lot of very smart people Goodharting themselves into believing that they've found the one weird trick to make their software both powerful and easy to use.
I strongly believe, that, if in the early days of the ribbon, someone had stood up and said, "This sucks!" things might have gone in a different direction.
I personally like Ribbon over rows and rows of small icons without labels. I think of Ribbons like tabs that organizes the buttons that makes sense together.
But I'm not a power Office user and that's just my preference.
The ribbon didn't replace rows and rows of small icons without labels. It replaced a hierarchical menu. Now, did the hierarchical menu have flaws? It did, insofar as it was rather forbidding to explore, and as a result, new users had trouble finding functionality by clicking around. That was the use case that the Ribbon sought to address.
What the designers of the ribbon did not understand was that users have other ways to find functionality. They could look up functionality on the Internet. There were even physical books which told you which specific menu to click on for a particular function.
What the ribbon did was instantly render all those resources useless. Moreover, by attempting to constantly surface different controls based upon the context of the current task, the ribbon made it extremely difficult to make new resources and tutorials. You could make a tutorial with screenshots, only to have users come to you with screens that look nothing like your screenshot, because they just happened to be highlighting a slightly different element.
On macOS, you get both the ribbon and the hierarchical menu.
Heaven help you if trying to navigate the "ribbon" on an iPhone though.
That said, I actually do like the simplified ribbon on Office for the web - once you figure out that it too is different.
I do kind of have a bone to pick about complaining about change for its own sake though. You could say the same -- all the earlier resources are useless - about the move from Windows NT to XP to 7 to 10 to 11 (we'll pretend 8 doesn't exist) when buying a new computer. Why not complain that your Active Desktop is missing, the desktop sidebar from Vista was a poor imitation and gone in just one release, Netscape Suite doesn't load webpages due to SSL errors and you can't publish webpages from your web browser like you used to, and you have to double-click folders to open them instead of single-clicking them like back in the old days of Windows ME? Sometimes change is just change and you have to adapt to the times.
Why not complain that your Active Desktop is missing, the desktop sidebar from Vista was a poor imitation and gone in just one release, Netscape Suite doesn't load webpages due to SSL errors and you can't publish webpages from your web browser like you used to, and you have to double-click folders to open them instead of single-clicking them like back in the old days of Windows ME?
I can and I do!
Sometimes change is just change and you have to adapt to the times.
That is exactly the kind of fatalistic attitude Microsoft, Google, Facebook, Apple, et. al. want you to have. "Oh there's nothing that can be done." "Change is inevitable." "I just need to go along and accept whatever scraps my corporate overlords deign to throw in my direction."
Corporations aren't natural phenomenona. They're not the sun, nor are they moon, nor are they the wind. They are composed of people, and those people can be persuaded to make different decisions if there is a sufficient outcry. Just look at Apple's proposal to enable client-side scanning for objectionable content. There was a huge outcry and Apple walked back its plans as a result.
In the case of the Ribbon, I think one of the factors leading to the success of Google Docs is the fact that it has the old-school hierarchical menu system that Office 2003 had, but which Microsoft refactored into the Ribbon with Office 2007. In a way, Google Docs was more familiar to Word users than Word itself, making it easy to switch.
Why didn't Word for Windows ever implement the Mac-like feature of a search box in the help menu? Start typing what you think the command's name is and then its location in the menu hierarchy is highlighted for you.
If you described how you saw some users struggle, that would be useful observation. Saying "it sucks" is a judgement call that adds no useful information. There are always people who dislike things, so one more stranger saying they dislike it doesn't add anything.
Sometimes people come to the correct conclusion without knowing how. And sometimes people come to the wrong conclusion with a painfully detailed process that really just led them astray. So maybe gut-level reactions shouldn't always be dismissed, and detailed reactions shouldn't always be held above gut level ones.
Because a stranger has an outside view. A stranger can see when something is weird or broken, and shouts when that weirdness or brokenness hurts them, versus the insider who is numbed by familiarity into taking the behavior of the system for granted.
It's not just software, either! There's a common social phenomenon known as the "broken-stair" problem, where you have a toxic, abusive person in a community, and everyone in the community has just gotten used to that person's behavior and normalized it. Sometimes it takes an outsider to notice that this toxic person is a net harm to the community.
I think there's two important aspects of this article:
1) Assume the people who wrote the code aren't stupid.
2) Be nice to developers
Point #1 is valid, because yes a lot of times intention is difficult to suss out and the guy who wrote it might have known something you didn't, or maybe the circumstances were different when it was written.
Point #2 is just wrong, it goes against the entire principle of Egoless Programming. Like you said about Ribbon, if it sucks you need to just admit it and either make it better or scrap it. It's just software, people don't need to incorporate every bug they write into their personal feelings of self-worth. If anything developers should embrace criticism, there might be lessons there to learn.
#2 does not contradict egoless programming. If you think it does, well, I'll take a page from your book: You're an idiot who has no clue what egoless programming is.
But, more seriously, "egoless programming" requires effort on the part of both the criticizer and criticized. The criticizer cannot act rudely and then exclaim, "You shouldn't be offended, it's just that you're a crap programmer and write sucky code!" That's an incredibly unhelpful way to work with the vast majority of people. If you don't understand why, well, the kindest thing I can say is that you are pitiful or maybe clueless. The person being criticized needs to set aside their ego, in egoless programming, and accept criticism with a minimum of emotional response. But that's hard.
However, the criticizer needs to be aware of who they're speaking to and how they're responding, otherwise they're being foolish, at best, or an asshole, at worst. The criticizer should act in a friendly manner, collegial, in order to be as honest and straightforward as possible without pushing the boundary and causing unneeded offense. Offense is often an emotional reaction, not a logical one, acknowledging that is critical to working with others and achieving your objective of egoless programming. You don't get to declare one day "We're going egoless people!" and follow it up with "All your code sucks!" and expect a successful transition to the egoless programming approach.
Egoless programming is a cooperative path that people embark upon, not a declared mode of working. For emphasis I'll repeat myself: Offense is often an emotional reaction, not a logical one. If you want to achieve egoless programming you have to work on both yourself: Letting things that offend slide off, whether the offense was intended or not. And how you work with others: Acknowledge that offense is an emotion, and being a rude dipshit is a great way to trigger that emotion in others, even if they try not to react with offense, so don't be a rude dipshit, be nice.
> Oh look, a big angry reaction to a simple assertion that you should try to look at code and criticisms about code objectively.
Oh look, an emotional (childishly sarcastic, in this case) reaction demonstrating that offense is, well, an emotional, not logical, reaction. Which was my point. Thank you for playing along.
In case you still don't get it, there's a distinction between honest-but-rude and honest-but-nice. My original comment was deliberately constructed to be rude, not nice, as an illustration of that. Your response is very helpful because that's the response people have when you provide unfriendly, non-collegial criticism. Even from people (like you, I'd presume, since you advocated for it) who want to practice egoless programming.
Hell, you can even be nice and still get an offended reaction from people, and have to backtrack (if you want to avoid unnecessary drama) a bit and work back to the point. Because egoless programming isn't just a declared mode of working, it's a process that all participants work toward. The one who is speaking and criticizing should take a "nice" approach if they want to be well-received, even if it's less straightforward than they want to be.
TL;DR: Egoless programming isn't an excuse to be unfriendly or rude.
Brilliant :) All too often the "I'm just being honest" people are providing shallow knee-jerk feedback, and shutting down dialogue. Quality honest feedback is always presented with compassion.
Maybe my memory is failing me, but I don't recall MS adopting the ribbon because it was better (even if they said it was). The purpose was to patent the ribbon UI, get it in front of as many people as possible while MS had a monopoly, and get it established as the "right" interface. That would make open source competition inferior and would allow MS to charge a tax on commercial competitors.
That would make a lot of sense, I remember when that started to appear in windows programming circles, many people jumped on it just because it was new and different but over time it sucks and I actually prefer the W2k look and feel where possible, ie drop down menus and a simple toolbar with icons.
Sure, but criticism comes in different flavors.
“This software is difficult for me to use because of X” is a valid and fair take.
“This software/development team sucks” is uninformed criticism if someone doesn’t know the full context.
For all I know, the developer may very well be aware of my situation, but there’s some reason that X must exist.
I worked for a very large financial services company, and when I told people this, they would commonly bring up something to the tune of “your app/website sucks because of X!”
And the response was very commonly: “we know, but we’re legally required to do this.”
I also worked on film projects, and occasionally someone would catch some goof (e.g. continuity error) and say “I can’t believe you missed this!” My (internal) response would be: “I didn’t overlook this. I have seen this film hundreds of time in slow motion during editing. We just didn’t have the budget to correct it, and it drives me nuts every time I see it. I could point out 70 other minor errors that YOU missed.”
It always reminded me how often we (myself included) mistake our own mental models and experiences for a comprehensive-enough understanding that we can pass judgement.
I think there's real value in hearing, "This sucks," even if there isn't a clear chain of reasoning backing it up. I've done a bit of gamedev, and I've found feedback of the form, "This isn't fun," or "This part feels boring," to be far more valuable than detailed analyses.
Like you said, the user usually doesn't have the full context. So if a player comes to me with a detailed analysis about why a specific area of the game sucks, it's likely to be wrong. Or, even if it's not completely wrong, it's likely to miss second and third order effects that have impacts later on. So, for example, someone telling me that part of the game is not fun because a particular character or ability needs to do more damage, be easier to use, require fewer resources, etc, etc, is less valuable to me than someone telling me, "Hey this thing feels kinda useless." "This thing feels useless," is a valuable signal. The detailed analysis is basically noise because it misses the fact that addressing the problem in the most direct way might ruin the rest of the game.
> But so what? If it sucks, it sucks, and we should call it out as such! How will we ever improve anything if we can't highlight what's wrong with the current solution?
Declaring an existing solution sucks is not sufficient to improve it. You also need to understand the constraints that led to that sucky solution and have some evidence that those constraints no longer apply. Otherwise, you'll just burn a bunch of time reinventing the same misshapen wheel.
> All that work, all that testing to delude themselves into believing that a UI where elements moved around, and weren't in predictable locations was going to be something that users (especially experienced users) would prefer.
What are you so certain that it's they that are deluded?
> And sure enough, even to this day, I still see users (both new and experienced) struggling with the ribbon.
Sure, but you don't notice when users don't struggle with it. This sounds like confirmation bias.
I generally agree with the points you are trying to make but
> Declaring an existing solution sucks is not sufficient to improve it.
Have you ever received poor App Store reviews? In my experience a drop in ratings (for example) can drive a whole lot work. Sure it can help to understand constraints, context, etc but even anecdotal feedback can be helpful.
Fair. Feedback that something sucks can perhaps incentivize an investigation into why. And that investigation might turn up ways that it can be improved.
But I think people generally overestimate the positive value of just declaring something bad. All the real work lies in figuring out why and how to make it better.
The ribbon itself was the result of confirmation bias, writ large, across the entire organization. Microsoft's PMs and UX experts noticed the new users who struggled with the hierarchical menus and forgot about the "dark matter" majority who found the menu structure adequate to their needs and didn't complain.
Hum... The article puts no effort on determining how much work went into that comment's assessment and how useful it was to people looking into invest some effort on migrating and learning how to use it.
Similarly, it's hard to see the cost of criticizing and it can be hard to judge the benefit of understanding.
Because of this, we'll see patterns of ignorant criticism playing out again and again. Some of the people in the pattern will never know any better. Others know better but don't care. Others know better but can't pay the price to understand because it's too high.
So when you find someone who actually defaults to understanding rather than criticizing you've found someone of rare value.
I wouldn't say I was clever, but there were, indeed, pressures that have led to the way it is, and the way it works. Instead of snarky, implied criticism like this, you could simply ask. Maybe I could then learn from you and it would get better, or maybe you could come to understand why it is as it is.
But I expect you don't actually care, and just wanted to couch your criticism in what you think is a clever dig.
You're right - this just comes off as snarky criticism. That wasn't my intent. I actually don't have any strong criticism about it - I was just thrown by the quote boxes at first.
> ... I was just thrown by the quote boxes at first.
That's interesting ... the "style" with the quote boxes was, indeed, the result of various implementation pressures when the site was first implemented. They've stuck, and my regular readers now consider it part of the "site style".
It's all well overdue a complete redesign, but whenever I've explained to people how it works, and what it does, they've recoiled in horror, then gone very thoughtful, then never come back again.
Someone sent a comment via the form on the page, but didn't provide a valid email return address. What they said is echoed by other comments on this page and deserves a reply, so I'll reply here. People may, no doubt will, disagree with me and agree with them, but there is a discussion to be had.
> Being slow to criticize, is being slow to correct. Is being slow to make you better.
I disagree. Being overly fast to criticize is to risk missing the
underlying causes, the underlying reasons, and the opportunity both
to learn and to make the right changes.
> This is not the first time I hear this argument. My opinion: complete and utter BS.
Then we disagree.
> If I have made bad software, please, let me know AS FAST AS POSSIBLE. Criticize me FAST! Let me fail fast!
If you are there to be asked then I will not simply criticize you,
I will ask you why you did it that way. It may be that what you
have done is poor, or badly coded, but it may be that there are
things you know that I don't know, and it's an opportunity for me
to learn from you.
If you then don't have a good reason then we have both learned,
and the code will be better. But if you do have a good reason
then I have learned, and we can possibly work together to improve
things within the restrictions that I had not initially seen.
I specifically take issue with this statement in the piece:
So often there are reasons for things to be the way they are.
This seems like a motte-and-bailey [1] argument. Of course there's a reason for way that things are the way they are. There's always a reason. It doesn't mean that the reason is good.
Let's take, for example, the dark patterns on the Adobe website [2]. Do I need to have the "full context" behind Adobe's product engineering to know that burying a hefty cancellation fee in the fine print for what appears to be month-to-month pricing is awful? No! We can, and should call that decision out, even if we aren't certain of the full process that led up to it.
In addition, I disagree with the broader point that one must have a full understanding of a system in order to disagree with it. I'm not a great cook. But I can sure tell when food tastes bad! Do I lose my ability to say, "Hey, this dish tastes bad," if I can't cook the dish myself? Do I lose the ability to say, "Hey, this car sucks," if I'm not a SAE-certified auto mechanic? Do I need to have a deep understanding of automotive supply chains in order to say that burying the controls for the heated seats two levels deep inside a touchscreen menu is a stupid idea?
No, of course not. While having a full understanding of the constraints behind a system may be helpful, in practice we can and must pass judgement on systems without having that understanding. There simply isn't enough time to learn everything about everything, so sometimes what you have do is say, "Eh this sucks," and move on.
Fundamentally, I think many programmers forget that writing software is a human problem first, and a coding/technical problem second. When you pause an extra beat to understand how things got the way they are before opening your mouth, it optimizes for the humanness of the outcome, which is more in line with the actual challenges - the humans using and building the software.
75 comments
[ 3.2 ms ] story [ 136 ms ] threadApologies. I was prompted by the submission about "My seatbelt rule for judgment" here:
https://news.ycombinator.com/item?id=30237457
Having realised I've returned to delete the submission, but find that I can't.
/mea culpa/
https://legacycoderocks.libsyn.com/self-compassion-with-clar...
I appreciate this double post!
This is not logic, where existence of a counterexample invalidates the general argument.
One reason for looking at even genuinely bad code is that it may express domain knowledge that you are currently unaware of.
Jon Bentley told the story of a Bell Labs researcher who found that his fast and correct algorithm for something or other had been "fixed" and "improved" so much that it was no longer efficient (a few comments may have helped here - though not necessarily - but that is a discussion for another time.)
//...Not how I would design it from scratch, but a nice evolutionary change.
Now next year when someone else looks at it (or even next-year me), we won't waste time thinking if we should refactor it, because it's obvious that we already looked at the pros and cons and decided not to.
Sometimes I didn't even knew it at the time, I thought I was doing fine. Sometimes I delivered a good thing that aged bad and turned to garbage or the environment in which it functioned changed.
So yeah, I am no longer quick to judge others by the work they did especially if I don't know the circumstances. But I am of the firm opinion that we should try to be honest and say when something is garbage. It might be justified that it is garbage and the producer might not have any fault, but it's still garbage. We might not have time to take out the garbage, we might even sweep it under the rug for a while, or even permanently. Be honest though, call it what it is. How else are we going to learn to do better or appreciate the gems by contrast?
I usually leave comments on garbage so later when I'm doing something else I try to fix it.
A generally good software system is agnostic about the quality of its components. There are going to be bugs everywhere and it is important to guarantee outcomes. The pinnacle of this thinking is something like TCP creating a reliable connection out of fallible parts. It doesn't matter that the parts are unreliable, we get a reliable outcome because the system has realistic expectations of its components. This instance has overtones of the same thinking.
Also, Chesterton's fence is often a red herring that leads to poor practices. It is appropriate to just break things that look suspicious if the risk of failure is low. When it turns out the strange construction is needed, repair the damage done and add a comment or documentation.
Decent or non-terrible software is the surprise and the exception, not the rule.
Respect What Came Before
When I was junior, I didn't respect much what came before...As I got experiences, I understood this need. I respect what came before, often people are surprised when I take that line.
The only problem is when people continue to do shit (even when hand carried through everything) and still have Pikachu faces when things go wrong, well these people and projects don't deserve respect.
Vouched in the hope that it'll benefit someone.
Technically Fearless
Lead with Empathy
Illuminate and Clarify
Flexible in Approach
Respect What Came Before
Learn, Educate, and Advocate
Have Resounding Impact
Each one has a one paragraph explanation but this gives you a taste.
This binary outlook is what leads to people who don't understand the reasons behind why existing code is the way it is to criticize. Frankly, when someone does it (and I have done it, lots of times, to my chagrin now) its a pretty good marker of engineering immaturity.
This is different than looking at something and identifying ways it could be better, btw. The latter is value-neutral and judgement-free.
That directive has served extremely well ever since.
One of the main authors of the tech spotted my post and replied saying my rant was offensive and that they had worked hard and done the best they could.
It had been a long time since I felt that much shame in myself. It could have been me pouring myself into something and then the other guy calls it crap.
But so what? If it sucks, it sucks, and we should call it out as such! How will we ever improve anything if we can't highlight what's wrong with the current solution?
My go-to example in this regard is the Microsoft Office ribbon. I remember, when the ribbon was introduced, I saw a presentation from a Microsoft employee (I can't remember if he was a developer or a product manager) going over the extensive testing that Microsoft did with focus groups to "prove" that the new UI was superior to the previous menu-based one. I remembered being both very impressed with the ostensible rigor of the process, and disappointed with the result. All that work, all that testing to delude themselves into believing that a UI where elements moved around, and weren't in predictable locations was going to be something that users (especially experienced users) would prefer.
And sure enough, even to this day, I still see users (both new and experienced) struggling with the ribbon. It sucks! And the fact that I know a lot of very smart people worked on it doesn't change that fact. In fact, it makes it worse. It would be one thing if such a horrid design were the result of a haphazard design process, implemented by incompetents. But it's not. It's the result of a lot of very smart people Goodharting themselves into believing that they've found the one weird trick to make their software both powerful and easy to use.
I strongly believe, that, if in the early days of the ribbon, someone had stood up and said, "This sucks!" things might have gone in a different direction.
But I'm not a power Office user and that's just my preference.
What the designers of the ribbon did not understand was that users have other ways to find functionality. They could look up functionality on the Internet. There were even physical books which told you which specific menu to click on for a particular function.
What the ribbon did was instantly render all those resources useless. Moreover, by attempting to constantly surface different controls based upon the context of the current task, the ribbon made it extremely difficult to make new resources and tutorials. You could make a tutorial with screenshots, only to have users come to you with screens that look nothing like your screenshot, because they just happened to be highlighting a slightly different element.
Heaven help you if trying to navigate the "ribbon" on an iPhone though.
That said, I actually do like the simplified ribbon on Office for the web - once you figure out that it too is different.
I do kind of have a bone to pick about complaining about change for its own sake though. You could say the same -- all the earlier resources are useless - about the move from Windows NT to XP to 7 to 10 to 11 (we'll pretend 8 doesn't exist) when buying a new computer. Why not complain that your Active Desktop is missing, the desktop sidebar from Vista was a poor imitation and gone in just one release, Netscape Suite doesn't load webpages due to SSL errors and you can't publish webpages from your web browser like you used to, and you have to double-click folders to open them instead of single-clicking them like back in the old days of Windows ME? Sometimes change is just change and you have to adapt to the times.
I can and I do!
Sometimes change is just change and you have to adapt to the times.
That is exactly the kind of fatalistic attitude Microsoft, Google, Facebook, Apple, et. al. want you to have. "Oh there's nothing that can be done." "Change is inevitable." "I just need to go along and accept whatever scraps my corporate overlords deign to throw in my direction."
Corporations aren't natural phenomenona. They're not the sun, nor are they moon, nor are they the wind. They are composed of people, and those people can be persuaded to make different decisions if there is a sufficient outcry. Just look at Apple's proposal to enable client-side scanning for objectionable content. There was a huge outcry and Apple walked back its plans as a result.
In the case of the Ribbon, I think one of the factors leading to the success of Google Docs is the fact that it has the old-school hierarchical menu system that Office 2003 had, but which Microsoft refactored into the Ribbon with Office 2007. In a way, Google Docs was more familiar to Word users than Word itself, making it easy to switch.
When you post your gut reaction, you are the stranger on the Internet. It doesn't matter who you are in real life.
It's not just software, either! There's a common social phenomenon known as the "broken-stair" problem, where you have a toxic, abusive person in a community, and everyone in the community has just gotten used to that person's behavior and normalized it. Sometimes it takes an outsider to notice that this toxic person is a net harm to the community.
1) Assume the people who wrote the code aren't stupid.
2) Be nice to developers
Point #1 is valid, because yes a lot of times intention is difficult to suss out and the guy who wrote it might have known something you didn't, or maybe the circumstances were different when it was written.
Point #2 is just wrong, it goes against the entire principle of Egoless Programming. Like you said about Ribbon, if it sucks you need to just admit it and either make it better or scrap it. It's just software, people don't need to incorporate every bug they write into their personal feelings of self-worth. If anything developers should embrace criticism, there might be lessons there to learn.
But, more seriously, "egoless programming" requires effort on the part of both the criticizer and criticized. The criticizer cannot act rudely and then exclaim, "You shouldn't be offended, it's just that you're a crap programmer and write sucky code!" That's an incredibly unhelpful way to work with the vast majority of people. If you don't understand why, well, the kindest thing I can say is that you are pitiful or maybe clueless. The person being criticized needs to set aside their ego, in egoless programming, and accept criticism with a minimum of emotional response. But that's hard.
However, the criticizer needs to be aware of who they're speaking to and how they're responding, otherwise they're being foolish, at best, or an asshole, at worst. The criticizer should act in a friendly manner, collegial, in order to be as honest and straightforward as possible without pushing the boundary and causing unneeded offense. Offense is often an emotional reaction, not a logical one, acknowledging that is critical to working with others and achieving your objective of egoless programming. You don't get to declare one day "We're going egoless people!" and follow it up with "All your code sucks!" and expect a successful transition to the egoless programming approach.
Egoless programming is a cooperative path that people embark upon, not a declared mode of working. For emphasis I'll repeat myself: Offense is often an emotional reaction, not a logical one. If you want to achieve egoless programming you have to work on both yourself: Letting things that offend slide off, whether the offense was intended or not. And how you work with others: Acknowledge that offense is an emotion, and being a rude dipshit is a great way to trigger that emotion in others, even if they try not to react with offense, so don't be a rude dipshit, be nice.
Oh look, an emotional (childishly sarcastic, in this case) reaction demonstrating that offense is, well, an emotional, not logical, reaction. Which was my point. Thank you for playing along.
In case you still don't get it, there's a distinction between honest-but-rude and honest-but-nice. My original comment was deliberately constructed to be rude, not nice, as an illustration of that. Your response is very helpful because that's the response people have when you provide unfriendly, non-collegial criticism. Even from people (like you, I'd presume, since you advocated for it) who want to practice egoless programming.
Hell, you can even be nice and still get an offended reaction from people, and have to backtrack (if you want to avoid unnecessary drama) a bit and work back to the point. Because egoless programming isn't just a declared mode of working, it's a process that all participants work toward. The one who is speaking and criticizing should take a "nice" approach if they want to be well-received, even if it's less straightforward than they want to be.
TL;DR: Egoless programming isn't an excuse to be unfriendly or rude.
For example: https://www.infoq.com/news/2018/02/Ribbon-UI/
I worked for a very large financial services company, and when I told people this, they would commonly bring up something to the tune of “your app/website sucks because of X!” And the response was very commonly: “we know, but we’re legally required to do this.”
I also worked on film projects, and occasionally someone would catch some goof (e.g. continuity error) and say “I can’t believe you missed this!” My (internal) response would be: “I didn’t overlook this. I have seen this film hundreds of time in slow motion during editing. We just didn’t have the budget to correct it, and it drives me nuts every time I see it. I could point out 70 other minor errors that YOU missed.”
It always reminded me how often we (myself included) mistake our own mental models and experiences for a comprehensive-enough understanding that we can pass judgement.
Like you said, the user usually doesn't have the full context. So if a player comes to me with a detailed analysis about why a specific area of the game sucks, it's likely to be wrong. Or, even if it's not completely wrong, it's likely to miss second and third order effects that have impacts later on. So, for example, someone telling me that part of the game is not fun because a particular character or ability needs to do more damage, be easier to use, require fewer resources, etc, etc, is less valuable to me than someone telling me, "Hey this thing feels kinda useless." "This thing feels useless," is a valuable signal. The detailed analysis is basically noise because it misses the fact that addressing the problem in the most direct way might ruin the rest of the game.
Declaring an existing solution sucks is not sufficient to improve it. You also need to understand the constraints that led to that sucky solution and have some evidence that those constraints no longer apply. Otherwise, you'll just burn a bunch of time reinventing the same misshapen wheel.
> All that work, all that testing to delude themselves into believing that a UI where elements moved around, and weren't in predictable locations was going to be something that users (especially experienced users) would prefer.
What are you so certain that it's they that are deluded?
> And sure enough, even to this day, I still see users (both new and experienced) struggling with the ribbon.
Sure, but you don't notice when users don't struggle with it. This sounds like confirmation bias.
> Declaring an existing solution sucks is not sufficient to improve it.
Have you ever received poor App Store reviews? In my experience a drop in ratings (for example) can drive a whole lot work. Sure it can help to understand constraints, context, etc but even anecdotal feedback can be helpful.
But I think people generally overestimate the positive value of just declaring something bad. All the real work lies in figuring out why and how to make it better.
Similarly, it's hard to see the cost of criticizing and it can be hard to judge the benefit of understanding.
Because of this, we'll see patterns of ignorant criticism playing out again and again. Some of the people in the pattern will never know any better. Others know better but don't care. Others know better but can't pay the price to understand because it's too high.
So when you find someone who actually defaults to understanding rather than criticizing you've found someone of rare value.
But I expect you don't actually care, and just wanted to couch your criticism in what you think is a clever dig.
That's interesting ... the "style" with the quote boxes was, indeed, the result of various implementation pressures when the site was first implemented. They've stuck, and my regular readers now consider it part of the "site style".
It's all well overdue a complete redesign, but whenever I've explained to people how it works, and what it does, they've recoiled in horror, then gone very thoughtful, then never come back again.
Addendum: You may be interested in this:
https://www.solipsys.co.uk/new/HowTheFarragoWorks.html?vb09h...
> Being slow to criticize, is being slow to correct. Is being slow to make you better.
I disagree. Being overly fast to criticize is to risk missing the underlying causes, the underlying reasons, and the opportunity both to learn and to make the right changes.
> This is not the first time I hear this argument. My opinion: complete and utter BS.
Then we disagree.
> If I have made bad software, please, let me know AS FAST AS POSSIBLE. Criticize me FAST! Let me fail fast!
If you are there to be asked then I will not simply criticize you, I will ask you why you did it that way. It may be that what you have done is poor, or badly coded, but it may be that there are things you know that I don't know, and it's an opportunity for me to learn from you.
If you then don't have a good reason then we have both learned, and the code will be better. But if you do have a good reason then I have learned, and we can possibly work together to improve things within the restrictions that I had not initially seen.
> This is just apology for mediocre SW.
I think you have missed the point.
So often there are reasons for things to be the way they are.
This seems like a motte-and-bailey [1] argument. Of course there's a reason for way that things are the way they are. There's always a reason. It doesn't mean that the reason is good.
Let's take, for example, the dark patterns on the Adobe website [2]. Do I need to have the "full context" behind Adobe's product engineering to know that burying a hefty cancellation fee in the fine print for what appears to be month-to-month pricing is awful? No! We can, and should call that decision out, even if we aren't certain of the full process that led up to it.
In addition, I disagree with the broader point that one must have a full understanding of a system in order to disagree with it. I'm not a great cook. But I can sure tell when food tastes bad! Do I lose my ability to say, "Hey, this dish tastes bad," if I can't cook the dish myself? Do I lose the ability to say, "Hey, this car sucks," if I'm not a SAE-certified auto mechanic? Do I need to have a deep understanding of automotive supply chains in order to say that burying the controls for the heated seats two levels deep inside a touchscreen menu is a stupid idea?
No, of course not. While having a full understanding of the constraints behind a system may be helpful, in practice we can and must pass judgement on systems without having that understanding. There simply isn't enough time to learn everything about everything, so sometimes what you have do is say, "Eh this sucks," and move on.
1: https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy
2: https://twitter.com/darkpatterns/status/1489901640777973768