Being Slow to Criticise
solipsys.co.uk
solipsys.co.uk
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.
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.
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.
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.
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.
That directive has served extremely well ever since.
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.
> 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
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.
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.
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.
Apologies. 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!
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...
Decent or non-terrible software is the surprise and the exception, not the rule.