[jrimbault]

Having designed a good number of internal tools for teams of developers I couldn't agree more.

Earlier I had the tendency to "leave the guts" open, thinking my users were developers and would want that. All it did was put obstacles in my teammates actually doing their work. My teammates must use the tools I made for them to achieve work the company needs them to do, they don't want, nor should they want to, fiddle with a little tool they won't find anywhere else.

I still leave a lot of escape hatches, but I try to design the internal tools in such way as to make the users fall into a pit of success.

Edit: also, error messages, error messages, error messages and auto suggestions for common errors

Edit 2: also the number of people only addressing the examples in the post rather than the spirit of the post is... disappointing.

[anal_reactor]

Some time ago I made an abstraction "hey, most people in our company who use CloudFront don't care about all the implementation details, they just want some paths to be somewhat cached". I explained this idea to a coworker. It took a while, but he understood it. Two months later someone merged a PR that replaced my interface "I want this and this path cached" with a simple passthrough that exposes raw AWS interface. Same thing happened to S3 buckets where I noticed that most people just want "auto-delete files after X days either on or off".

I spent entire year trying to explain to my manager "most devs who create services want a simple deploy button". Instead, we tried to teach devs how our "infrastructure as a code" works so that they'd contribute. The effect was that only one guy engaged with us this way, and he always sent us AI-generated PRs, and every time he saw an error, he just copy-pasted it to ChatGPT without reading and then the answer back to me.

The project eventually shifted towards my original idea, but in an extremely painful way without any design at all. It's just a toolbox of completely random features glued together because one day manager says "no we don't need to support X" and two months later a Jira ticket "add support of X".

[sbloz]

I think I have the same perspective. I see it as a flavor of progressive disclosure. Sane defaults and a way to customize if needed. Start with the 80% case and let people customize if they want to. It needs to be optional.

Especially with developer tools I think there's a hesitancy to be opinionated. If you don't know for sure an option is "always correct" it seems safer to ask the user. Developers can be very pedantic. "95% of people probably want it this way, but I should make people pick because that 5% has a valid point". But now you've made it worse for most users.

It's also so much more complicated to support customization, more than I think people realize. It's not just about bugs, every option makes polishing your UX much more difficult. Both because of the testing surface and also because more flexible abstractions are harder to design.

[bombela]

And before any major change, add a `--v2` for early adopters and `--v1` as default. Nobody should notice anything on `--v1`, any regression must be fixed imediately. Flip `--v2` as default, leaving `--v1` for the unforseen. Until you can finally get rid of them.

This helps being as invisible as possible.

[rmunn]

Excellent idea; it's good practice to do that with APIs, so why not with command-line tools as well?

[weitendorf]

I think configurability depends on how important your tool is to the core job function or role being performed, where it becomes very valuable for helping them directly perform the tasks they and their employer value, vs how much it allows you make problems they don’t value as much get out of the way of the ones they do.

For example, I am a HUGE fan of the way Gusto handles payroll and all the different taxes and form filing for me, because I basically do not even have to think about the problem or fiddle with it at all. But to someone whose job is doing payroll/accounting/taxes or working within giant enterprise HR/legal/finance departments that does more harm than good, because it’s something they have to fight (or less charitably it makes their job too simple).

The other big problem is who is actually making the decision to pay or spend money on a thing, and whether it serves more of a defensive (eg auditability, security, constraints against undesirable behavior) or creative purpose. The creative stuff is sexier but hard to quantify, and end-users won’t actually be willing to pay that much for it relative to how much it helps them or how critical it is to their role.

[lcnPylGDnU4H9OF]

> make the users fall into a pit of success

I don't have anything else to add but I thought this was a wonderfully evocative phrase.

[wofo]

Here's some additional context on the phrase, for today's lucky ten thousand[0]: https://blog.codinghorror.com/falling-into-the-pit-of-succes...

[0]: https://xkcd.com/1053/

[bch]

Good read, and I think a sort of living mindset, or “process, not product”, though seems to be follow-on/reaction to Perl’s TMTOWTDI (Tim Toadie)[0], and Python’s response(“There should be one-- and preferably only one --obvious way to do it”)[1].

[0] https://perl.fandom.com/wiki/TIMTOWTDI

[1] https://en.wikipedia.org/wiki/Zen_of_Python#Principles

[ozim]

Getting out of the way is important because people use dozen of tools each day for n and out.

Unfortunately there is still a thing to balance against, which is forcing people to do the right thing.

There always will be bunch of people who nag about being impeded by doing something correctly, because they feel it is waste of time.

[lanthissa]

it really depends on the framing, some work, especially fun work that develops skills is more valuable than people realize.

From an org perspective the goal is to create the highest curve of performance over the lifetime engagement of the employee or from the employee perspective their career.

And a lot of that depends on teh relationship of the people involved. From my perspective its a net negative when if my movers worked out the day before, their muscles will be sore and they'll do a worse or slower job. From the moving companies perspective its good, they'll be stronger for more jobs. Unless they quit or are fired that day, in which case we're back to bad.

The real evaluation isn't the macro vs the sublime edit. its does the thought process of making them macro improve them in other things, and what were they doing before that. In my experience no one is going use the time they spent writing a macro or a learning vim to do real meaningful work, they're doing that because they're bored or burned out and want to think about something else they find fun at the time.

your problem isn't your employees choose to write random scripts, its that they dont have a sense of urgency or care about their current task.

[TheOtherHobbes]

Some work is also less valuable than people - especially hackers - realise.

Hackers have an addiction to tractable problems that require effort and some skill, but have a well-defined solution.

They don't require true originality or cleverness. Barrelling through them with adequate but not outstanding skills is more than enough.

Hacker systems like Linux, Vim, and Emacs, offer exactly this. You can tinker with them to solve consecutive microproblems in a satisfying way. Likewise other standard projects like working with vintage hardware or repurposing a consumer product to do something interesting.

This kind of work generates dopamine, where spending four days trying to track down an incredibly subtle bug in a giant stack owned by a few tens of people generates frustration.

So it's not that employees don't care, it's because some work really is hard and frustrating, and solving tractable problems is far easier and more satisfying.

But is it productive? Even educationally? Not necessarily.

[reinitctxoffset]

vi and emacs were designed by legendary computer scientists at two poles of the keystroke latency gradient. Bill Joy was on a model from an apartment in Berkeley, RMS was codifying the collected wisdom of a whole pool of elite typists on TECO and was doing so on the kind of connections at the MIT AI lab. Both of them were more or less stuck with QWERTY.

A keyboard interaction paradigm isn't a given chip or a driver for one. It is closer to UTF-8 than to Win 32. CUA is the Salesforce of such.

Ginger Bill, like many, is asserting that just because he's never encountered a bottleneck, there isn't one.

I'm not sure if that's arrogance or self-doubt puffing it's chest, but it ain't big dick energy.

[stackghost]

RMS may be legendary but he's no John Carmack or whomever else. I use emacs every day, and nobody who does the same can honestly say the foundations are good. The performance is atrocious. The UI locks up when you make network calls because the whole thing is single threaded. The whole thing is a mess of spaghetti code and there are multiple instances of core developers like Eli Zarerski admitting on emacs-devel that they don't know how <internal core system> works.

RMS is a visionary but as an actual software developer he's pretty mid.

[brabel]

You’re judging RMS skills based on the current performance of a tool he created 40 years ago using the tools available at the time. That’s wild. You complain about emacs being single threaded but computers in the 80s had a single core. Software at that time was always single threaded. By the time multiple cores became available, emacs wasn’t RMS’s personal project anymore and with lots of users it couldn’t just replace the core to make it multithreaded.

Tell me what Carmack has written that’s still widely used but did not start with the same “problems” as emacs.

[iLemming]

Emacs is just old. Its foundations (as in the general design) are truly fantastic. I still don't understand how the heck not a single other editor over so many years has even considered replicating ideas like indirect buffers. That alone is a truly brilliant idea, and there are so many more.

Performance is atrocious today. At some point, a couple of decades ago, it might have been considered superb, but some may still remember "8 megabytes and constantly swapping". Emacs can be slow, yet its keyboard latency is still better compared to some other, more modern tools.

I'm not disagreeing with you, Emacs can be so damn annoying, and yet paradoxically remain enormously useful. Sadly (or otherwise), there's still no meaningful alternative to it, nothing even comes close. Lem has a promising story, but I remain skeptical. I think Emacs gets core C improvements sooner than Lem reaches meaningful, practical parity, although I might be wildly wrong in my prediction simply because I don't understand the scale of entanglement of the C-written core of Emacs, yet surely it's probably easier than porting the gigantic body of Elisp in existence to work in Lem.

I can't really comment on RMS' software developer skills - I have never directly reviewed his code. Perhaps, in modern times he'd be considered a "no hire", because being a software developer today requires a little bit more than just being a brilliant code writer.

[achenet]

sorry for the stupid quesiton, but why do you use Emacs daily if you consider the performance atrocious and the foundations unsound?

Do you have to use it for work? Do you just consider other editors to be even worse, so Emacs is the best of a bad bunch?

[tonyarkles]

> Do you have to use it for work? Do you just consider other editors to be even worse, so Emacs is the best of a bad bunch?

Not who you’re asking but:

- I have a very long legacy of both muscle memory and “just right” coziness in my Emacs environment, that has followed me around from machine to machine since about 2003.

- I have flip-flopped between GUI Emacs and terminal Emacs probably a dozen times, with my most recent flop being due to Codex and Claude Code, which I run side-by-side with Emacs in a split pane tmux window.

- Yes, best of a bad bunch. I am also reasonably comfortable in Vi(m) but dislike how it handles having many open files, which is unfortunately necessary for most of the work I do.

- I have used VSCode off and on over the years as well, most recently with Gemini, but found the GUI experience quite frustrating and the lack of a CLI option ended up being a show stopper (I sometimes need to write code over SSH and the way VSCode handles remote editing is highly unpalatable to me)

Edit: one other nice perk that I discovered the other day: Claude is quite good at elisp. I was having a really weird issue that seemed like it sat at the intersection of a few packages interacting funny. Put Claude on the problem, got a very detailed explanation of how three packages had evolved and how one of them hadn’t caught up with subtle changes the other two had done. Put together a patch and suggested I make a PR to upstream. I haven’t fully reviewed the patch but the bug seems fixed properly.

[iLemming]

Emacs is not an editor. It's a Lisp-driven text orchestrator with a built-in editor. You can type your text in whatever IDE and still control everything through Emacs.

[kayo_20211030]

> try to design the internal tools in such way as to make the users fall into a pit of success.

Yes. I couldn't agree more. The tools have to make it quick and easy for the users to succeed - as invisible as possible, and transparent to what a user wants to achieve.