Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Being Slow to Criticise

solipsys.co.uk

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Being Slow to Criticise

#41

Post by lstamour »

quanticle wrote: post #34
highwind wrote: post #31

Earlier quoted context omitted.

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 w…

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.

Re: Being Slow to Criticise

#42

Post by BeFlatXIII »

quanticle wrote: post #34
highwind wrote: post #31

Earlier quoted context omitted.

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 w…

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.

Re: Being Slow to Criticise

#43

Post by angarg12 »

andrewqu wrote: post #25
angarg12 wrote: post #13

The Principal Engineer community in Amazon has a list of tenets. I think one of them puts it very eloquently. Respect What Came Before

Any chance you can share some of the other tenets? :P

Exemplary Practitioner

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.

Re: Being Slow to Criticise

#44

Post by thekiptxt »

quanticle wrote: post #29

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…

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.

Re: Being Slow to Criticise

#45

Post by munificent »

quanticle wrote: post #29

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…

> 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.

Re: Being Slow to Criticise

#46

Post by elpakal »

munificent wrote: post #45
quanticle wrote: post #29

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…

> 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 tim…

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.

Re: Being Slow to Criticise

#47

Post by quanticle »

thekiptxt wrote: post #44
quanticle wrote: post #29

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…

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 pe…

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.

Re: Being Slow to Criticise

#48

Post by munificent »

elpakal wrote: post #46
munificent wrote: post #45

Earlier quoted context omitted.

> 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 tim…

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.

Re: Being Slow to Criticise

#49

Post by quanticle »

munificent wrote: post #45
quanticle wrote: post #29

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…

> 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 tim…

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.

Re: Being Slow to Criticise

#50

Post by Jtsummers »

bigwig8702 wrote: post #39
quanticle wrote: post #29

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…

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 Progr…

#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.

Post reply on HN