[ngngngng]

> but it takes 45 steps in the console and 12 of them are highly confusing if you never did it before.

I am constantly amazed that software engineering is as difficult as it is in ways like this. Half the time I just figure I'm an idiot because no one else is struggling with the same things but I probably just don't notice when they are.

[intergalplan]

1) It's just as shitty for everyone except the person who's selling themselves as a "consultant" for X. And actually—they're lying, it's shitty for them too.

2) A bunch of other goddamn morons managed to use this more-broken-than-not thing to make something useful, so this goddamn moron (i.e. me) surely can.

Both almost always true. After the second or third time you realize something made by the "geniuses" at FAANG (let alone "lesser" companies) is totally broken, was plainly half-assed at implementation and in fact is worse than what you might have done (yes, even considering management/time constraints), and has incorrect documentation, you start to catch on to these two truths. It's all shit, and most people are bad at it. Let that be a source of comfort.

[EDIT] actually, broader point: the degree to which "fucking around with shitty tools" is where one spends one's time in this job is probably understated. This bull-crap is why some people "nope" the hell out and specialize in a single language/stack, so at least they only have one well-defined set of terrible, broken crap to worry about. Then people on HN tell them they're not real developers because they aren't super-eager to learn [other horribly-broken pile of crap with marginal benefits over what they already know]. (nb. I'm in the generalist and willing-to-learn-new-garbage category, so this judgement isn't self-serving on my part)

[esjeon]

I'm slightly afraid of all the negativity here, but still kinda agree with the sentiment.

However, I still want to note that there are many cases where smart people simply don't have enough time to handle all the stupidity in their products. Often times, it's just little issues like communication cost and politics. But, also often, one should care about the revenue of one's own company or clients', which slows down changes a lot. Even a simple feature can take weeks and months to roll out.

In short, even without stupid people, life sucks. :\

[intergalplan]

Oh, yeah, world-imposed restrictions are a factor. Problems aren't all because people are idiots. I, pointedly, don't exclude myself from the "people are idiots" judgement, either. But I think it's also true that the Super-Serious Real World's not half as competent, or capable, or polished, as one might hope. That organization that seems impossibly amazing? They're not, actually. Look closer and they produce bafflingly-bad crap more often than not. The institution with The Reputation? It's because they sometimes get things mostly right, and are good at networking and/or marketing, but if you got a look at how "the sausage is made" you'd be absolutely shocked. The Authority on The Thing? OMG you don't want to know.

Which is horrifying or liberating, depending on one's perspective.

[pm90]

The smartest people can build utterly useless crap if the teams they work on don’t prioritize UX. I think of it as “emergent stupidity”; individually they will optimize for and build the best components but if they aren’t well put together the UX is horrible and the product sucks sucks sucks.

On the contrary, users will be ok with suboptimal components if the overall UX is good.

[ungamedplayer]

> On the contrary, users will be ok with suboptimal components if the overall UX is good.

Until they -absolutely- need quality components, then no matter good the UI/UX is, you're out of luck.

[edoceo]

many things are confusing if you've never done it before.

my first HAproxy setup wasn't great, my 10th is rock solid, just needed a bit of context-specific learning.

same with PG replication (locical and archive) but 3rd go was awesome.

its a flawed expectation to get it right the first time.

[mLuby]

> its a flawed expectation to get it right the first time.

If your toilet overflows when you push the lever down and flushes when you pull the lever up, you'll learn pretty quickly how to use it. And other users will too, after they screw up or after you carefully explain so they're sure to understand. But it's just a shitty design! The fact that you've learned to deal with it doesn't excuse it or mean it shouldn't be fixed for all future users.

I want to get it right the first time; I don't expect to only because I've been hurt too many times by shoddy UIs. A good UI, whether a GUI, API, CLI, or other TLA, guides users through their workflow as effortlessly as possible by means of sensible defaults, law of least surprise, and progressive reveal of power features.

Relevant http://xkcd.com/1168

[tsimionescu]

There's still no way around having to learn complex features. For most software, building a really simple first try is very easy, but almost certainly useless.

Once you need to actually do something useful, uunavoidable complexity sets in and all of a sudden defaults and such don't really help anymore.

Some people try to push defaults further with templates and wizards, but that often still doesn't really work for your particular use case, and also makes you first search through many options before realizing you actually need to go for the scary blank one.