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…
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 w…
The curse of knowing how, or; fixing everything
301–310 of 458 posts
Re: The curse of knowing how, or; fixing everything
#302Fractal complexity. It's not only that solutions decay, though that's true, but also that the search for improvement itself becomes recursive. When you identify something can be improved, and fix it, your own fix and every individual step of it now become the new thing that can be improved. After the most fleeting of pauses to step back and appreciate your work, this becomes your new default. Indeed I often look back…
"Just build the product" this was a good read, and a trap I get sucked into. Always focusing on amassing ever better tools, and forgetting that the practice of using those tools is what really matters.
Re: The curse of knowing how, or; fixing everything
#303Earlier quoted context omitted.
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.
Yes, if you change hardware, the software can break (a lot less often now than before though, as hardware changes are a negligible and they usually think about backwards compatibility).
Someone is not familiar with iOS/macOS/Android, where stuff breaks every. effing. year. Windows is the exception, nowadays.
Re: The curse of knowing how, or; fixing everything
#304I don't feel the "moral weight" the author mentions. For one, there are many, many directions you could take at any given moment, but you have to choose only one. You have no choice but to triage. That's not a moral failing, just the nature of agency and existence. I do have some perfectionistic tendencies, which might be behind some of this. But a long time ago I graduated to a deeper perfectionism... The problem wi…
This is why so many open-source maintainers burn out: they create something that people find useful and suddenly, almost inadvertently, incur the obligation to keep users happy. That is both the best part and worse part of creating software.
Re: The curse of knowing how, or; fixing everything
#305Oh wow. This hits hard in the feels. 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…
> 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…
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.
Re: The curse of knowing how, or; fixing everything
#306Earlier quoted context omitted.
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,…
Thank you for your comment, especially for this > 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…
i was in the same boat. i’d probably gone through the first half of the rust book and made actual hand written notes several times over the last 5 years. started rustlings. started “100 exercises in rust” (can’t remember actual title). never finished them. never felt like i was going to be “ready” to handle rust.
6-9 months ago i had the time to start learning a new language. was between rust or go. decided on rust. avoided it for a month. recently released my first library crate (with another on the way).
my tips/experience
- don’t worry about the borrow checker to start, just be aware it’s a thing. clone() everything if you need to. i had to just get comfortable writing rust code first. “i wrote some rust” was the goal each day. just working on getting it to compile somehow was all that mattered. confidence building is a thing.
- i started with simple CLI binary doing stuff like “package the files in these directories as a release/dev build setup”. basically copy paste /symlink files with clap. simple but useful [0]
- start with an ide that hooks into the compiler and shows you errors. ideally one like theia or rust rover which shows you the documentation of the error when you hover over it. i’ve now switched to nano and compiling manually after like 7 months. i see fewer errors these days and usually i expect some of them.
- keep it simple. don’t worry about being idiomatic. it will come as you read other people’s libraries and code over time. i’m still not there yet.
- if you are really struggling with the compiler just wont let me do this one bloody thing why won’t you let me do it it’s so simple in language X —> you are either fighting against the type system or the borrow checker. pause. take a moment. figure out which. it’s time to figure out what you’re not understanding. accept that you might have to completely change the approach of what you were doing. it’s okay, it’s part of learning.
- i would read all the outputs of `cargo clippy` and change each one by hand. i don’t use `cargo clippy —fix` ever. repetition helps me learn. doing enough boring repetition forced me to remember basic stuff that makes my code more idiomatic. i cannot emphasise how useful this was to make my code more idiomatic up front.
- commit your changes. then use `cargo fmt` and read through the diffs. again, helps to work out what rust code is supposed to look like while writing it (eventually without needing to use `cargo fmt`). i cheated with formatting compared to clippy (see above). it’s just formatting, you can probably rely on cargo fmt and be lazy tbh.
- you don’t have to start your rust journey with hardcore systems/hardware level coding. i felt like i was cheating / doing it wrong because i wasn’t doing that. but a lot of crates are nothing to do with systems level stuff. just because it’s a systems programming language doesn’t mean you have to be that hardcore to start with. see 2nd bullet point.
- generics might be my favourite thing about rust. realising how they work and how to apply them blew my mind. once i had that ‘mind blown’ moment with something — i was hooked. i don’t wanna go back to python now!
[0]: i need to change perms. apparently i set code viewing to private somehow? wtff. https://gitlab.com/dijksterhuis-arma3/vn-mf-builder
Re: The curse of knowing how, or; fixing everything
#307Re: The curse of knowing how, or; fixing everything
#308Earlier quoted context omitted.
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.
Your browser should be set to open all pages in reader mode.
about:reader?url=https;//www.example.com
But seems that doesn't work anymore.Re: The curse of knowing how, or; fixing everything
#309Re: The curse of knowing how, or; fixing everything
#310Oh wow. This hits hard in the feels. 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…
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.
https://scribe.rip/@pmarreck/the-most-annoying-ui-problem-r3...