Important problem: you have to raise lots of money, work with a huge team, become a manager, fight with government regulators, do lots of marketing.
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.
If your product is able to spread by word of mouth, then I'd argue you were working on an important problem. People generally don't recommend things that are not 'important' to them in some way.
Eric Barone's success with Stardew Valley won this debate. Hell, Eric won this debate by virtue. He didn't have to do everything himself, but the very fact he's limited anyone else working on the game has played a huge role in every port of it continuing to sit in the top 10 for sales nearly four years on from its release.
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.
Theres a decent point in here, but the examples given are far less convincing than the author seems to think.
> 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.
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.
I think this is a basic tenant of research - you can't always expect a specific outcome, sometimes you just have to explore curiosity and see what turns up.
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?
Meaning and purpose are not things that you find in work; they are things that you make. As a CTO in a small adtech company, my standard pitch to hungry young talent went something like this: You're not going to be curing cancer or putting people on Mars, and we don't have daily catered lunches or a foosball table, but I will give you A) more responsibility than you would have elsewhere, B) more opportunity to make an out-size contribution to the company, C) more freedom to choose the tools and methods you want to use, and D) lots of data to play with. And then I would point out people who honed their crafts and made money in adtech and then went on to work on curing cancer, sending people to Mars, etc.
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.
> For instance, GPU hardware was developed to run first-person shooters with increasingly fancier graphics. Today, it powers some of the largest high-performance computing clusters where "important" science is done.
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.
I also think the GPU example is really flawed because ultimately it required other people who were working on “important” problems to execute the work of adapting GPU programming to their domains.
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.
Nice article, but I got sidetracked by this line near the beginning:
> 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'm reminded of how the Inca had wheels on their toys but never put them into practical use.
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.
Useful to keep in mind that wheels confined to toys was due some combination of a lack of animals that are good at pulling (llamas aren't great as that) and metal use being primarily confined to decorative purposes (so durable axles unlikely) :)
I often take the perspective (with my loosely anti-capitalist sympathies, admittedly) that the mechanistic forces of capitalism aren't "bad", but simply aren't curious about certain things in the world. The system is just a bit incurious about some very human things, and just like an emotionally incurious person might ask less questions of a peer, so too does our dominant system act in some parts of human affairs.
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.
This is an interesting hypothesis about capitalism (also seems to go against “capitalist realism” theory). Can you give a few examples of what the areas that capitalism cannot get curious about are? What would be the common characteristics?
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.