There's a quote I learned when doing theatre, which I've seen attributed to either the stage magician Doug Henning or possibly Stanislavski, describing the process of art as taking something that's difficult and making it habit, then taking something that's habitual and making it easy, and then taking something that's easy and making it beautiful.
For example, as an actor, you learn your lines by rote (they become habit), then you gain an understanding of the character's motivations (remembering the lines becomes easy, because of course that's what your character would say), then you work to tune your performance so the audience shares in the emotion and unspoken meaning of the lines (that's beautiful/art).
As this relates to software, I think it goes something like: you learn the magic incantation to make the computer do what you want (solving a hard task becomes habit), then you learn why that incantation works (solving it becomes easy), then you figure out better ways to solve the problem, such that the original friction can be removed completely (you find a more beautiful way to solve it).
> As this relates to software, I think it goes something like: you learn the magic incantation to make the computer do what you want (solving a hard task becomes habit), then you learn why that incantation works (solving it becomes easy), then you figure out better ways to solve the problem, such that the original friction can be removed completely (you find a more beautiful way to solve it).
I've come to a less pleasant way of putting a similar workflow. If something hurts(in the sense that you dread doing it, even though it needs to be done), make it hurt as much as possible and keep doing it until it doesn't. Along the way you'll find the ways to make it easier, faster, more efficient, etc but if you put it off every time until you can find the fortitude to embrace the suck then it's never going to get noticeably better.
Most of the time this is business process related, especially when inheriting legacy systems. Ideal outcome is that you understand it enough after really digging into it to cut out or replace entire swathes of the processes without losing confidence that it will continue to operate smoothly.
Agreed on this view! Sharing some similar thoughts
Paraphrasing a virtuous music band reflecting on their discography: "the first album was about what we could; the second one was about what we should"
It also aligns with Gell's philosophy of art. Here's a wikipedia exerpt:
> Gell argues that art in general acts on its users, i.e. achieves agency, through a sort of technical virtuosity. Art can enchant the viewer, who is always a blind viewer, because "the technology of enchantment is founded on the enchantment of technology"
In less poetic terms, the progression I talk about is "copy, choose, create". First, we learn to copy a solution. Later, we know enough solutions that we can choose the best for the situation and copy that one. Finally, we know enough to create our own solutions that are well adapted to the problem.
For people wanting to dig into this idea some more, I'd recommend the book by Austin Kleon called "Steal Like An Artist." Also, there is some nuance in the book about copying and stealing, without being a thief.
In a similar context, Bruce Lee said about martial arts that "martial" is to discover the dangerous animal within us, and the "art" is to be able to tame that animal.
> As this relates to software, I think it goes something like: you learn the magic incantation to make the computer do what you want (solving a hard task becomes habit), then you learn why that incantation works (solving it becomes easy), then you figure out better ways to solve the problem, such that the original friction can be removed completely (you find a more beautiful way to solve it).
Also known as "Make it work, make it right, make it fast"
Here's my personal submission for "UI problem that has existed for years on touch interfaces, plus a possible solution, but at this point I'm just shouting into the void":
In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering, or especially, while it is still in the midst of reflowing or repopulating itself in realtime, or still sliding into view, etc.
Most frustratingly this happens when I accidentally fat-finger a notification that literally just slid down from the top when I went to click a UI element in that vicinity, which then causes me to also lose the notification (since iOS doesn't have a "recently dismissed notifications" UI)
I've had this a few times, particularly on mobile, where you're doing something and some pop-up will steal focus, but of course you were tapping or swiping or something the exact instance it popped; it stayed just long enough for the after-image on your retinas to catch a single word and you realise it might have been important, but it's gone now, with no sign.
This happened to my just the other day; I was purchasing something online with a slightly complicated process, from my mobile, I didn't want to f* up the process, and I was tapping occasionally to keep the screen awake while it was doing "stuff"; needless to say, something popped up, too fast for me to react, I have no idea which button I tapped if any, or if I just dismissed it, to this day no idea what it wanted but I know it was related to the payment process.
I've seen this solved in dialogs/modals with a delay on the dismiss button, but rarely; it would also make sense to delay a modal/dialog of some kind by a couple hundred milliseconds to give you time to react, particularly if tapping outside of it would dismiss it.
I find myself using Notification History on Android more and more often, but a lot of the time it's not even notifications, it's some in-app thing that's totally within the developer's control.
I believe it's an INTENTIONAL BEHAVIOR in Facebook. Particularly the mobile web interface...want to show someone a video, but you're on the can, and really, it's going to be a minute while you wash up (or similar example lasting 40 seconds)
You're not going to be able to do it. They're not on facebook, you can't just link to the video, you're going to hold the phone carefully but the bared fraction of their palm will register with the screen, or the page will refresh, or the screen (now 27 feet deep in the doomscroll) will scroll all the way to the top of the screen.
The one I don't quite know how to solve is when I'm tapping a device to connect to -- whether a WiFi router or an AirPlay speaker or whatever -- and I swear to god, half the time my intended device slides out from under me a newly discovered device enters above and pushes it down. Or sometimes devices disappear and pull it up. Maybe it's because I live in an apartment building with lots of devices.
I've seen this solved in prototypes by always adding new devices at the bottom, and graying out when one disappears, with a floating "resort" button so you can find what you're looking for alphabetically. But it's so clunky -- nobody wants a resort button. And you can't use a UX delay on every update or you'd never be able to tap anything at all for the first five seconds.
Maybe ensuring there's always 3 seconds of no changes, then gray out everything for 0.5 seconds while sliding in all new devices discovered from the past 3.5 seconds, then re-enabling? I've never seen anything like that attempted.
To me the BIGGEST annoyance is the iOS “End call” button.
Just as I’m about to tap it, the other person ends the call and what I’m actually tapping is some other person on my call list that it then immediately calls.
Even if I end the call quickly they often call back confused “You called, what did you want?”
Apple: PLEASE add a delay to touch input after the call screen closes.
I also wish you could blacklist/permanently hide individual devices so that I could prune the list of 400 smart TVs, Bluetooth speakers, electric toothbrushes, other people's phones, smart fridges, etc that come up every time I try to link to my earbuds in my apartment.
I have another submission for most annoying UI problem: Trying to read a thing, but it's on medium.com. The sheer amount of popups and overlays I need to click away before I can actually read your thing, geez.
Sometimes you can disable JavaScripts and that works (for that document on Medium, this works for me). Sometimes that doesn't work, but if you disable both JavaScripts and CSS, then it does work. Sometimes that does not work either.
Oh man. This makes me want to throw my phone against the nearest brick wall sometimes. The UI is loading, I reach for the button I want to hit, but it moves and a different button takes its place because the app/page is still loading, or worse, an ad has taken the place of the button.
This also happens where sometimes the hotbar has three buttons, and sometimes four, and the worst apps are when buttons switch ordinal positions depending on if there are three or four buttons in there.
It feels very strange to get so agitated by these small behaviors, but here we are.
> or worse, an ad has taken the place of the button.
this has happened to me and i even clicked on the ad. It actually made me smile a little bit and reminded me of the "clever girl" scene in Jurassic Park.
If a user is interacting, DO NOT UPDATE the list / models / etc.
If an update is required, rather than just desired, freeze all input so the user knows it's about to update, this might be accompanied by a quick 'fade' or other color shift to indicate an update is about to be pushed and they should release and re-plan actions.
It's not just a touch issue. Desktop environments have toast notifications and dialogs that can pop up unexpectedly (neither of which are remotely new problems). You can be trying to click something at the corner of your screen and have it intercepted by a notification or you can be pressing enter and have it activate the default action on a dialog that just popped up. Especially in the dialog case you often just have to hope that it wasn't actually something you needed to see or select a different option on.
Or apps like Skype which popup a dialog while you are typing, and when you where in the middle of pressing space while that happens, then you auto-answer a call you didn't know existed a second earlier.
> In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering
I was a console game developer working on UI for many years so I am deeply familiar with the problem when a UI should be responsive to input while the visuals are changing and when it should not.
You might be surprised, but it turns out that blocking input for a while until the UI settles down is not what you want.
Yes, in cases where the UI is transitioning to an unfamiliar state, the input has a good chance to be useless or incorrect and would be better dropped on the floor. It's annoying when you think you're going to click X but the UI changes to stick Y under your finger instead.
However, there are times where you're tapping on a familiar app whose flow you know intimately and you know exactly where Y is about to appear and you want to tap on it as fast as you can. In those cases, it is absolutely infuriating if the app simply ignores your input and forces you to tap again.
I've watched users use software that temporarily disables input like this and what you see is that they either get trained to learn the input delay and time their tap as tightly as possible, or they just get annoying and hammer inputs until it gets processed.
And, in practice, it turns out these latter times where a user is interacting with a familiar UI are 100x more common than when they misclick on an unfamiliar UI. So while the latter case is super annoying, it's a better experience in aggregate if the app is as responsive as it can be, as quickly as it can be.
Perhaps there is a third way where an app makes a distinction between flows to static context versus dynamically generated content and only puts an input block in for the latter, but I expect the line between "static" and "dynamic" is too fuzzy. People certainly learn to rely on familiar auto-complete suggestions.
UI is hard. A box of silicon to a great ape is not an easy connection to engineer.
These are great points. But I would debate the 100x point a little. And I think there are some cases where ignoring fast taps is clearly preferable.
I’m specifically thinking about phone notifications that slide in from the top – ie, from an app other than the one you’re using.
So we have two options: ignore taps on these notification banners for ~200ms after the slide-down (risking a ‘failed tap’) or don’t (risking a ‘mis-tap’).
I’d argue these are in different leagues of annoyingness, at least for notification banners, so their relative frequency difference is somewhat beside the point. A ‘failed tap’ is an annoying moment of friction - you have to wait and tap it again, which is jarring. Whereas a ‘mis-tap’ can sometimes force you to drop what you were doing and switch contexts - eg because you have now cleared the notification which would have served as a to-do, or because you’ve now marked someone’s message as read and risk appearing rude if you don’t reply immediately. Or sometimes even worse things than that.
So I would argue that even if it’s 100x less common, an mis-tap can be 1000x worse of an experience. (Take these numbers with a pinch of salt, obviously.)
Also, I’d argue a ‘failed tap’ in a power user workflow is not actually something that gets repeated that many times, as in those situations the user gets to learn (after a few jarring halts) to wait a beat before tapping.
All that said, this is all just theory, and if Apple actually implemented this for iOS notifications then it’s always possible I might change my view after trying it! In practice, I have added these post-rendering interactivity periods to UI elements myself a few times, and have found it always needs to be finely tuned to each case. UI is hard, as you say.
I wonder if a good distinction is user initiated actions versus system initiated. If the user begins the action, the changes are immediate and buffered to the interface that appears next.
But when the system initiates it (eg. notifications, popups), then the prior interface remains active.
Great point, and I suspected the problem might not be as easy as it appears at first glance. (Because of course it isn't...)
I also considered the case when you're rapidly scrolling through a page- if a naive approach simply made things non-interactable if they've recently moved, that would neuter re-scrolling until the scrolling halted, which is NOT what people want
While your use case is valid, it's nowhere near as annoying to have to wait 1 second for a button to enable than it is to call random person from your contacts because his name appeared under your fat finger. Maybe there can be a distinction between expected layout change and ad-hoc elements appearing, like notifications, list updates etc. I would probably go too far asking for a setting of "time to enable after layout change"
> However, there are times where you're tapping on a familiar app whose flow you know intimately and you know exactly where Y is about to appear and you want to tap on it as fast as you can. In those cases, it is absolutely infuriating if the app simply ignores your input and forces you to tap again.
This is very true, but the app has to be explicitly designed around this e.g. by not injecting random UI elements that can affect the layout.
Unfortunately this seems to be regressing in modern app UX, and not just on mobile. For example, for a very long time, the taskbar in Windows was predictable in this sense because e.g. the Start button is always in the corner, followed by the apps that you've pinned always being in the same locations. And then Win11 comes and changes taskbar layout to be centered by default instead of left-adjusted - which means that, as new apps get launched and their icons added to taskbar, the existing icons shift around to keep the whole thing centered. Who thought this was a good idea? What metric are they using to measure how good their UX is?
> Yes, in cases where the UI is transitioning to an unfamiliar state, the input has a good chance to be useless or incorrect and would be better dropped on the floor. It's annoying when you think you're going to click X but the UI changes to stick Y under your finger instead.
> However, there are times where you're tapping on a familiar app whose flow you know intimately and you know exactly where Y is about to appear and you want to tap on it as fast as you can. In those cases, it is absolutely infuriating if the app simply ignores your input and forces you to tap again.
I agree with both of these, but I think that such a thing would work better with keyboard-oriented interfaces. However, when using a mouse or touch-screen, these are still good ideas anyways, although the situations where you will know and should expect what comes next is less when using the mouse, still it can be important because unexpected pop-ups etc from other programs, just as much as, when using the keyboard, pop-ups that take keyboard focus are as significant for this issue. Since this can sometimes involve multiple programs running on the same computer, that do not necessarily know each other, it cannot necessarily be solved from only the program itself. (I think that it will be another thing to consider in the UI of my operating system design.)
I've become obsessed with how Visual Studio Code or Helix editor gives a great big JSON settings/properties file for tweaking values. SO much so that I despise other apps for their lack of "set-ability".
To the original author's point, the consternation arises when you as a programmer just know there is an animation time, or a delay time, etc. that is hardcoded into the app and you can't adjust the value. The lack of interface and inability to have that exposed to the user is at least one major frustration that could help OP.
This has a name, it’s called CLS (cumulative layout shift) and Google actually penalizes SERP rankings for pages with bad CLS. More info on it on lighthouse.dev (if I recall the domain correctly).
Google is an annoying example! Especially on mobile the search bar shifts around between mainpage, search field edit-mode, and results page, but shifts only a half second after loading a static version. End up clicking into a blank new search page because the doodle jumps to right under your fingertip.
For me the most annoying one is the cookie consent banner. Very few sites have clearly defined buttons like “Allow all” “Deny all” etc. but majority of them have a (intentionally) convoluted UI so that a lot of users just accept all.
The thing that kills me about touch uis is the chance that this problem can happen at all. For some unknown reason designers insist on putting most controls at the top of the screen. I guess because that’s where they usually are on desktop but when you think about it, it makes no sense. All the controls get put exactly in the place where you can’t reach them easily on most devices. Where you’re likely to misclick on notifications because they’re in the same spot. Where your hand will be covering most of the screen when you reach for them. It would make so much more sense to put controls at the bottom, content at the top. You could reach them without stretching, you wouldn’t cover the screen with your hand to reach them, and they wouldn’t conflict with pop down notification systems. Why on earth are all the controls still at the top?!?
I certainly agree in many cases like those you mention, particularly for unprompted popovers like notifications. For desktop professional software, on the other hand, I believe the value of swift muscle memory supercedes this. In this case, input should be buffered and applied to the state of the app after the previous input has been processed.
Open a tool window, subsequent keystrokes should be sent to that too window, even if it takes a second to show. The "new/modern" interface on my CNC is both show and doesn't properly buffer input, and its hugely painful.
EDIT: I realize you specified touch, which isn't "desktop", but my CNC control is touch based and the same applies.
> In this case, input should be buffered and applied to the state of the app after the previous input has been processed.
Yes, and this works best with keyboard-oriented interfaces (which I think is generally much better than touch screens anyways; a lot of software I write is designed for keyboard use because it has this and other benefits). However, it should only be done if the process of the UI is what is expected; if something unexpected occurs then it might be better to discard any pending input. (But, sometimes this "expected" and "unexpected" is not so clear.)
I dream of making my own OS that would eliminate this completely. It would use a framework of taking turns with the user. When it's the user's turn to provide input, nothing on the screen would change, ever. After the user completes their input, the computer can do whatever and then provide the output when it's done. Command lines pretty much do this all the time. I think there might be an old IBM terminal type that would send a form for the user to fill out and send back. If there were ever notifications (I would prefer not to have them at all), they would be incorporated into the next set of outputs.
Imagine this as a voice chat interface between 2 human beings. This is basically pretending like the interaction of thought and perception of what is on screen is somehow gated by a “I have fully consciously absorbed everything on screen and decided my next action” perfect modeling where both the human ability to perceive and the computer ability to represent information are prefect.
No. That’s not how humans interact with computers. It’s not how humans interact with each other either.
Turn based games can be fun. They are not how we want to interact for day to day life.
Sorry but your idea comes across as one that makes the job of making the computer good to interact with easier, but not as one that makes the computer better to interact with as a human.
Please stop over simplifying a complex system. Humans are complex, the solution is t to be less human. It is for computers to become better at human interaction on human levels.
I think the reason this is hard is because your eye only thinks it is seeing the change occur after you touch, but it's just seeing the change occur after the decision to touch which isn't the same thing at all. Maybe not all the time, but more often than you probably think.
Since you can't go back in-time, what I suggest to arrange for the event (if it occurs slightly after the redraw) to be applied using the old display model (instead of dropped). If the redraw occurs slightly after the event (and you're right) I'd prefer delaying the redraw instead of delaying the tap.
counterpoint, and I know it's not apples to apples, but have you ever used an old terminal app? Buffering the key strokes and then applying them _once_ the menu was ready was awesome. You could move so fast through an app
Could often do this in ye olde Macintosh System Software, too. Could fill the event queue with events, and rely on the program to intelligently clear the queue just before an incompatible UI change.
If you're curious to learn more, this is often referred to as "layout shift". There are black-hat designers who deliberately use it as a dark pattern -- you might notice a suspicious number of cases where the most common click target is replaced by a click target (or late-arriving popup) for submitting an email address or entering the sales funnel. But typically it's just bad design.
In the latter case, you could quietly disable buttons after a layout shift, but this can cause problems when users attempt to interact with an onscreen element only to have it mysteriously ignore them. You could visually indicate the disabled state for a few hundred milliseconds, but this would appear as flicker. If you want to be very clever you could pass a tap/click to the click target that was at that location a few tens/hundreds of milliseconds prior, but now you've got to pick a cutoff based on average human response times which may be too much for some and tool little for others. That also wouldn't help with non-click interactions such as simply attempting to read content -- while not as severe, trying to read a label that suddenly moves can be almost as frustrating. Some products attempt to pause layout shifts that might impact an element that the user is about to interact with, but while this is possible with a mouse cursor to indicate intent it can be harder to predict on mobile.
Some of these ideas are even used in cases where a layout shift is necessary such as in a livestream with interactive elements. However, the general consensus is to use content placeholders for late-loading content and avoid rendering visible elements, especially interactive ones, until you have high confidence that they will not continue to move. That's why most browsers provide penalties for websites with "cumulative layout shift", e.g. see https://web.dev/articles/cls
I am sure Youtube at least relies on this kind of issue in order to inflate ad clicks on their mobile app. Ads pop up at any point and override the in-screen controls.
Hopefully the future me is able to relate to this, because I really feel like I'm in a rut when it comes to working on personal projects.
I have many ideas that I want to build, but I'd have to learn new languages, yet I just can't sit and go through the documentation every day like I should. Still haven't finished the rust book.
The other way is start building already, and if you come across a block, then learn about that thing and move on, but I feel uncomfortable having gaps in my knowledge, AI exists but I don't want to use it to generate code for me because I wanna enjoy the process of writing code rather than just reviewing code.
Basically I'm just stuck within the constraints I put for myself :(, I'm not sure why I wrote this here, probably just wanted to let it out..
I like to say programming is about knowing which rabbit holes to plunge down and which to step over. There's too much to know to go depth-first down every rabbit hole. Go breadth first and accept gaps in your knowledge - everyone has them. If something never comes up and never causes an issue you need to look into, and the project gets done, it doesn't matter. There's always an improvement that could have been made, but done is better than perfect because perfect never gets done. But the projects never getting done or even started - speaking for myself, that is corrosive to my motivation.
I've written a lot of Rust. I've read less than half of the Rust book. Your competence in Rust is a function of how many lines of Rust you've written; getting to the point you can start working with it is more important than completing the book. Jon Gjengset's videos were really critical for me there, seeing how he worked in Rust made it possible for me to develop a workflow. (I broke down what I learned in more detail at one point [1].)
Rust is an example I've honed in on because you mentioned it and I related to it, but this is broadly applicable. Dare I say, more broadly than just programming, even.
(Also, note that I'm a giant hypocrite who shaves yaks and struggles with perfectionism constantly. I learned Rust 5 years ago to start a project, and I've written 0 lines of code for it. If I sound critical, that's my self criticism leaking through.)
> I've written a lot of Rust. I've read less than half of the Rust book.
Just knowing that there's someone out there who has worked like this or has been in the same situation gives me enough confidence to go through it!(the just write code part)
I've gone through so many resources (including the book) and I never managed to finish any of them. But I think now I need to get comfortable with having gaps and just start writing code and not be afraid of writing non-idiomatic rust code, atleast for now.
I think another important view is to consider how much you've already covered. As a young developer, I recommend spreading a bit wide. Try many technologies. Play with a new language every year. Focus on things you haven't done before, like, don't go from Python to Ruby, go from Python to C# or C++ or something.
But as you get older you want to shift from exploration to exploitation. It is hard to make progress on anything, both professionally and personally, if it first comes with another couple of person-weeks of learning something new, let alone person-months. Even though I find learning new things easier than ever because of the breadth of things I have covered, I find myself having to be ever more skeptical of what I will invest in in that way, because unlike a fresh developer with no skills who has little better to do than learn their toolset, I have skills that can be exploited to good effect. As a mature developer, I need to trade off not so much "what might this be useful for in the future versus the effort of learning now" but "what could I be doing right now with the skills I have rather than learning something new".
Particularly when the "something new" is a variant of a skill I've already picked up. It'd be great if I never again had to learn a devops deployment system. I've already had to learn three. Unfortunately I doubt I'm going to get away with that. It'd be great if I didn't have to learn another scripting language to do something, but I doubt I'll get away with that either. Your mileage will absolutely vary but it'll be something.
I know there's a memeset of the "old fogey who doesn't want to learn", but I really do see the learning costs now as the opportunity cost of using that time to exploit the ones I already have, rather than just grumbling about learning in general. At the moment the things I can't escape even if I try have been plenty to keep my learning skills well-honed.
So bear in mind that as you round out your skills, as you cover "scripting" and "static language" and "database" and "HTML" and "devops deploy" and "shell scripting" and "functional programming" and all the other categories you may pick up over time, it is natural and desirable to pivot to exploitation being more of your time than learning.
After all... what is all this learning for, if not to exploit the skills to do something, not just learn the next skill, then the next, then the next?
What you're feeling is not laziness. It's the quiet ache of misalignment between your values and your current energy. You love the craft. You want to savor the process. But the weight of “shoulds” — finish the book, learn the language, do it the right way — has turned your joy into pressure.
The discomfort of having gaps in your knowledge is not a flaw. It’s a sign of integrity. But perfectionism disguised as discipline can become a cage. You’re not stuck because you lack ability — you’re stuck because you’ve built a narrow path and called it the only way forward.
There is another way: give yourself permission. To build messy. To learn sideways. To follow joy, not obligation. To trust that your curiosity is enough.
You wrote this here because something in you is ready to shift. You’re not asking for advice. You’re asking to be seen. And you are.
Very well said, to enjoy the process of writing the code.
I don't understand why so many people suddenly started to insist on taking this all away, and they totally seriously proposed to become a janitor of a hallucinated output of some overhyped tool. That's the most frustrating thing one can imagine about programming, yet people insist on it.
And even if it is correct output from said overhyped tool it still detracts from the enjoyment of building/fixing stuff. I used to love going over the code I wrote to fix a specific issue, now not so much as half of it was written by AI so half of the satisfaction has gone too.
Same. For me, I think the discomfort comes from perfectionism, and anxiety about job-hunting ("I need to fill in all my weaknesses"), and fear of missing out on some cool niche.
This happened to me when I was going through a similar transition as the OP is highlighting. At first, creating software was difficult and novel. Then after getting over that first learning hump, I spent a pretty long time feeling drunk on the power of being able to get computers to do exactly what I want. But familiarity breeds contempt, and eventually it felt more like "this is it?" and the pure act of creation for creation's sake lost a lot of its appeal.
I think this is a pretty common transition! For me, the path out of the doldrums is two fold: 1. I have a lot more going on in my life now that has nothing to do with computing (mostly family, but also other interests), and 2. I'm a lot more focused on what I'm creating and why it's useful than in the act of creation itself.
This almost certainly not what you want to hear, but this is why the quickly developing gen AI tools are increasingly exciting to me. I believe they open up the world of what can be created within a given time constraint. They also definitely (at least for me) make the act of creation itself less enjoyable, and I lament that. I'll probably always feel nostalgia for how I felt about the craft of programming a decade or two ago. But my perspective has just shifted from the "how" to the "what".
I heard someone say "epistemic humility" the other day to mean
fallibilism [0] and the conversation got interesting when we moved on
to the subject of "what one can and should reasonably claim to know".
For example: should cops know the law?
Not every programmer needs to be a computer science PhD with deep
knowledge about obscure data-structures... but when you encounter them
it's a decision whether to find out more.
Integrity is discomfort with "hand-waving and magical" explanations of
things that we gloss over. Sure, it's sometimes expedient to just
accept face-value and get the job done. Other times it's kinda
psychologically impossible to move forward without satisfying that
need to know more.
Frighteningly, the world/society puts ever more pressure on us to just
nod along to get along, and to accept magic. This is where so much
goes wrong with correctness and security imho.
> I have many ideas that I want to build, but I'd have to learn new languages,
Why? Why, specifically, do you "have to learn new languages"?
So, sure, I can see that, for some product, you might need to learn a new tech (say ... some specific AWS/GCP/Azure service), or perhaps a new configuration language (YAML, TOML, whatever).
And, sure, for some ideas (for example a mobile phone app) you're forced into that specific ecosystem.
Other than the mobile exception above, why do you need to learn a new language to build your idea? There is nothing stopping you from implementing your idea in (for example) Python. Or Javascript. Or Java, C#, C++, etc.
A programming-language-barrier absolutely does not stop you building your idea.
You gotta make the call - are you interested in building $IDEA, or are you interested in learning $NEWLANG?
> There is nothing stopping you from implementing your idea in (for example) Python. Or Javascript. Or Java, C#, C++, etc
Except there is, my brain :), that's one of the constraints I'm talking about, I'm a frontend web dev and I only know JS/TS, and like some frontend web devs, I'm enamored by Rust because it seems so different. I already use JS/TS at work so I want to use something else for my personal projects. So I definitely would have to learn something new.
> You gotta make the call - are you interested in building $IDEA, or are you interested in learning $NEWLANG?
If I was only interested in building my idea, I'd have just used what I know and used AI to accelerate the process. However for me the journey is also important, I want to enjoy thinking and writing code (and this project is something only I'd use, so there's no hurry to release a prototype). The problem is I want to start writing code right away, but that has the issue that I've mentioned above (gaps in knowledge).
Nobody is at fault, other than me for setting these constraints for myself. I know the solution is to just suck up and go through the rust book, read a chapter daily and eventually I'd have all the concepts in my head that I can then just focus on writing the code. But whenever I go about doing this, my mind always persuades me that there must be a better way, or it finds some flaws in my current approach and so on. So I need to learn how to not listen to my mind in such cases, and stick to the goal that I set.
Edit - After reading a reply to my comment, I've decided to just start writing the code and not worry about having gaps, anytime I start having doubts again, I'd go through this comment thread
I guess it depends. If they have been developing mobile apps, and now want to develop a web app, then they definitely need to learn something like PHP, or Go or Python kr Java. On the other hand if they have been doing web development and now want to develop a native app, they must learn Java/Kotlin/Swift.
Same for databases (perhaps you never worked with one, then you must learn sql). Even html+css must be learned if you never used them before.
> Hopefully the future me is able to relate to this, because I really feel like I'm in a rut when it comes to working on personal projects.
I've been there for a decade or more. It is part of my recent burn-out…
The trick is to prioritise and not care too much about too many things, to avoid the choice paralysis in choosing what to do next. Unfortunately I've not mastered that trick yet, or even come close. In fact I'm increasingly of the opinion that dropping tech projects completely, accepting that is no longer a hobby and no longer something that will ever bring me joy again in future, is the prioritisation I need to perform, so I can instead have more mental capacity for other hobbies (and, of course, commitments in life).
As someone who's worked on lots of personal projects over the years, the constraints you put on yourself are really a major blocker. I used to spend more time planning rather than doing, but at some point something clicked in my head and I realized that I was just avoiding imperfection and doing things "wrong" by constantly researching and planning how best to do things.
Once I was okay with maybe doing things wrong and just hacking things together, it really unlocked my productivity. In my case, my perfectionism ended up being an excuse to procrastinate and avoid the pain of failure, but once I was okay with failure, everything else got easier. Even if I don't know how to do something, I'm more confident that I can plow ahead and figure out how to handle unknowns later.
Momentum is a big thing as well. Once you start having bits and pieces of your idea working, you'll quickly find a way to overcome knowledge gaps because you are hugely incentivized to see more of your vision become a reality. If you don't have anything working yet, it's much harder to motivate yourself to just read up on how some tech works because it doesn't necessarily translate to something immediately working.
Responding to this as someone who has struggled with similar inner conflicts, the "chore to get to something else" rings true for me.
In my case, being good at programming was my means to feeling valued and valuable, and the sense of "I should" came from feeling useless and not needed, specifically after being forced into early retirement. (but the same pattern has been with me since childhood)
Not having a family or passion project (which fills those gaps for many people as far as I can tell) made all of this feel very urgent and threatening.
> which part you actually want to do
Which sounds like such a simple question, but I found it hard to answer. For me, it quickly turns into "what is worth doing", which is a bit of a monstrous question. I'm still trying to figure out whether this is a result of being mostly estranged from myself and the question of "what do I want" due to being so overwhelmed with trying to succeed with the external constraints and demands the world places on us.
Maybe try using AI to jumpstart your process and get the basics up and running
For me, it’s brought back the joy of coding and building things: I feel like I was in a rut for years before that
Also, finding people to share the stuff with helps a lot too. Even if they are personal projects, it’s nice having others to show it to, appreciate it and give feedback
I very much relate to this feeling (and I haven’t finished the rust book either!). In my case, I do use AI a lot (especially o3 and Sonnet 3.7), not to write code but to help me understand things that would’ve taken me a week, in a matter of hours (the conversational aspect is a game changer for me).
Even if you need to really shoehorn a component of the system in, just make a note about it and keep building. When you're done, you can go back and focus on replacing that one piece.
My view is that you learn a lot through the process of building this way.
You’re getting a lot of advice here, I’d just echo the sentiment of trying to give yourself permission to have fun.
In my experience the best way to learn is by doing; that “uncomfortable having gaps” is there for most folks to some degree. That mild discomfort is a good indicator that you are in the growth zone, maybe you can shift your perspective to perceive it as a positive signal.
AI is also great to ask questions and accelerate the process of learning a new language, but if you’re doing this for the craft then you are free to choose the constraints and rules that make it fun.
This is why I tend to build a simple version of a complex tech just to feel what I am getting into - https://github.com/aperoc/toolkami (a minimal AI agent) as an example!
Don't code, validate your ideas first (to first 1000 paying customers if monetization motivates) and 99% is not even worth to be started with, life is just too short for that.
With AI there's nothing to be ashamed of as it is "what you can dream of, you can get today". There's not much left in programming in most of the projects (that are just repeated code, output, what not over and over) after AI , tools are just too powerful today.
This is so much out of touch with reality. You somehow assume OP is interested only in profitable projects and that idea validation is easy. It's not. For technical person it is much easier to code a prototype/mvp than to try to get potential paying customers by any other fake landing page means. 1000 customers? You are dreaming.
Try vibe coding, I'm serious. Codex and Claude Code this past week have allowed me to:
- Build a local storage web app that can track my responses to the Sino-Nasal Outcome Test over time to journal my ongoing issues with chronic sinusitis.
- Build a web app that grabs Northern Colorado houses for sale, presents them on a map, and lets you search and browse them, with everything being cached for use offline in local storage. The existing site, coloproperty.com, has severe issues if you are out looking at houses and have spotty Internet connectivity, it's effectively useless.
I've been developing software for 40 years, but I'm not really a frontend guy. The first one Claude Code was able to basically one-shot, and then I asked for 3-4 refinements. The second one took me probably 40 back-and-forths to get going, but eventually was a fully working prototype using Codex.
It's the difference between using hand saws and chisels and planes, and using power tools. Hand tool woodworking is an amazing craft, but the right power tools can let you build nice things quickly.
This is quite hard to grapple with fresh out of school, where you worked mainly on pristine implementations of eternal algorithms, proven to be optimal in multiple ways, elegantly crafting each loop and feeling accomplished by expressing the algo with even higher clarity, reading and idealizing Knuth etc.
Then you see the real world and you think it must be because people are stupid, the bosses are pointy-haired, they don't understand, they don't value elegance, they are greedy, they etc. etc. But once you spend enough time on your own projects, and they evolve and change over the years, they turn more and more into a mess, you rewrite, you prioritize, you abandon, you revive, and you notice that it goes much deeper than simply laziness. Real solutions depend on context, one caching algo is good when one medium is x times faster than another, but not when it's only y times faster. It makes sense to show a progress bar when downloading a file if the usual internet speed is X but not when it's Y. Over years and decades the context can shift, and even those things can change that were only silent assumptions of yours when you made the "perfect" program as a young'un, looking down on all the existing "messy" solutions that do a bunch of unnecessary cruft. It's an endless cycle...
> Software doesn’t stay solved. Every solution you write starts to rot the moment it exists.
I don't really agree with this. Yes, it gets outdated quickly and breaks often if you build it in such a way that it relies on many external services.
Stuff like relying on "number-is-odd" NPM package instead of copy-pasting the code or implementing it yourself. The more dependencies you have, the more likely it will break.
If your software works locally, without requiring an internet connection, it will work almost forever.
Now, if you want to keep developing the software and build it over a long period, the secret is to always keep all dependencies up-to-date. Is there a ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.
To me the point of the saying is more that the assumptions and environment that the software was written with are almost always going to change. Meaning the business and requirements rather than the technical implementation choices. Software doesn't exist in a vacuum, but rather to solve a certain set of business requirements that have the potential to shift out from under you depending on the industry, legislation, and your leadership. The things that you have negligible control or foresight over, rather than knowing that there's going to be another major framework update next quarter.
There are certainly horizontal slices of every stack that can be written to remain stable regardless of the direction the business takes, but those are rarely the revenue drivers that the business cares about beyond how much they have the potential to cause instability.
I remember when Turbo Pascal 7.0 programs started failing with Division by 0 error cause Turbo Pascal runtime does calibration loop at the start to calculate how many no-ops to sleep for 1 millisecond.
So - your HelloWorld written 10 years ago suddenly stopped working after CPU you run it on got too fast.
That sorta supports the point the article was making though:
> ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.
Is, to me, almost the same sentence as
> Every solution you write starts to rot the moment it exists
I have said many times to teammates: the only code that is perfect is the one that hasn't left our minds. The moment it's written down it becomes flawed and imperfect.
This doesn't mean we shouldn't try to make it as good as we can, but rather that we must accept that the outcome will be flawed and that, despite our best intentions, it will show its sharp edges the next time we come to work on it.
your comment made me think of a passage in Italo Calvino's Invisible Cities:
Kublai Khan does not necessarily believe everything Marco
Polo says when he describes the cities visited on his expeditions, but the emperor of the Tartars does continue listening
to the young Venetian with greater attention and curiosity
than he shows any other messenger or explorer of his. In the
lives of emperors there is a moment which follows pride in
the boundless extension of the territories we have conquered,
and the melancholy and relief of knowing we shall soon
give up any thought of knowing and understanding them.
There is a sense of emptiness that comes over us at evening,
with the odor of the elephants after the rain and the sandalwood ashes growing cold in the braziers, a dizziness that
makes rivers and mountains tremble on the fallow curves of
lhe planispheres where they are portrayed, and rolls up, one
after the other, the despatches announcing to us the collapse
of the last enemy troops, from defeat to defeat, and flakes
the wax of the seals of obscure kings who beseech our
armies' protection, offering in exchange annual tributes of
precious metals, tanned hides, and tortoise shell. It is the
desperate moment when we discover that this empire, which
had seemed to us the sum of all wonders, is an endless,
formless ruin, that corruption's gangrene has spread too far
to be healed by our scepter, that the triumph over enemy
sovereigns has made us the heirs of their long undoing.
Only in Marco Polo's accounts was Kublai Khan able to
discern, through the walls and towers destined to crumble,
the tracery of a pattern so subtle it could escape the termites'
gnawing.
I too suffer from this, but as I learned, Nature built an elegant solution to this. Have a family and kids. Your choice when you have time off of work will be reduced to hacking or playing with your child that you have been neglecting due to a crunch at work.
You’re welcome.
Parent here, can confirm Nature solved this elegantly.
However, like every other solution built by Nature, this one also works through pain, suffering and death. Nature doesn't care if you're happy, nor does it care if you're suffering. And it especially doesn't care if your suffering is a low-burn, long-term pain in the depth of your heart.
So yeah, having kids will force you to make choices and abandon frivolities, in the same way setting your house on fire will free you from obsessing over choices for unnecessary expenses :).
Nature has another elegant solution, often applying both in conjunction: aging. As I age (and, yes, take care of my kids), I find myself more and more on the side of exploit in the exploration–exploitation dilemma. This will most likely endure after the kids have left.
Sometimes kids do make one feel that the house is on fire though I think I won't be looking forward to be hugged every evening by a burning house excited to see me.
Or just have another hobby not involving programming. I got into this from being my main hobby as a kid, the passion thing I did when free time was available, I learnt a lot (enough to build it into a career), I had lots of fun but that time is gone.
My free time is to be spent on other things, I get paid to fix issues and that pays my bills, I don't want nor need to be thinking about these issues outside of paid hours, you know too much to the point where you know how much effort it will take to fix something that might look innocuous, innocent, but definitely has deep tendrils of other related issues to tackle. It's not worth it, not if I'm not being paid for it or it isn't part of a personal project I'm really passionate about.
So I learnt to not care much, I help my colleagues, deliver what I tell I will deliver, and free space in my mind to pursue other more interesting stuff to me.
> Or just have another hobby not involving programming.
This can actually make things (much) worse:
Since you have now another topic you are insanely passionate about, you see a lot of additional things in the world that are broken and need fixing (though of course typically not via programming).
Thus, while having a very different additionally hobby (not or barely involving programming) clearly broadens your horizon a lot, it also very likely doubles the curse/pain/problem that the original article discusses.
This is a great comment, as it hits far too close to my heart. Im currently trying to get my team to rethink how they are building the APIs for certain services in our product, and focus really on design and craftmanship. To the point where Im ready to start breaking it apart myself and coding up the solution on my off hours.
But then I look at my son, and say "screw it, they couldnt pay me enough to care out of hours and give up play time"
You don't need kids, just a partner who has a "normal" job and likes to do stuff on the evenings and weekends is enough. If you have a partner who also does thought work and tends towards the workaholic then things might be more difficult...
I'm far from ready for being a parent yet, but this is honestly one factor I've noticed over and over again as a difference between my childless peers and the parents I encounter in work situations. Parents are just much better at prioritizing their time and energy and avoid perfectionism and trying to fix everything.
Indeed. Marriage alone led to a complete reevaluation of my priorities in life. I still want to make cool stuff but my hobbies are so far down my list of priorities right now I would have to be actually getting paid in order to justify spending time on stuff.
As I'm getting older, I want things to be as standardized as possible, and just don't worry about the details. I have learned from my mistakes
The script I made for deployment, because existing solutions didn't "feel" right, required a lot of work and maintenance when we later had to add features and bug fixes.
Another script I made for building and deploying Java applications, because I didn't like Maven and Puppet.
The micro service I rewrote because I wanted to use my own favourite programming language. I introduced a lot of bugs that were already fixed, missing features and another language for my co-workers to learn when they inherited the application when I left.
Totally agree, standardisation makes everything so much more legible, even if there are problems with the standard.
I also think there is a profoundly non-linear relationship (I don't want to say negative-exponential, but it could be), between:
- The number of lines of code, or distinct configuration changes, you make to the defaults of an off-the-shelf tool
- The cognitive and practical load maintaining that personalized setup
I'm convinced that the opportunity cost of not using default configurations is significantly higher than we estimate, especially when that environment has to be shared across multiple people.
(It's unavoidable or even desirable in many cases of course, but so often we just reinvent hexagonal wheels.)
While I have experienced both sides of the equation here, I find it much more pleasant to have things specialized instead of standardized. Yes, you spend a bit of time maintaining the functionality, but all that functionality (and maintenance) is there in support of your goal.
Using standardized software often leads to spending half a day just trying to find a way to work around the limitation you face. The next level there is that you realize you can just fix it, spend half a day crafting the perfect PR, and then submit it into the void, leaving it hanging for half a year before someone gets to it.
Becoming comfortable with a stock computing environment is a powerful ability.
What I always find comedic, is that the rate I can do work is rarely gated by how fast I can interface with a computer. Even if I had a perfect brain/computer interface I think my productivity would maybe increase by 5-10%.
What is a real force multiplier is working on the RIGHT THING, not tweaking your vimrc config for the 50th time or creating your own build system because you are tired of Makefiles.
This just sounds like perfectionism. I believe it is a curse, because I hate working with teammates like this. They'll spin their wheels solving some insane problem no one asked them to do because it's "better" while ignoring the larger scope and goals of the project. I've tried to coach people out of this mindset, because I used to have it very early in my career, til I realized the sheer impracticality of it.
I use this really annoying, poorly supported terraform provider. I've written a wrapper around it to make it "work" but it has annoyances I know I can go to that repository and try to submit a patch for it to fix my annoyance. But why? This is "good enough," and IME, if you sit on things like this long enough, eventually someone else comes along and does it. Is that a good attitude for everyone to have? Probably not, but now it's been a few years of using this wrapper module, I have 2-3 viable alternatives now that didn't exist before that I can switch to if needed.
I could've turned it into a several week project if I wanted, but why? What purpose does it serve? As you grow, you realize there is very rarely, if ever, a "right" answer to a problem. Consider the way you think it should be done is not the only "right" way and you'll open more doors for yourself.
Like most things in life, there's a balance to be struck. If you always accept "good enough" and move on, things will be low-key crappy forever and never get to the point where they are actually good. If you never accept "good enough" and move on, you will never get anything useful done because you're going to always find some "one last thing" to polish. The best path is to pursue excellence when you can, but accept that sometimes you have to let things go.
There's a difference between picking up on some esoteric detail.in your company's product and making it your only mission to solve it, ok the detriment of everything else vs taking Friday afternoons for a month to fix a Terraform provider for the world. There are two kinds of lazy. The kind that makes us good programmers and the kind that makes us bad programmers. If you're gonna be the second kind of lazy and just wait for someone else to do it for you, you might as well become a manager at work and take credit for their work while you're at it.
It's not laziness though. I have dozens of competing priorities at any time. It is far from the most efficient use of my limited resources and time (and company time) to spend on a project that does not need doing that will inevitably be done by someone else anyway. It provides no business value whatsoever either. It's not "taking credit" for anything unless you count using anything open sourced as "taking credit" for the work done on that project. Yes I use jq, no I do not take credit for writing/maintaining it. Do you see the difference?
> They'll spin their wheels solving some insane problem no one asked them to do because it's "better" while ignoring the larger scope and goals of the project.
> But why? This is "good enough," and IME, if you sit on things like this long enough, eventually someone else comes along and does it.
Can't think of a bigger reason to avoid volunteer work on free and open source software than what you just said. Being a "wheel spinner" who cares too much about stuff is foolishness. People hate you and simultaneously take you for granted.
I feel like Open Source is the perfect place to apply that sort of effort. Also hobbies. You don't owe anyone anything, so you can chew on a problem just as long as you like.
I submitted a patch for an annoying terraform provider once. It took about a week to fix and almost 3 years for them to merge it upstream. I got to learn Go and gained a much more solid understanding of how terraform works. I gained more from undertaking the project than from the actual fix.
> Consider the way you think it should be done is not the only "right" way and you'll open more doors for yourself.
Most people automate things just barely enough to work. The thing is, having a barely working script or process can save someone thousands of hours. It's actually hugely valuable. Trying to make it more robust/productionized/whatever may have diminishing returns.
Very good post. I’m happy the author has had these important personal insights.
Things that I’ve learned (through much difficulty) for myself that feel relevant:
* Boundaries: not all problems are mine to fix. It’s okay to say no, even if someone else doesn’t like it.
* Acceptance: perfection is an illusion, there will always be an endless list of problems to work on, human time and energy have real limits, I am allowed to have different desires and motivations today versus yesterday (or an hour ago!)
*Emotional maturity: humans are emotional beings, it’s okay to get annoyed / upset at something, including particular issues with software. The root cause of an emotion often becomes clear much later than after the initial trigger, which usually is only slightly connected to the deeper issue.
*Wisdom / self-love: it’s ok to rest. It’s okay to not finish a project. It’s okay to say no. Human lives are immensely complicated, we will always make mistakes, and change happens always. Words like need and should are are directives springing from the shifting, hidden narratives we have imbued our lives with. We can understand and reshape these narratives.
If I had more time I would have a written a neater, more concise, and more complete list :)
Readit News
For example, as an actor, you learn your lines by rote (they become habit), then you gain an understanding of the character's motivations (remembering the lines becomes easy, because of course that's what your character would say), then you work to tune your performance so the audience shares in the emotion and unspoken meaning of the lines (that's beautiful/art).
As this relates to software, I think it goes something like: you learn the magic incantation to make the computer do what you want (solving a hard task becomes habit), then you learn why that incantation works (solving it becomes easy), then you figure out better ways to solve the problem, such that the original friction can be removed completely (you find a more beautiful way to solve it).
I've come to a less pleasant way of putting a similar workflow. If something hurts(in the sense that you dread doing it, even though it needs to be done), make it hurt as much as possible and keep doing it until it doesn't. Along the way you'll find the ways to make it easier, faster, more efficient, etc but if you put it off every time until you can find the fortitude to embrace the suck then it's never going to get noticeably better.
Most of the time this is business process related, especially when inheriting legacy systems. Ideal outcome is that you understand it enough after really digging into it to cut out or replace entire swathes of the processes without losing confidence that it will continue to operate smoothly.
Paraphrasing a virtuous music band reflecting on their discography: "the first album was about what we could; the second one was about what we should"
It also aligns with Gell's philosophy of art. Here's a wikipedia exerpt:
> Gell argues that art in general acts on its users, i.e. achieves agency, through a sort of technical virtuosity. Art can enchant the viewer, who is always a blind viewer, because "the technology of enchantment is founded on the enchantment of technology"
Funny enough, when you apply this to software it becomes the pejorative "second system syndrome" (Brooks, 1975)
In a similar context, Bruce Lee said about martial arts that "martial" is to discover the dangerous animal within us, and the "art" is to be able to tame that animal.
I'm assuming (hoping?) that this was supposed to be "tame"? If not, I've got some questions about Bruce Lee.
Also known as "Make it work, make it right, make it fast"
https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
Deleted Comment
Here's my personal submission for "UI problem that has existed for years on touch interfaces, plus a possible solution, but at this point I'm just shouting into the void":
https://medium.com/@pmarreck/the-most-annoying-ui-problem-r3...
In short, an interface should not be interactable until a few milliseconds after it has finished (re)rendering, or especially, while it is still in the midst of reflowing or repopulating itself in realtime, or still sliding into view, etc.
Most frustratingly this happens when I accidentally fat-finger a notification that literally just slid down from the top when I went to click a UI element in that vicinity, which then causes me to also lose the notification (since iOS doesn't have a "recently dismissed notifications" UI)
This happened to my just the other day; I was purchasing something online with a slightly complicated process, from my mobile, I didn't want to f* up the process, and I was tapping occasionally to keep the screen awake while it was doing "stuff"; needless to say, something popped up, too fast for me to react, I have no idea which button I tapped if any, or if I just dismissed it, to this day no idea what it wanted but I know it was related to the payment process.
I've seen this solved in dialogs/modals with a delay on the dismiss button, but rarely; it would also make sense to delay a modal/dialog of some kind by a couple hundred milliseconds to give you time to react, particularly if tapping outside of it would dismiss it.
I find myself using Notification History on Android more and more often, but a lot of the time it's not even notifications, it's some in-app thing that's totally within the developer's control.
iOS does not!
You're not going to be able to do it. They're not on facebook, you can't just link to the video, you're going to hold the phone carefully but the bared fraction of their palm will register with the screen, or the page will refresh, or the screen (now 27 feet deep in the doomscroll) will scroll all the way to the top of the screen.
And you'll end every iMessage with a b. b
The one I don't quite know how to solve is when I'm tapping a device to connect to -- whether a WiFi router or an AirPlay speaker or whatever -- and I swear to god, half the time my intended device slides out from under me a newly discovered device enters above and pushes it down. Or sometimes devices disappear and pull it up. Maybe it's because I live in an apartment building with lots of devices.
I've seen this solved in prototypes by always adding new devices at the bottom, and graying out when one disappears, with a floating "resort" button so you can find what you're looking for alphabetically. But it's so clunky -- nobody wants a resort button. And you can't use a UX delay on every update or you'd never be able to tap anything at all for the first five seconds.
Maybe ensuring there's always 3 seconds of no changes, then gray out everything for 0.5 seconds while sliding in all new devices discovered from the past 3.5 seconds, then re-enabling? I've never seen anything like that attempted.
Just as I’m about to tap it, the other person ends the call and what I’m actually tapping is some other person on my call list that it then immediately calls. Even if I end the call quickly they often call back confused “You called, what did you want?”
Apple: PLEASE add a delay to touch input after the call screen closes.
It seems like a super easy fix.
(Honestly, I'm sort of with you on the medium thing, but I posted this years ago now...)
https://scribe.rip/@pmarreck/the-most-annoying-ui-problem-r3...
I consider UBO basically mandatory for browsing the web in 2025, too many sites are unusable and infuriating without it.
Deleted Comment
This also happens where sometimes the hotbar has three buttons, and sometimes four, and the worst apps are when buttons switch ordinal positions depending on if there are three or four buttons in there.
It feels very strange to get so agitated by these small behaviors, but here we are.
this has happened to me and i even clicked on the ad. It actually made me smile a little bit and reminded me of the "clever girl" scene in Jurassic Park.
> or worse, an ad has taken the place of the button
That's actually a dark pattern/perverse incentive I hint at towards the end of my blog post about it.
If an update is required, rather than just desired, freeze all input so the user knows it's about to update, this might be accompanied by a quick 'fade' or other color shift to indicate an update is about to be pushed and they should release and re-plan actions.
I was a console game developer working on UI for many years so I am deeply familiar with the problem when a UI should be responsive to input while the visuals are changing and when it should not.
You might be surprised, but it turns out that blocking input for a while until the UI settles down is not what you want.
Yes, in cases where the UI is transitioning to an unfamiliar state, the input has a good chance to be useless or incorrect and would be better dropped on the floor. It's annoying when you think you're going to click X but the UI changes to stick Y under your finger instead.
However, there are times where you're tapping on a familiar app whose flow you know intimately and you know exactly where Y is about to appear and you want to tap on it as fast as you can. In those cases, it is absolutely infuriating if the app simply ignores your input and forces you to tap again.
I've watched users use software that temporarily disables input like this and what you see is that they either get trained to learn the input delay and time their tap as tightly as possible, or they just get annoying and hammer inputs until it gets processed.
And, in practice, it turns out these latter times where a user is interacting with a familiar UI are 100x more common than when they misclick on an unfamiliar UI. So while the latter case is super annoying, it's a better experience in aggregate if the app is as responsive as it can be, as quickly as it can be.
Perhaps there is a third way where an app makes a distinction between flows to static context versus dynamically generated content and only puts an input block in for the latter, but I expect the line between "static" and "dynamic" is too fuzzy. People certainly learn to rely on familiar auto-complete suggestions.
UI is hard. A box of silicon to a great ape is not an easy connection to engineer.
I’m specifically thinking about phone notifications that slide in from the top – ie, from an app other than the one you’re using.
So we have two options: ignore taps on these notification banners for ~200ms after the slide-down (risking a ‘failed tap’) or don’t (risking a ‘mis-tap’).
I’d argue these are in different leagues of annoyingness, at least for notification banners, so their relative frequency difference is somewhat beside the point. A ‘failed tap’ is an annoying moment of friction - you have to wait and tap it again, which is jarring. Whereas a ‘mis-tap’ can sometimes force you to drop what you were doing and switch contexts - eg because you have now cleared the notification which would have served as a to-do, or because you’ve now marked someone’s message as read and risk appearing rude if you don’t reply immediately. Or sometimes even worse things than that.
So I would argue that even if it’s 100x less common, an mis-tap can be 1000x worse of an experience. (Take these numbers with a pinch of salt, obviously.)
Also, I’d argue a ‘failed tap’ in a power user workflow is not actually something that gets repeated that many times, as in those situations the user gets to learn (after a few jarring halts) to wait a beat before tapping.
All that said, this is all just theory, and if Apple actually implemented this for iOS notifications then it’s always possible I might change my view after trying it! In practice, I have added these post-rendering interactivity periods to UI elements myself a few times, and have found it always needs to be finely tuned to each case. UI is hard, as you say.
But when the system initiates it (eg. notifications, popups), then the prior interface remains active.
There's this paper studying this, and I think more work on it too.. https://dl.acm.org/doi/full/10.1145/3660338
I also considered the case when you're rapidly scrolling through a page- if a naive approach simply made things non-interactable if they've recently moved, that would neuter re-scrolling until the scrolling halted, which is NOT what people want
This is very true, but the app has to be explicitly designed around this e.g. by not injecting random UI elements that can affect the layout.
Unfortunately this seems to be regressing in modern app UX, and not just on mobile. For example, for a very long time, the taskbar in Windows was predictable in this sense because e.g. the Start button is always in the corner, followed by the apps that you've pinned always being in the same locations. And then Win11 comes and changes taskbar layout to be centered by default instead of left-adjusted - which means that, as new apps get launched and their icons added to taskbar, the existing icons shift around to keep the whole thing centered. Who thought this was a good idea? What metric are they using to measure how good their UX is?
> However, there are times where you're tapping on a familiar app whose flow you know intimately and you know exactly where Y is about to appear and you want to tap on it as fast as you can. In those cases, it is absolutely infuriating if the app simply ignores your input and forces you to tap again.
I agree with both of these, but I think that such a thing would work better with keyboard-oriented interfaces. However, when using a mouse or touch-screen, these are still good ideas anyways, although the situations where you will know and should expect what comes next is less when using the mouse, still it can be important because unexpected pop-ups etc from other programs, just as much as, when using the keyboard, pop-ups that take keyboard focus are as significant for this issue. Since this can sometimes involve multiple programs running on the same computer, that do not necessarily know each other, it cannot necessarily be solved from only the program itself. (I think that it will be another thing to consider in the UI of my operating system design.)
To the original author's point, the consternation arises when you as a programmer just know there is an animation time, or a delay time, etc. that is hardcoded into the app and you can't adjust the value. The lack of interface and inability to have that exposed to the user is at least one major frustration that could help OP.
I did find this though, and I think I will add it to my medium post: https://web.dev/articles/cls
Open a tool window, subsequent keystrokes should be sent to that too window, even if it takes a second to show. The "new/modern" interface on my CNC is both show and doesn't properly buffer input, and its hugely painful.
EDIT: I realize you specified touch, which isn't "desktop", but my CNC control is touch based and the same applies.
Yes, and this works best with keyboard-oriented interfaces (which I think is generally much better than touch screens anyways; a lot of software I write is designed for keyboard use because it has this and other benefits). However, it should only be done if the process of the UI is what is expected; if something unexpected occurs then it might be better to discard any pending input. (But, sometimes this "expected" and "unexpected" is not so clear.)
No. That’s not how humans interact with computers. It’s not how humans interact with each other either.
Turn based games can be fun. They are not how we want to interact for day to day life.
Sorry but your idea comes across as one that makes the job of making the computer good to interact with easier, but not as one that makes the computer better to interact with as a human.
Please stop over simplifying a complex system. Humans are complex, the solution is t to be less human. It is for computers to become better at human interaction on human levels.
Since you can't go back in-time, what I suggest to arrange for the event (if it occurs slightly after the redraw) to be applied using the old display model (instead of dropped). If the redraw occurs slightly after the event (and you're right) I'd prefer delaying the redraw instead of delaying the tap.
I think a interface shouldn't be even visible, if the elements will be jumping around until they are done validating and loading.
And should an interface be interactable for a few milliseconds longer, after it has disappeared?
In the latter case, you could quietly disable buttons after a layout shift, but this can cause problems when users attempt to interact with an onscreen element only to have it mysteriously ignore them. You could visually indicate the disabled state for a few hundred milliseconds, but this would appear as flicker. If you want to be very clever you could pass a tap/click to the click target that was at that location a few tens/hundreds of milliseconds prior, but now you've got to pick a cutoff based on average human response times which may be too much for some and tool little for others. That also wouldn't help with non-click interactions such as simply attempting to read content -- while not as severe, trying to read a label that suddenly moves can be almost as frustrating. Some products attempt to pause layout shifts that might impact an element that the user is about to interact with, but while this is possible with a mouse cursor to indicate intent it can be harder to predict on mobile.
Some of these ideas are even used in cases where a layout shift is necessary such as in a livestream with interactive elements. However, the general consensus is to use content placeholders for late-loading content and avoid rendering visible elements, especially interactive ones, until you have high confidence that they will not continue to move. That's why most browsers provide penalties for websites with "cumulative layout shift", e.g. see https://web.dev/articles/cls
Why do we even show interactable elements when the final layout isn't completed yet?
Deleted Comment
I have many ideas that I want to build, but I'd have to learn new languages, yet I just can't sit and go through the documentation every day like I should. Still haven't finished the rust book.
The other way is start building already, and if you come across a block, then learn about that thing and move on, but I feel uncomfortable having gaps in my knowledge, AI exists but I don't want to use it to generate code for me because I wanna enjoy the process of writing code rather than just reviewing code.
Basically I'm just stuck within the constraints I put for myself :(, I'm not sure why I wrote this here, probably just wanted to let it out..
I've written a lot of Rust. I've read less than half of the Rust book. Your competence in Rust is a function of how many lines of Rust you've written; getting to the point you can start working with it is more important than completing the book. Jon Gjengset's videos were really critical for me there, seeing how he worked in Rust made it possible for me to develop a workflow. (I broke down what I learned in more detail at one point [1].)
Rust is an example I've honed in on because you mentioned it and I related to it, but this is broadly applicable. Dare I say, more broadly than just programming, even.
(Also, note that I'm a giant hypocrite who shaves yaks and struggles with perfectionism constantly. I learned Rust 5 years ago to start a project, and I've written 0 lines of code for it. If I sound critical, that's my self criticism leaking through.)
[1] https://news.ycombinator.com/item?id=38020654
> I've written a lot of Rust. I've read less than half of the Rust book.
Just knowing that there's someone out there who has worked like this or has been in the same situation gives me enough confidence to go through it!(the just write code part)
I've gone through so many resources (including the book) and I never managed to finish any of them. But I think now I need to get comfortable with having gaps and just start writing code and not be afraid of writing non-idiomatic rust code, atleast for now.
I like this a lot. I told someone once I avoid documentation like the plague and it just didn't have the same poetic ring as this line.
Sometimes you need to dive in, other times you need to hobble together something to step over
But as you get older you want to shift from exploration to exploitation. It is hard to make progress on anything, both professionally and personally, if it first comes with another couple of person-weeks of learning something new, let alone person-months. Even though I find learning new things easier than ever because of the breadth of things I have covered, I find myself having to be ever more skeptical of what I will invest in in that way, because unlike a fresh developer with no skills who has little better to do than learn their toolset, I have skills that can be exploited to good effect. As a mature developer, I need to trade off not so much "what might this be useful for in the future versus the effort of learning now" but "what could I be doing right now with the skills I have rather than learning something new".
Particularly when the "something new" is a variant of a skill I've already picked up. It'd be great if I never again had to learn a devops deployment system. I've already had to learn three. Unfortunately I doubt I'm going to get away with that. It'd be great if I didn't have to learn another scripting language to do something, but I doubt I'll get away with that either. Your mileage will absolutely vary but it'll be something.
I know there's a memeset of the "old fogey who doesn't want to learn", but I really do see the learning costs now as the opportunity cost of using that time to exploit the ones I already have, rather than just grumbling about learning in general. At the moment the things I can't escape even if I try have been plenty to keep my learning skills well-honed.
So bear in mind that as you round out your skills, as you cover "scripting" and "static language" and "database" and "HTML" and "devops deploy" and "shell scripting" and "functional programming" and all the other categories you may pick up over time, it is natural and desirable to pivot to exploitation being more of your time than learning.
After all... what is all this learning for, if not to exploit the skills to do something, not just learn the next skill, then the next, then the next?
The discomfort of having gaps in your knowledge is not a flaw. It’s a sign of integrity. But perfectionism disguised as discipline can become a cage. You’re not stuck because you lack ability — you’re stuck because you’ve built a narrow path and called it the only way forward.
There is another way: give yourself permission. To build messy. To learn sideways. To follow joy, not obligation. To trust that your curiosity is enough.
You wrote this here because something in you is ready to shift. You’re not asking for advice. You’re asking to be seen. And you are.
I don't understand why so many people suddenly started to insist on taking this all away, and they totally seriously proposed to become a janitor of a hallucinated output of some overhyped tool. That's the most frustrating thing one can imagine about programming, yet people insist on it.
Deleted Comment
Understanding why I feel this, when I have, has always proven enlightening. I find it never has to do with the gap or what would fill it.
There is two things I validated from reading Barbara Oakley and Kató Lomb is that a) it's okay to be a slow learner b) it's okay to learn differently.
Just do your thing.
This happened to me when I was going through a similar transition as the OP is highlighting. At first, creating software was difficult and novel. Then after getting over that first learning hump, I spent a pretty long time feeling drunk on the power of being able to get computers to do exactly what I want. But familiarity breeds contempt, and eventually it felt more like "this is it?" and the pure act of creation for creation's sake lost a lot of its appeal.
I think this is a pretty common transition! For me, the path out of the doldrums is two fold: 1. I have a lot more going on in my life now that has nothing to do with computing (mostly family, but also other interests), and 2. I'm a lot more focused on what I'm creating and why it's useful than in the act of creation itself.
This almost certainly not what you want to hear, but this is why the quickly developing gen AI tools are increasingly exciting to me. I believe they open up the world of what can be created within a given time constraint. They also definitely (at least for me) make the act of creation itself less enjoyable, and I lament that. I'll probably always feel nostalgia for how I felt about the craft of programming a decade or two ago. But my perspective has just shifted from the "how" to the "what".
I heard someone say "epistemic humility" the other day to mean fallibilism [0] and the conversation got interesting when we moved on to the subject of "what one can and should reasonably claim to know". For example: should cops know the law?
Not every programmer needs to be a computer science PhD with deep knowledge about obscure data-structures... but when you encounter them it's a decision whether to find out more.
Integrity is discomfort with "hand-waving and magical" explanations of things that we gloss over. Sure, it's sometimes expedient to just accept face-value and get the job done. Other times it's kinda psychologically impossible to move forward without satisfying that need to know more.
Frighteningly, the world/society puts ever more pressure on us to just nod along to get along, and to accept magic. This is where so much goes wrong with correctness and security imho.
[0] https://iep.utm.edu/fallibil/
Why? Why, specifically, do you "have to learn new languages"?
So, sure, I can see that, for some product, you might need to learn a new tech (say ... some specific AWS/GCP/Azure service), or perhaps a new configuration language (YAML, TOML, whatever).
And, sure, for some ideas (for example a mobile phone app) you're forced into that specific ecosystem.
Other than the mobile exception above, why do you need to learn a new language to build your idea? There is nothing stopping you from implementing your idea in (for example) Python. Or Javascript. Or Java, C#, C++, etc.
A programming-language-barrier absolutely does not stop you building your idea.
You gotta make the call - are you interested in building $IDEA, or are you interested in learning $NEWLANG?
Except there is, my brain :), that's one of the constraints I'm talking about, I'm a frontend web dev and I only know JS/TS, and like some frontend web devs, I'm enamored by Rust because it seems so different. I already use JS/TS at work so I want to use something else for my personal projects. So I definitely would have to learn something new.
> You gotta make the call - are you interested in building $IDEA, or are you interested in learning $NEWLANG?
If I was only interested in building my idea, I'd have just used what I know and used AI to accelerate the process. However for me the journey is also important, I want to enjoy thinking and writing code (and this project is something only I'd use, so there's no hurry to release a prototype). The problem is I want to start writing code right away, but that has the issue that I've mentioned above (gaps in knowledge).
Nobody is at fault, other than me for setting these constraints for myself. I know the solution is to just suck up and go through the rust book, read a chapter daily and eventually I'd have all the concepts in my head that I can then just focus on writing the code. But whenever I go about doing this, my mind always persuades me that there must be a better way, or it finds some flaws in my current approach and so on. So I need to learn how to not listen to my mind in such cases, and stick to the goal that I set.
Edit - After reading a reply to my comment, I've decided to just start writing the code and not worry about having gaps, anytime I start having doubts again, I'd go through this comment thread
I've been there for a decade or more. It is part of my recent burn-out…
The trick is to prioritise and not care too much about too many things, to avoid the choice paralysis in choosing what to do next. Unfortunately I've not mastered that trick yet, or even come close. In fact I'm increasingly of the opinion that dropping tech projects completely, accepting that is no longer a hobby and no longer something that will ever bring me joy again in future, is the prioritisation I need to perform, so I can instead have more mental capacity for other hobbies (and, of course, commitments in life).
You are far from alone in this trap!
Once I was okay with maybe doing things wrong and just hacking things together, it really unlocked my productivity. In my case, my perfectionism ended up being an excuse to procrastinate and avoid the pain of failure, but once I was okay with failure, everything else got easier. Even if I don't know how to do something, I'm more confident that I can plow ahead and figure out how to handle unknowns later.
Momentum is a big thing as well. Once you start having bits and pieces of your idea working, you'll quickly find a way to overcome knowledge gaps because you are hugely incentivized to see more of your vision become a reality. If you don't have anything working yet, it's much harder to motivate yourself to just read up on how some tech works because it doesn't necessarily translate to something immediately working.
That’s not a bad thing - just find out which part you actually want to do
In my case, being good at programming was my means to feeling valued and valuable, and the sense of "I should" came from feeling useless and not needed, specifically after being forced into early retirement. (but the same pattern has been with me since childhood)
Not having a family or passion project (which fills those gaps for many people as far as I can tell) made all of this feel very urgent and threatening.
> which part you actually want to do
Which sounds like such a simple question, but I found it hard to answer. For me, it quickly turns into "what is worth doing", which is a bit of a monstrous question. I'm still trying to figure out whether this is a result of being mostly estranged from myself and the question of "what do I want" due to being so overwhelmed with trying to succeed with the external constraints and demands the world places on us.
For me, it’s brought back the joy of coding and building things: I feel like I was in a rut for years before that
Also, finding people to share the stuff with helps a lot too. Even if they are personal projects, it’s nice having others to show it to, appreciate it and give feedback
Even if you need to really shoehorn a component of the system in, just make a note about it and keep building. When you're done, you can go back and focus on replacing that one piece.
My view is that you learn a lot through the process of building this way.
In my experience the best way to learn is by doing; that “uncomfortable having gaps” is there for most folks to some degree. That mild discomfort is a good indicator that you are in the growth zone, maybe you can shift your perspective to perceive it as a positive signal.
AI is also great to ask questions and accelerate the process of learning a new language, but if you’re doing this for the craft then you are free to choose the constraints and rules that make it fun.
Say, you have to use a new IDE and don't know how to use it, ask the LLM the steps to perform whether action your want to take.
The worst you can do is nothing at all.
With AI there's nothing to be ashamed of as it is "what you can dream of, you can get today". There's not much left in programming in most of the projects (that are just repeated code, output, what not over and over) after AI , tools are just too powerful today.
- Build a local storage web app that can track my responses to the Sino-Nasal Outcome Test over time to journal my ongoing issues with chronic sinusitis.
- Build a web app that grabs Northern Colorado houses for sale, presents them on a map, and lets you search and browse them, with everything being cached for use offline in local storage. The existing site, coloproperty.com, has severe issues if you are out looking at houses and have spotty Internet connectivity, it's effectively useless.
I've been developing software for 40 years, but I'm not really a frontend guy. The first one Claude Code was able to basically one-shot, and then I asked for 3-4 refinements. The second one took me probably 40 back-and-forths to get going, but eventually was a fully working prototype using Codex.
It's the difference between using hand saws and chisels and planes, and using power tools. Hand tool woodworking is an amazing craft, but the right power tools can let you build nice things quickly.
I grew up in a datacenter. Leaky air conditioners and diesel generators. Open the big doors if it gets too hot.
Everything, everywhere, is greasy and lousy and half broken. Sysadmins, we accept that everything is shit from the very beginning.Then you see the real world and you think it must be because people are stupid, the bosses are pointy-haired, they don't understand, they don't value elegance, they are greedy, they etc. etc. But once you spend enough time on your own projects, and they evolve and change over the years, they turn more and more into a mess, you rewrite, you prioritize, you abandon, you revive, and you notice that it goes much deeper than simply laziness. Real solutions depend on context, one caching algo is good when one medium is x times faster than another, but not when it's only y times faster. It makes sense to show a progress bar when downloading a file if the usual internet speed is X but not when it's Y. Over years and decades the context can shift, and even those things can change that were only silent assumptions of yours when you made the "perfect" program as a young'un, looking down on all the existing "messy" solutions that do a bunch of unnecessary cruft. It's an endless cycle...
I don't really agree with this. Yes, it gets outdated quickly and breaks often if you build it in such a way that it relies on many external services.
Stuff like relying on "number-is-odd" NPM package instead of copy-pasting the code or implementing it yourself. The more dependencies you have, the more likely it will break.
If your software works locally, without requiring an internet connection, it will work almost forever.
Now, if you want to keep developing the software and build it over a long period, the secret is to always keep all dependencies up-to-date. Is there a ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.
There are certainly horizontal slices of every stack that can be written to remain stable regardless of the direction the business takes, but those are rarely the revenue drivers that the business cares about beyond how much they have the potential to cause instability.
So - your HelloWorld written 10 years ago suddenly stopped working after CPU you run it on got too fast.
> ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.
Is, to me, almost the same sentence as
> Every solution you write starts to rot the moment it exists
This doesn't mean we shouldn't try to make it as good as we can, but rather that we must accept that the outcome will be flawed and that, despite our best intentions, it will show its sharp edges the next time we come to work on it.
Kublai Khan does not necessarily believe everything Marco Polo says when he describes the cities visited on his expeditions, but the emperor of the Tartars does continue listening to the young Venetian with greater attention and curiosity than he shows any other messenger or explorer of his. In the lives of emperors there is a moment which follows pride in the boundless extension of the territories we have conquered, and the melancholy and relief of knowing we shall soon give up any thought of knowing and understanding them. There is a sense of emptiness that comes over us at evening, with the odor of the elephants after the rain and the sandalwood ashes growing cold in the braziers, a dizziness that makes rivers and mountains tremble on the fallow curves of lhe planispheres where they are portrayed, and rolls up, one after the other, the despatches announcing to us the collapse of the last enemy troops, from defeat to defeat, and flakes the wax of the seals of obscure kings who beseech our armies' protection, offering in exchange annual tributes of precious metals, tanned hides, and tortoise shell. It is the desperate moment when we discover that this empire, which had seemed to us the sum of all wonders, is an endless, formless ruin, that corruption's gangrene has spread too far to be healed by our scepter, that the triumph over enemy sovereigns has made us the heirs of their long undoing. Only in Marco Polo's accounts was Kublai Khan able to discern, through the walls and towers destined to crumble, the tracery of a pattern so subtle it could escape the termites' gnawing.
However, like every other solution built by Nature, this one also works through pain, suffering and death. Nature doesn't care if you're happy, nor does it care if you're suffering. And it especially doesn't care if your suffering is a low-burn, long-term pain in the depth of your heart.
So yeah, having kids will force you to make choices and abandon frivolities, in the same way setting your house on fire will free you from obsessing over choices for unnecessary expenses :).
My free time is to be spent on other things, I get paid to fix issues and that pays my bills, I don't want nor need to be thinking about these issues outside of paid hours, you know too much to the point where you know how much effort it will take to fix something that might look innocuous, innocent, but definitely has deep tendrils of other related issues to tackle. It's not worth it, not if I'm not being paid for it or it isn't part of a personal project I'm really passionate about.
So I learnt to not care much, I help my colleagues, deliver what I tell I will deliver, and free space in my mind to pursue other more interesting stuff to me.
This can actually make things (much) worse:
Since you have now another topic you are insanely passionate about, you see a lot of additional things in the world that are broken and need fixing (though of course typically not via programming).
Thus, while having a very different additionally hobby (not or barely involving programming) clearly broadens your horizon a lot, it also very likely doubles the curse/pain/problem that the original article discusses.
But then I look at my son, and say "screw it, they couldnt pay me enough to care out of hours and give up play time"
I, for example, would perhaps not be a bad parent, but very likely at least one who does not obey the social expectations of how to raise a child.
The script I made for deployment, because existing solutions didn't "feel" right, required a lot of work and maintenance when we later had to add features and bug fixes.
Another script I made for building and deploying Java applications, because I didn't like Maven and Puppet.
The micro service I rewrote because I wanted to use my own favourite programming language. I introduced a lot of bugs that were already fixed, missing features and another language for my co-workers to learn when they inherited the application when I left.
I also think there is a profoundly non-linear relationship (I don't want to say negative-exponential, but it could be), between:
- The number of lines of code, or distinct configuration changes, you make to the defaults of an off-the-shelf tool
- The cognitive and practical load maintaining that personalized setup
I'm convinced that the opportunity cost of not using default configurations is significantly higher than we estimate, especially when that environment has to be shared across multiple people.
(It's unavoidable or even desirable in many cases of course, but so often we just reinvent hexagonal wheels.)
Using standardized software often leads to spending half a day just trying to find a way to work around the limitation you face. The next level there is that you realize you can just fix it, spend half a day crafting the perfect PR, and then submit it into the void, leaving it hanging for half a year before someone gets to it.
It is a rare and wise insight which only becomes crystal clear with age. Choose your battles very carefully.
This is a golden nugget up there with "time flies". I never understood that as a kid but really hits hard with your mid-life crisis.
Listen carefully little grasshoppers.
Deleted Comment
What I always find comedic, is that the rate I can do work is rarely gated by how fast I can interface with a computer. Even if I had a perfect brain/computer interface I think my productivity would maybe increase by 5-10%.
What is a real force multiplier is working on the RIGHT THING, not tweaking your vimrc config for the 50th time or creating your own build system because you are tired of Makefiles.
I use this really annoying, poorly supported terraform provider. I've written a wrapper around it to make it "work" but it has annoyances I know I can go to that repository and try to submit a patch for it to fix my annoyance. But why? This is "good enough," and IME, if you sit on things like this long enough, eventually someone else comes along and does it. Is that a good attitude for everyone to have? Probably not, but now it's been a few years of using this wrapper module, I have 2-3 viable alternatives now that didn't exist before that I can switch to if needed.
I could've turned it into a several week project if I wanted, but why? What purpose does it serve? As you grow, you realize there is very rarely, if ever, a "right" answer to a problem. Consider the way you think it should be done is not the only "right" way and you'll open more doors for yourself.
> They'll spin their wheels solving some insane problem no one asked them to do because it's "better" while ignoring the larger scope and goals of the project.
> But why? This is "good enough," and IME, if you sit on things like this long enough, eventually someone else comes along and does it.
Can't think of a bigger reason to avoid volunteer work on free and open source software than what you just said. Being a "wheel spinner" who cares too much about stuff is foolishness. People hate you and simultaneously take you for granted.
> Consider the way you think it should be done is not the only "right" way and you'll open more doors for yourself.
Absolutely.
To not be annoyed? How is that not a worthy goal in itself?
Things that I’ve learned (through much difficulty) for myself that feel relevant:
* Boundaries: not all problems are mine to fix. It’s okay to say no, even if someone else doesn’t like it.
* Acceptance: perfection is an illusion, there will always be an endless list of problems to work on, human time and energy have real limits, I am allowed to have different desires and motivations today versus yesterday (or an hour ago!)
*Emotional maturity: humans are emotional beings, it’s okay to get annoyed / upset at something, including particular issues with software. The root cause of an emotion often becomes clear much later than after the initial trigger, which usually is only slightly connected to the deeper issue.
*Wisdom / self-love: it’s ok to rest. It’s okay to not finish a project. It’s okay to say no. Human lives are immensely complicated, we will always make mistakes, and change happens always. Words like need and should are are directives springing from the shifting, hidden narratives we have imbued our lives with. We can understand and reshape these narratives.
If I had more time I would have a written a neater, more concise, and more complete list :)