it’s so hard to sell someone on the concept of “what you’re doing is unnecessarily hard, but if you put in a lot of effort to wrap your head around this counterintuitive thing, then you can do it way more easily instead”

I’m specifically thinking about stuff like ECS, Vim/Emacs/Neovim, containerization, immutability in general, and functional programming

because like, the argument format that I usually see is:

1. okay so the way that you would normally do XYZ is hard right?
2. but if you just [describes a very counterintuitive solution] then it would be really easy instead

because first of all, if you say “the way that you normally do XYZ is hard” the first thing someone is going to think is “… I guess? but it’s just an inherently tricky problem. I could definitely solve it though, and I already have a high-level idea of how I would do that”. to them the problem is inherently tricky because - in their mental framework for solving this category of problems - it is

and when you follow up with “but actually you could do this much simpler thing instead” their response is going to be “that sounds sideways and backwards, almost to the point of being academic. if it’s so hard for me to even understand what your solution is then why would it be simpler?”

and like, how do you even bridge that gap without coming off like “trust me bro. my way is better. put in a bunch of work without understanding why and you’ll eventually agree with me”?

and also, if you’re in the position of the person being convinced, how do you distinguish between a genuinely useful problem-solving technique and a tech fad? like, is NixOS actually a useful operating system or is it an excuse to tinker with a cool functional language? is Vim actually a superior way to edit text or is it a mind-bending exercise in memorizing arcane keybinds and configuring plugins for no tangible benefit?

you can’t just try every counterintuitive new thing in the hope that it turns out to be a good idea, but you also can’t stagnate and refuse to learn new things because they all seem counterintuitive to you

@kasdeya im of the school of thought that much of this is at the intersection of domain-specific needs and personal preference. it’s really difficult to explain this because, in order to explain it, one must recreate the original problem in its entirety and then layout the history of all the other things we’ve done to get to [current solution]. not to mention, we all think about problems differently – one approach may seem exceedingly simple to one individual and needlessly complex to another (looking at you, functional programming). this isn’t even including familiarity because of course, once you learn a toolset, you then begin to expand your understanding of all the ways a tool may be applied. within your chosen toolset, it may seem elegant and simple to solve it with X when the rest of the world is using Y. is X better than Y? maybe, but probably not. it’s more likely because Y isn’t in your typical toolset for some reason so reaching for it feels unnatural.

@kasdeya using ecs as an example: it’s found a home in game development because it solves a non-trivial amount of game dev specific problems.

some common problems in game dev

• game objects can be expensive to create / destroy but games often require this very frequently
  • in non-ecs development, this is often solved with object pools – a collection of objects which are pulled from the pool, manipulated for whatever use its needed for, and then released back to the pool
• many game objects are variations of one another with just a few changes but many standard object-oriented patterns (inheritance) become fragile when applied and force a lot of redundant code
  • there are object-oriented patterns which are similar to ECS like what godot and unity do
• much of a game’s code runs 60+ times per second. it needs to be fast and organized such that only code which needs to run that often actually does, and it should be as done as cheaply as possible

enter ecs: component-based development allows for extremely modular design, data-oriented programming is focused on highly performant code, and entities being simple identifiers means that creating/destroying them is very cheap.

however, explaining this to say – a web dev, they may only understand this at a conceptual level if they’ve had little or no exposure to making applications like this. they may look at whats required to write ECS code and think to themselves, “couldnt we just solve this with observables / events / whatever other pattern we use frequently?” thats because these are the tools in their daily toolset and its how they solve their problems elegantly. they are very proficient with using these tools and will reach for them first.

to be clear: that web dev is not stupid. it is not a statement to their proficiency as a developer or anything else. its just that programming and computer science is both vast in breadth ( ) and depth and we have to specialize.

@kasdeya I'm biased because I enjoy learning new ways to do things in the event any of the new things is actually better than what I'm currently doing, so I'm already poised to experiment and put in the effort to try. Having said that, I agree that it's difficult to explain to others why, but you just have to put in the work sometimes

@rowan @kasdeya also just a final thought: we've noticed that the folks who picked up a technology *because* of that core use-case . . . they tend to be more likely to be the apologists who will sing its praises until the end of time

because it actually solved a genuine problem for them! it made their life better, and they want to share that! but it seems to us like they kind of forget that it was most worth the investment to learn *in that one area*, and everything else is a bonus

and it's when they start transferring that "it will change your life" claim into the other use cases that we start to run into kind of . . . well the frankly ridiculous takes about technology

(like the claims of "every developer should be doing their local dev environment in docker" or "react native is going to replace java and objective-c/swift" or "language specific package managers are dead, nix will replace them all" or like . . . basically all of the emacs / neovim plugin worlds. it's easy to not realize how long it took to build their familiary, and they misjudge the cost in time that it will take folks to get that specific benefit out of the tool)

@tempest @kasdeya i feel the point of familiarity and preference is underappreciated in general and i like this post values it. individuals “misuse” irl tools all the time because of convenience and familiarity and because they dont want to have 29384293429 highly specific tools to decide between. if they have something that works what for what they do, why change? only when that tool isn’t doing the job or new requirements have surfaced should they really consider whether they need something new. there are obviously cases where this isn’t true (eg. the use of the tool is harmful to themselves or others) but outside of those… why evangelize to them?

@tempest @kasdeya i know this post sounds like some crusty php developer cope but honestly, i’ll take phpbb over nodebb anyday i’m not gonna maintain it or write code for it, but damn if its not an Okay piece of software