6 ms·

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

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.

lcnPylGDnU4H9OF 2mo ago
> 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 2mo ago
  Here's some additional context on the phrase, for today's lucky ten thousand[0]: https://blog.codinghorror.com/falling-into-the-pit-of-success/ https://blog.codinghorror.com/falling-into-the-pit-of-succes... [0]: https://xkcd.com/1053/ https://xkcd.com/1053/
  - bch 2mo ago
    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 https://perl.fandom.com/wiki/TIMTOWTDI [1] https://en.wikipedia.org/wiki/Zen_of_Python#Principles https://en.wikipedia.org/wiki/Zen_of_Python#Principles
lanthissa 2mo ago
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 2mo ago
  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.
cws_ai_buddy 2mo ago
[flagged]
anal_reactor 2mo ago
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".
weitendorf 2mo ago
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.
ozim 2mo ago
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.
sbloz 2mo ago
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.
kayo_20211030 2mo ago
> 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.
reinitctxoffset 2mo ago
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 2mo ago
  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.
  - iLemming 2mo ago
    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.
bombela 2mo ago
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 2mo ago
  Excellent idea; it's good practice to do that with APIs, so why not with command-line tools as well?
- deleted 2mo ago
  [deleted]
nullsanity 2mo ago
[dead]

lcnPylGDnU4H9OF 2mo ago

> 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 2mo ago
Here's some additional context on the phrase, for today's lucky ten thousand[0]: https://blog.codinghorror.com/falling-into-the-pit-of-success/ https://blog.codinghorror.com/falling-into-the-pit-of-succes... [0]: https://xkcd.com/1053/ https://xkcd.com/1053/
- bch 2mo ago
  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 https://perl.fandom.com/wiki/TIMTOWTDI [1] https://en.wikipedia.org/wiki/Zen_of_Python#Principles https://en.wikipedia.org/wiki/Zen_of_Python#Principles

lanthissa 2mo ago

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 2mo ago
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.

cws_ai_buddy 2mo ago

[flagged]

anal_reactor 2mo ago

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

weitendorf 2mo ago

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.

ozim 2mo ago

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.

sbloz 2mo ago

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.

kayo_20211030 2mo ago

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

reinitctxoffset 2mo ago

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 2mo ago
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.
- iLemming 2mo ago
  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.

bombela 2mo ago

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 2mo ago
Excellent idea; it's good practice to do that with APIs, so why not with command-line tools as well?
deleted 2mo ago
[deleted]

nullsanity 2mo ago

[dead]