Here's my theory: software developers are usually empowered to fix their own problems. You speak about offices, these offices are often filled with people working on computers. Most of them, when they have an error, refer to someone else. Few feel empowered to fix their problems. On the other hand, software developers usually know that there's a huge chance they can fix this error, and thus make things righht themselves. That habit translates to things like doors or elevator lights.

We are also (and I say this with a lot of love) massive prima donnas and love the opportunity to complain about someone else's bad UI decisions.

I agree, and I think it may have roots in perfectionism. We always want to "make things right".

I just think it is a different mindset from people who build things for other people, vs people who don't. If you build consumer facing software you have to have a level of empathy for the user, otherwise you are going to create a hostile UX, similar to doors that don't indicate which direction they go. A small detail, but something that will at some level annoy every person that uses it for the first time. In software a similar example would be things like animations that take too long for often repeated tasks.

In software, small affordances to improve UX are usually easy and cheap, requiring a few extra lines of code and a little more thought..and in the case of a door the only affordance needed is a $2 sign saying "push" somewhere.

A door that needs a sign to use is a classic example of bad de-sign (see Psychology/Design of Everyday Things)

That book was literally what the video was about.

Been wondering that all my life. With my "software/geeky" friends we can have these discussions for hours; with my "non-software/geeky" friends... 0.5 seconds before being labelled as grouchy old geezer who should just let it go :->

I think partially it's analytical minds trying to / used to optimizing; but the more self-flagellating part of me also worries if it's me/geeks or "them"/everybody-else who are bad at filtering/prioritizing :P

I think it's two things:

1) the other way around - being the sort of person who notices these sorts of things inclines you towards (or is a good indicator you are also heading towards) engineering & CS;

2) knowing it could be different, having some idea how the lift display firmware is implemented makes you think 'oh but it could so easily do this why doesn't it', etc. If you have no idea how something works (or don't care) then you also don't really have a grasp on the limits of the black box, or how readily it could be improved.

It's a thought straight from my butthole, but The Design of Everyday Things is a book recommended amongst this crowd, and one of the early chapters of that book goes on about doors. Once you've seen it, blah, blah, blah. Or perhaps the book didn't make any difference other than to validate what many had already noticed.

Afaik the book isn't THAT known among regular software devs (otherwise we'd have far less shitty UI's). The doors in the book is mostly an obvious tool used in the book to get people into the right mindset to then learn about the other issues the book presents.

I'm an engineer, but have had a similar observation with my wife.

I am constantly tweaking and fixing things that bug me in our relatively new-to-us house. The feedback is usually along the lines of "I never realized how annoying that was, but this is better". She has a strange-to-me ability to just not register the little annoyances.

Her approach is probably a better way to go through life, but I'm just not wired that way.

As engineers, we encounter great (and poor) design choices via our consumption of APIs. Something that has well-chosen public interfaces can be a pleasure to use. At the very least, it does its job without calling attention to itself and allows us to move on with our day. A door is a great metaphor for this. Using a well-designed door isn't going to change your life; it's nothing to write home about. But a poorly-designed one can make someone want to pull their hair out, as is evident from the video. That pain is something engineers are acutely sensitive to as a result of using other peoples' APIs on a daily basis, so we're more prone to need to vent our frustration.

In addition, I once read (I forget where, maybe it was a Paul Graham essay) that part of the mentality of a programmer is the idea that we're lazy. In the sense that we're happy to spend a larger-than-usual amount of effort up-front to solve a problem, if doing so will mean we'll save time, effort, and energy in perpetuity which will more than offset the up-front cost of those things. I think the above comes into play for me when I encounter a Norman door. When I think about how easy it would be to solve the issue (remove the handle from the side on which you're meant to push), and the sum total of all the people day-in and day-out who are having the same problem as me with this door, it's mind-boggling that the door would have been designed this way in the first place. It indicates that whoever designed it saw their primary concern as being aesthetic in nature, as opposed to practical. To me, that's shirking one's responsibility as a designer. As Steve Jobs said[1], "Design is how it works."

1. https://quotesondesign.com/steve-jobs/

As socially inept as we're stereotyped to be, we arguably have more user empathy than the average non-builder/non-engineer, considering how easy it is to build things.

As a software engineer, the fact that the elevators in the office don't have an up-peak mode in the morning and a down-peak mode at 5PM drives me up a wall.

Engineering mindset. They can imagine how it could be accomplished and want someone to bring it to fruition.

i would like to think it's about striving for a better world and a want to improve things for users.

but really it's probably that attention to details people are more likely to be drawn to the field.