This post is not about perfection, but rather about a deep, legitimate frustration that the tech community spends so little time really understanding the problems it sets out to solve.
Here's a key paragraph:
> I am not solution-oriented. I don’t see a problem and get giddy at the idea of solving it, patching it up and sending it on its merry way. I want to poke it and ask it questions. Where did it come from, what is it doing, what’s its story? I want to take it to tea and hear about its life and understand it to its core. And if, at that point, I’ve come to a wholistic understanding and am able to solve the problem, by all means, let the problem-solving commence! But my instinct is never to solve, but to understand.
This is not a statement of perfectionism, but rather a deep yearning for like-minded people who believe in trying to understand the problems they're trying to solve.
The RFC process, which has gained more prominence through projects like Ember, Rust, Swift, and Yarn, operate on the same principle: that we should try to make sure we understand, not just rush in with the first solution that comes to mind.
Iteration and contact with reality are important. A desire to understand is not in conflict with a desire to iterate and work with communities. But too often, the tech community makes a virtue out of moving fast, breaking things, and never coming to a deep understanding even in many of the most successful cases.
I think we owe it to ourselves and our community to get past a knee-jerk reaction to this post.
I guarantee most people who work in product or software are far more interested in hearing problems than half baked solutions. It’s actually quite frustrating when someone gives me their solution and I have to reverse engineer the actual issue.
Sounds like a common case of loving the idea of something but not having the will to carry it out. That's most of humanity in my experience. People, even experienced tech professionals are far more likely to bitch about a problem vs actually taking steps to solve it.
It's like people who will bitch about how lousy customer service is at company X, but if company X raised the prices on their products by $1-2 to hire full time customer support staff, those same people would take their business elsewhere. So really they don't want better customer support, they just want the genie to grant wishes.
3 out of 50 people actually serious about solving a given problem fits pretty well with my life experience. :P
"Just trying to "quick fix" apparent bugs, without having understood the complex problem in its entirety beforehand, is a pretty bad approach in quite some areas of the tech world."
And a million sysadmins across the world cried aloud in agreement and despair.
The point is that I think there are business side problems more than there are tech problems in this industry as a whole. I think the phrase "the perfect is the enemy of the good" is a dangerous one for so many managers to latch onto. More on point to the article though, we need more magnum opuses, more results of this kind of long term thinking, put into action. Not more band-aids on problems.
I do think though, that big picture thinkers of this ilk do find themselves trapped into a twist on the Bertrand Russell saying, "The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt."
What we need then, are some of the intelligent to gain a bit of the cocksuredness, and the stupid to gain a bit of doubt.
Having something "solved" does not mean there is no space left for different approaches or sheer competition.
And seeing people putting effort into something and delivering software is at least one indicator that the original problem is not solved in the eyes of some...
I like to put it this way: look for solutions, not problems. Many programmers spend their effort on figuring out why something can't work, rather than how it could work.
Very much so. This problem only gets bigger as people get more technically sophisticated. Most people are satisficers (when the first idea pops up that could even remotely fix the problem they stop thinking about more solutions) and they tend to force that on others as well. It's rare for people to be able step back and state their problem in a pure form, instead people like to state their problem in the form of an unimplemented solution (thinking that makes it easier).
Developers who aren't skilled in recognizing or dealing with this sort of thing are at a significant disadvantage. If you naively implement all of the random satisficed solutions people submit to you as "problems" you end up with an incoherent and conflicting mess.
you keep repeating this mantra, but this is exactly what Op is asking... what problem is it really solving. Its not solving a tech problem, because the tech exists.
Well, I agree it's the more overt problem. But having spent some time in the adult world myself, I find that the larger problem is partial solutions piled on partial solutions, burying users in piles of steaming bureaucracy that take time and effort to wade through. Like good software, it requires principles and discipline to construct correctly and avoid 'technical debt' - though a quick&dirty solution will certainly work in the short term.
I've noticed as well, it's quite common that when a well-constructed solution takes much more time (and may be harder to identify) than an quick fix, proponents of the quick fix will claim that the 'do it right' folks are actually saying we should do nothing.
I wasn't in industry when that issue came up, and I wasn't employed by Apple. So, it really isn't fair to hold me responsible for a problem I didn't have. I've only recently begun carrying a mobile device of any sort, furthermore.
There are infinitely many problems that I haven't solved nor, I reckon, have you. I will not argue, though, that we automatically are not capable of solving them, as we have not encountered them and have no reason to solve them.
Given the constraints, given the hardware, given the opportunity and incentive, we certainly could come up with something similar. Just because we did not does not mean we could not.
This logic puts us in the unfortunate opportunity of saying "Well, the first person to run into the problem, to them goes the spoils!"
That's rubbish, and heavily encourages either wasteful flailing about in the problem space wasting resources, or worse, explicitly avoiding exploring even the same areas as others because you'd hate to be a few minutes late.
We need to be free to attempt solutions to problems regardless of who else has worked on them and to what success.
Second, the point I was making was not that Apple execs can't invent anything (indeed, I believe I set the bar fairly low for novelty!) or that groups only find trivial progress.
The point was that in a community we expect some users to find problems and others to find solutions--and these may be different folks, spread far in time and space. You made some statement seeming to imply that one must both discover and solve a problem, and that is what I took issue with.
The problem is both. We can't pretend that failed solutions with good intentions are not problems. It is not worth adding more problems on the stack because the guess-and-check solution whims fail. Solutions can be measured and worked towards, not guessed at where they do such large changes that their failure is also large.
Assuming tue devs don't live in a vaccum, it is other people eho define the problems to be solved. Doing so consiously, and not unconsiously by chance, is what engineering does. Producing something to produce something, while ignoring the problems you where handed to solve (doesn't matter if it is clients, customers, regulators or management), is pointless.
The tricky bit is figuring what the real problem to be solved is, I agree. Ignoring that question and doing whatever comes to ones mind first doesn't really work so.
I agree that there are better ways of solving the problem. Getting back to the root cause would be good. But, over the years I've seen too many cases where users have to live with a poor experience while the development team is working on the "right way." It's nice to see the experience of the user taken seriously.
The point I'm trying (and failing) to make is that if a solution to a problem is reliably mis-used by its users, then it's not actually a solution in practical terms. The problems in this space are ultimately social, not technical. Success is measured by usage, not passing tests.
If you read the article, that's not at all what it's about. In tech, the issue being discussed is closer to what's commonly termed "analysis paralysis". Sometimes you just have to act on your instincts (honed by experience, knowledge, and study) and act rather than looking for a larger pattern or perfect solution.
FWIW, I'm not saying we must have a perfect solution: I'm saying that we have to build systems which make the implicit failings of their imperfect solutions explicit. As an example, it is impossible to build a system which gives one person access without permitting that person to lend that access to others: we need to acknowledge that rather than pretend it's untrue.
Here's a key paragraph:
> I am not solution-oriented. I don’t see a problem and get giddy at the idea of solving it, patching it up and sending it on its merry way. I want to poke it and ask it questions. Where did it come from, what is it doing, what’s its story? I want to take it to tea and hear about its life and understand it to its core. And if, at that point, I’ve come to a wholistic understanding and am able to solve the problem, by all means, let the problem-solving commence! But my instinct is never to solve, but to understand.
This is not a statement of perfectionism, but rather a deep yearning for like-minded people who believe in trying to understand the problems they're trying to solve.
The RFC process, which has gained more prominence through projects like Ember, Rust, Swift, and Yarn, operate on the same principle: that we should try to make sure we understand, not just rush in with the first solution that comes to mind.
Iteration and contact with reality are important. A desire to understand is not in conflict with a desire to iterate and work with communities. But too often, the tech community makes a virtue out of moving fast, breaking things, and never coming to a deep understanding even in many of the most successful cases.
I think we owe it to ourselves and our community to get past a knee-jerk reaction to this post.
reply