Schlep Blindness (2012) | Hacker News Reader

Schlep Blindness (2012)

paulgraham.com

53 pointsenigmatic0214 comments

embrace the grind: https://jacobian.org/2021/apr/7/embrace-the-grind/

Wow, this was a great and somewhat eye-opening read. Thanks for sharing!

> People said I did the impossible, but that's wrong: I merely did something so boring that nobody else had been willing to do it.

I really enjoyed this, thanks for sharing. My takeaway is don't be afraid to put an unreasonable amount of time towards something.

It reminds me of PG's essay "The Bus Ticket Theory of Genius", which is like a hack on this idea. If you're obsessively interested in something, you're bound to spend an unreasonable amount of time on it.

Taking it even farther, there's a Revisionist History episode on the song Hallelujah, who's original version took over two years to write. The two components to "experimental" genius: time and iteration.

http://www.paulgraham.com/genius.html https://www.pushkin.fm/episode/hallelujah/

I feel strong survivorship bias in this theme.

What about them, who embraced the grind, spent unreasonable amount of time, money and effort, but were not successful? Doesn't that look so obviously incorrect in retrospect that we make jokes about those people?

no; the grind is necessary but insufficient.

According to the article, ignorance (of the complexity) is one of the best conditions when starting large projects.

I have heard anecdotes from people finishing large projects that they would have never started had they known how hard it would have been.

Not everyone can turn their ignorant mind on and will always think about all sorts of problems at the start of a project, but perhaps it helps to not get intimidated or blocked by them and get into a mindset that "we'll cross that bridge when we get there".

The is a real opportunity cost when completing these 'large projects' that often becomes visible at the very end of the endeavour. Ignorance can be a bliss - ignorance can be devastating. At the end you need to decide on case by case basis what is the best attitude in order to proceed in the best interest of all stakeholders.

This question is so important: > "what problem do I wish someone else would solve for me?"

Otherwise you might fall in the trap thinking just because a problem is hard, it's worth starting a startup to solve it.

Start with ignorance, but then make the schleps as conscious and explicit as possible?

People literally assemble jigsaws and exercise on treadmills in their spare time. Repeatedly! So it seems that even the most apparently mechanical tasks can be made interesting with some creative engagement.

In every job that must be done, there is an element of fun. You find the fun and - SNAP - the job's a game -- Mary Poppins

There is an army of people with weird hobbies that keep this world running. The people maintaining OpenSSL, the Open Street Map contributors, the people who maintain lists of countries and time zones, and so on.

Blessed be their souls.

I think that the pendulum has swung too far the other way: Startups that get funded are disproportionately trying to solve some annoyance. There's no room for whimsy or lovable products (like Apple and Blackberry were early on). There's no room for disrupting an entrenched player with an agile team. No. Solve a pain point or no funding for you.

So, to turn it around, what in the current day is schlep work par excellence? A few things stick out like very sore thumbs.

* AWS permissions management, and IAM in general.

* Data cleansing and data governance at scale.

* IoT costing and specifications.

* Rural broadband, in all its forms and associated problems. This one is especially close to the heart for me in Wisconsin.

* Negotiate best offers on service renewal.

As far as I can tell, reading documentation - not in snippets, to remember the details of something you know how to do, but top-to-bottom, to learn capabilities you didn’t know existed.

Reply on news.ycombinator.com