Undeveloping Conviction
When you come to a new idea, if you’re lucky, you’ll have a new perspective - well, at least somewhat new, since you bring your own personal history and biases to anything you do. But in the first moments of dealing with something, you haven’t invested much in the problem or solution yet, and you have a lot of freedom to try new things. This is as much true for near-term engineering problems as it is for larger life problems like career, relationship, living arrangements (city/town/etc) and job. It’s why lots of innovation comes from people who are new to the domain - either new in age (young), or new in expertise (beginner’s mind).
No matter what the situation though, you quickly settle into some kind of strategy - that’s the nature of solving long term, hard problems or making accommodations in life - you have to make some choices along the way. So you begin to accumulate something like “sunk costs” - the energy (and time, which is another form of cost) invested in the current solution only go up. This increases your inertia - which is great if the solution works.
But sometimes, the solution is a dead-end or a local-maxima. It might be that you are somewhat happy at your job, but not growing. It might be that the solution to the engineering problem works, but is buggy and hard to stabilize. At that point the choices seem stark: keep going and hope for the best, or give up and start over. Most people frame these kinds of problems this way, and usually choose the first path, especially as they get more invested in time or effort.
But there’s an intermediate path that’s akin to a programming technique called “simulated annealing”. The key to this is to find a way to relax some of the constraints of the situation - it can be as explicit as actual technical requirements being loosened, but often it’s a more subtle relaxation of what is constraining your conviction about the solution. In short: doubt, a little, from time to time, as a way of letting yourself wander around the landscape and get off the hill.
What does this mean in practice? Maybe it means taking up hobbies or travelling to other cities to see if you like them better than the job or city your in. In an engineering problem, it can mean temporarily trying one of the earlier solutions that was discarded, or building something “outside of the design” you’re working on to see if it’s more effective. Or just spending a bit of time poking at the problem from a completely different direction as a “break” from the “real work”. Many ultimate solutions are hybrid like this in nature actually - the engineering team started with something that was overly simple or constrained but eventually iterated to something that worked.
Just to pick an example, the early history of mobile UX feels like that to me - they started with the (implicit, because no one had a better model) constraint of “replicate the desktop” but the best expression of that still didn’t really work, so they relaxed a little bit and worked on something that was more like “make it familiar to desktop users”. So we still have things like distinct applications, with icons, and there’s still a way to text, but scrollbars have been replaced by pinch-and-zoom, the apps are simpler and more graphically oriented, and you can’t quite (and don’t need to) organize the device and manage it the way you do a desktop (though you can get closer with Android).
In that case, “desktop but on a phone” was a local maxima that didn’t actually solve the problem. “Something desktop-ish but tuned for the device” was an adjacent hill that needed a bit of wandering to get to.
Technical Documentation Pro -- Retired
2 年Are you wandering Kaufman's fitness landscapes here?