61–70 of 172 posts
My favourite business cliche is a diagram with three or four things in a circle. I thought about it so much I know think the circular process is an inevitable consequence of reality. Still, the business ones are usually pretty vacuuous.
I'm thankful that the words "paradigm" and "synergy" have been mocked enough that business people avoid them now.
I'd love to see a similar list for software engineering. - if your code isn't important enough to be tested, it's not important to be written - every function must fit a single screen
Imperative languages are the best match for the underlying hardware
Use the right tool for the job
A language is just another tool in your toolbox
Earlier quoted context omitted.
- if your code isn't important enough to be tested, it's not important to be written Does this rule cover all code? Do your tests, which are code themselves, not need their own tests? If not, what is special about a test that you know it's correct, when there is no faith in in non-test code? Is it possible to write your program entirely out of the special "test" code, so that it's always correct and doesn't need to b…
My tests run during tests, so they automatically have 100% test coverage. :D
Earlier quoted context omitted.
Yes, I imagine no one ever thought to themselves a flying horse was the realistic way of getting to the Moon.
Ahem, actually: in norse mythology there was the flying horse «Sleipnir:» https://en.wikipedia.org/wiki/Sleipnir While not «realistic,» they did believe it was.
Interesting fact nontheless, Pegasus comes to mind.
I'm feeling that cliches is not the right word. To call something cliche generally means it's over-used, tired, boring, etc. But the article itself is not saying that. Perhaps maxims or truths, would be better?
:-)
My favorite “If Henry Ford had asked people what they wanted, they would have told him faster horses” Used as a counter-argument to the previous statement, when you start to realize you won’t have time or money to do enough user research.
I like this one: > UX should be a mindset, not a step in the process Mostly because it's not a UX-cliché, but a cliché for everything: security, accessibility, UX, localisation, etc.; advocates want them all to be an essential part of the process, but in practice, nobody manages to do all that.
Building software is like that. It's a high-dimensional optimization process in which all those concerns like UX, security, accessibility, etc. are each a dimension, and in which you initially only know the rough shape of the terrain, so you have to walk it to discover its features. Or, to use a different analogy - software isn't like assembling a car toy on a factory line. Building software is like everything that happens in between the CEO saying "we need to build a toy car" and the factory getting the BOM and designs.
--
[0] - probably because it simplifies management.
These are overall really accurate depictions of what life in UX is like. I do have a comment on this one: > “Users don’t read” > An overly used argument to convince clients and stakeholders to cut copy length in half. If you made this far to this article, you’re living proof that this statement is untrue. The real principle here is that users don't read anything that doesn't look like it will help them do what they'r…
I am not a designer nor a software engineer, nor a business person. I am just a (heavy) user of all sorts of software for a very long time. I am a competent coder, and I code for research and pleasure. I don't have a dog in this, let's say, professional race. Every time I spot "UX" in relation to something I use, I cringe. Not because I have anything against the idea of design, or good interfaces, or designing good i…
In the early 2000, my music library was a few dozens GBs played back using mpeg123 or something. Nowadays it’s a Google Play Music subscription. Things have moved to the cloud, a lot. That’s a huge change in how computers work, requiring some serious UX changes. I too hate gratuitous UI changes, but things need to keep evolving.