In the land of the blind, the one-eyed man is king
This is an old saying that I was thinking about last night.
In the land of the blind, the one-eyed man is king
I got a new job about 6 months ago and the position involves working with a lot of top-tier software engineers, which is great.
But one thing I’m struggling a bit with is getting acceptance for my ideas, and I’ve been trying to reflect on why.
One interpretation of the saying is that someone incompetent may not know that they’re incompetent because they’re among people who are less competent. Is it possible that I’m the proverbial one-eyed man, and my success to date may only be relative to people who are less competent than me? And that now that I’m hired into a team of two-eyed men, the ideas I “see” are generally dismissed as crazy, impossible, or impractical because I’m surrounded by people with better sight than me?
It’s hard to accurately evaluate oneself in the absence of reflection from others, and I personally don’t have a strong sense of self-worth, so it’s hard to emotionally protect myself against this subtle dismissal1.
But there’s another possibility. Maybe the rest of the team has eyes, but I have ears. That is, maybe we have orthogonal senses which are able to sense different aspects of the landscape2.
The types of ideas I have tend to be those of the “paradigm-shifting” variety. For example, I’ve previously talked in this blog about using snapshotting as a replacement for compilation and bundling; how this change in approach can simplify your code while simultaneously making it more robust and not sacrificing any control.
Paradigm shifts are inherently difficult to explain. If you’ve ever learned functional-style programming, and then tried to explain it to someone else, you’ll see this challenge3. It’s not the complexity of the idea that makes the functional paradigm hard to communicate to others, it’s that it really requires you to immerse yourself in it and come to that “aha” moment yourself. Once you reach that point, you can see more clearly to evaluate when best to use the different paradigms to your full advantage.
I should add that the transition from one paradigm to another need not involve starting again from scratch. For example, it’s perfectly possible to slowly adopt functional-style patterns into a previously-imperative project. A paradigm shift can just mean a general shift in the direction that a project moves. Similarly, paradigm shifts do not necessarily require much upfront investment (although they sometimes do), but can often instead be adopted incrementally. The biggest upfront investment may be the work to uncover and understand the paradigm itself.
Beyond the snapshotting paradigm, I have many other examples of ideas of mine that are paradigm shifts. In fact, this general tendency is right there in my blog title: challenge the way you think about code. It seems to just be the way I work. To continue the trend of applicable sayings, perhaps I’m the proverbial fish trying to climb a tree:
Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.
In this sense, it’s possible I may be trying to “climb a tree” by trying to do the work handed to me by a team of climbers, rather than a team of swimmers. I struggle enormously with the work I’m given, both on a technical and emotional level, to the point where sometimes my brain just goes into a mental block and I stop making progress altogether. But at the same time, I can see big areas of need where my “swimming” skills would have a positive benefit.
Falsifiability and Evidence
So how can I evaluate which is true? How do I know if I’m the one-eyed man in the valley of the sighted (i.e. just not that great at software engineering), or the fish trying to climb a tree? The observable feedback may look similar in both scenarios.
Well, one thing is that I can and do talk to other fish. I don’t have many fish friends, but the ones I do tend to believe in and support my ideas in general.
But objectively, what if all the fish I know are actually just incompetent chimpanzees?
Perhaps better evidence is historical success. Many of the projects I’ve done in the past have introduced paradigm-shifting ideas and come out successfully4.
Microvium may be the best litmus test and the only one of its kind to date in my portfolio. If the point of work is to contribute constructively to society and make the world a better place, then having demand for something you produce independently is perhaps the best indicator of “success”5.
Having someone pay for it will be even more an indicator of success, so getting Microvium to a point where I can monetize it may be the best route forward for me.
Can fish and chimpanzees work together?
I think the answer is obviously “yes” and the different skill sets may be complementary.
But it should be acknowledged that paradigm-shifting work looks quite different from traditional software engineering and may not fit into a traditional software engineering workflow.
For example, it can take months of “just thinking” to develop a new paradigm. Many of the breakthrough ideas I had in my career are not things that just “come to mind” one afternoon, just like an imperative programmer is not going to “invent” functional-style programming one afternoon. Concepts that take a while to “click” will take even longer to “invent”.
If it takes months of work to even know what the paradigm looks like concretely, how do you come to agreement that those months are worth dedicating to the outcome?
There’s a real communication challenge when it comes to communicating ideas that don’t fully exist yet. Traditional software development is not that open to concepts that can’t be coded up in an afternoon to demonstrate what you’re talking about.
And how do you evaluate the cost/benefit of an idea that will take months just to conceive, let alone code? I tend to have a good “gut feel” about the benefits a paradigm will have — otherwise I wouldn’t be pursuing the idea. But it’s hard to communicate this to others until the idea itself is more concrete (which can take months of work).
And work of that nature is not something that fits well into sprints (if you do sprints) or JIRA tickets (unless you don’t mind month-long tickets).
So I think it requires an unusual level of trust and autonomy, which is something I’ve very grateful to have had in past jobs. When tackling a particular design or architecture, I’ve had the luxury of pursuing my hunches and listening to my instincts, even when the benefits of the choices may not be immediately apparent.
This is no criticism of the team or company. They’re all great people and very respectful. None of the discussions are adversarial, and everyone does their best to judge fairly according to their own experience. ↩
That’s not to say that I necessarily have a “special” sense and everyone else is the same. It’s probably more accurate to believe that everyone has their senses tuned to a different profile based on their own experience. ↩
I don’t claim to have invented anything on the same scale as “functional programming”, but it’s an example that’s relatable to many people. ↩
It’s still not unambiguous evidence. It’s entirely possible that what I rank as “successful” is another person’s steaming pile of garbage. Certainly, in the past, I’ve seen other people’s “successful” work and silently judged it as fragile and poorly abstracted. ↩
I can think of edge cases where this isn’t true, but it generally still seems like the best metric. ↩