Work on Unimportant Problems (2012)
yosefk.com
yosefk.com
Unimportant problem: you spend your days coding, you work alone or with a small team, you stay lean and don't worry too much about money, nobody can override your architectural decisions, the government has never heard of you, your product spreads via word-of-mouth from excited users.
I love Eric. Like, love him. He did something unimportant, but it meant something to him. And over time, it began to mean something to other people. Harvest Moon is not a massive selling franchise, so Stardew Valley was more likely to flop on that basis alone. Then you add in that indie devs get little exposure, no advertising, none of the connections that AAA companies have access to. And then there's the fact the game wasn't broadly tested before release. Eric had weeks of major bugs to patch right after release, and the pressure of hundreds of thousands of people who'd just spent $15 on his game. But maybe, just maybe, the patience and gratitude he received for his unimportant game was all the product of what he did and how he did it.
Any of the people could've said, "Just sell this to Valve. They'll fix it. You're in over your head, dude." But instead, he got a lot of, "Saves still corrupt. But make sure you get some sleep!" and a whole lot of "Can't get X to work, so I'm going to do Y." People could've abandoned the game. They didn't.
I like this idea of unimportant things. I can't be the only person thinking it's both absurd to spend time inventing a new way to keep shoes on our feet, but also thinking it's absurd we're using a piece of string still but sending billion-dollar machines to collect soil from nearby planets.
Unimportant problem: recruiting costs $$$
> C/Unix
developed to improve global telephony (important)
> the world of businessy/officy/enterprisey software (Windows, VB, Java, C#, ASP)
Perhaps "unimportant" to the author but most of these were aimed at multimillionaire sales contracts or major consumer sales (important). Its a categorical difference from a "small side project" (e.g. Python, Linux, etc.) of a solo author, and not really beneficial to his point.
Part of the story is that Ken Thompson wanted to play a video game. This is documented in a number of places
https://en.wikipedia.org/wiki/Space_Travel_(video_game)
As a part of porting the game to the PDP-7, Thompson developed his own operating system, which later formed the core of the Unix operating system.
Multics was closer to something "important", while Unix was something unimportant and a great example of the principle laid out in the article.
Also, the first application of Unix beyond Bell Labs was typesetting. They were using it to produce patent applications, saving the labor of many secretaries. It was not used for telephony.
C was co-evolved with Unix as portable language to write an OS in.
---
edit: For some color on how Bell Labs related to the rest of the org, I recommend "The Idea Factory" by Gertner and Brian Kernighan's recent memoir on Unix.
However the contrarian in me wants to call out a counter-point:
> Working on unimportant problems can create important side-effects.
If over-applied - this logic can essentially become the tech-investor equivalent of trickle-down economics.
Who is to say that those areas that benefited from the side-effects of other work wouldn't have benefitted even more from direct investment?
I am reminded of a story about a janitor. Being a janitor doesn't seem like an obviously meaningful and fulfilling job, but if you work as a janitor to provide for your daughter so she can go to college, then that job indeed can be profoundly meaningful.
When graphics hardware was relatively new, a better graphics card could make business applications like spreadsheets faster. It was practically a joke that people who wanted a video card to play games would rationalize their purchase by saying that they needed it for office applications.
The 'important work' surely benefited from the frivolous work that the hardware was purchased to run, but it was funded for a very long time under the guise of the important work.
While “unimportant” work might lead to important developments, that only happens because other people were doing the important work, and saw the opportunity.
So at the end of the day if you still want these societal gains, you must be advocating for working on “important” problems.
> Office software arguably solves no important problem: as Berglas convincingly argues, office automation results not in increased productivity, but in increased complexity of rules and regulations.
I’ve observed this phenomenon in my personal life, where I use automation and productivity tools to make my life more complex instead of reducing stress (especially my finances).
I kind of believe that similar things are happening now with video game tech, GPU mostly happened due to gaming and now benefits a lot of other fields, game engines are now being used in architectural, automotive and video production pipelines. I think there is a lot more to come.
I often tell friends that I enjoy working on neglected things that capitalism isn't curious about. This domain is a whole subset of reality, which has specific properties, especially in relation to network structure.
I would say that much of what's described in this post is to work on things that capitalism isn't _yet_ curious about.
While this is neat to suggest, I believe that maybe some things in the world (that are worth working on) might categorically be impossible for capitalism to become curious about -- capitalism is only eager to explore domains where value can [eventually] be skimmed by occupying a structural hole[1] (in other words, a choke point) in the social and/or information graph.
But some innovations are such that they only manifest and take form within resilient and redundant "clique"/"support" networks (in social capital theory parlance [2]). These networks by their very defintion lack a clear choke-point. To capture value there, someone must either (1) find the elusive but existing choke-points or (2) distort the whole system into produce a chokepoint. But this might be like capturing and compacting a cloud -- you force a phase transition and no longer have the thing you started with.
Anyhow, thanks for the chance to reflect :)
[1]: https://en.wikipedia.org/wiki/Social_network#Structural_hole... [2]: p. 408, fig 8 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.652...