This really resonated with me. After reading, I thought "This person is likely from the same generation I am". I started programming in 1987. According to their About page, they've been programming since 2018. I wonder how they can feel that burned out after such a (relatively) short time?!
The curse of knowing how, or; fixing everything
361–370 of 458 posts
Re: The curse of knowing how, or; fixing everything
#362There'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…
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.
Re: The curse of knowing how, or; fixing everything
#363Earlier quoted context omitted.
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…
> 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’). Yeah, notifications are an interesting corner case where by their nature you can probably assume a user isn't anticipating one and it might be worth ignoring input for a bit. > Also, I’d argue a ‘failed tap’ in a power user workflow is not actually something that…
I don't view notifications as a corner case. I think two factors are key:
1. Can the user predict the UI change? This is close to the static vs dynamic idea, but doesn't matter if the UI changes. If the user can learn to predict how the UI changes, processing the tap makes more sense. This allows (power) users to be fast. You usually don't know that a notification is about to be displayed, so this doesn't apply.
2. Is the action reversible? If a checkbox appears, undoing the misclick is trivial. Dismissing a potentially important notification with no history, deleting a file etc. should maybe block interactions for a moment to force the user to reconsider.
Often even better is to offer undo (if possible). It allows to fast track the happy path while you can still recover from errors.
Re: The curse of knowing how, or; fixing everything
#364> Software doesn’t stay solved. Every solution you write starts to rot the moment it exists. Not now, not later, but eventually. Libraries deprecate. APIs change. Performance regressions creep in. Your once-perfect tool breaks silently because libfoo.so is now libfoo.so.2.
Since I started using Nix flakes to build everything and pin to specific versions this largely stopped being a problem for me. I happily run things I last touched many, many years ago without worrying about stupid stuff like this ^
> Burnout does not just come from overwork. It comes from overresponsibility.
I remain unconvinced by this, and the more years I rack up, the more I recognize the pattern of burnout having a direct relationship to alienation of labor.
Re: The curse of knowing how, or; fixing everything
#365this could be dunning-kruger in action
Re: The curse of knowing how, or; fixing everything
#366The corollary, ignorance/management is bliss.
Re: The curse of knowing how, or; fixing everything
#367There'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…
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"
Re: The curse of knowing how, or; fixing everything
#368Every piece of software becomes a TODO list.
The classic form of this is people hacking EMACS.
The other side of the problem is when you're building on a base that's broken and needs more maintenance than it is getting. Much open source is like that. With too few eyes, all bugs are deep.
Re: The curse of knowing how, or; fixing everything
#369This 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…
> 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. > 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 so…
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.
Re: The curse of knowing how, or; fixing everything
#370Hopefully 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 abou…
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.