In my own tiny way, I applied this logic when trying to be a contributor to an existing and popular open source project. I found that puzzling out poorly-written bug report tickets, ignored by the extremely busy experts on the project, I could find work to do.
I started by looking at well written tickets (to-the-point descriptions, minimal reproduction examples), but that method got me no work: some expert on the project would have a pull request for that kind of ticket in just a few hours, whereas I would need at least a week to figure out the root cause and another few days to craft a fix and a test.
So I started looking at ignored tickets, i.e., tickets that had been sitting around for weeks or months with no activity. Those often turned out to be very poorly written tickets with either very little information, or a huge wall of text with much business domain-specific info. If those tickets contained repro examples at all, they were often complex and very long, using external libraries I never heard of, and devoid of table schemas and example data. Sometimes I could get the author to provide more information, sometimes the author would not respond. I might have to infer schemas and make up my own data, try different things based on a stack trace, install libraries I would have preferred to not install, etc. I would work on trying to reproduce the problem for a few days, and at least a few times I struck gold. Then I would work on a self-contained, minimal reproduction case, followed by a week of sussing out the root cause. It was pretty time-consuming, but I was able to get a few fixes merged using that method, such that I was no longer a total stranger on the project (which helped me get other things merged into the code base).
I learned this lesson kind of by accident. I've told this story before but I think it's relevant.
When I dropped out of college the first time around in January 2012, I assumed that my career options were extremely limited. I knew I needed a job, so I applied to pretty much every wage-labor job I could find: McDonalds, Lowes, Starbucks, Aldi, Publix, etc. Almost as a joke to myself, I sent exactly one application to a software developer position on Craigslist for a Flash, Foxpro, and Coldfusion developer position.
The only company that called me back was the software job. I interviewed there, got the job, and thus my career as a software engineer was kicked off.
In hindsight I realized something: the less qualified you are for a job, the more likely a company might be to overlook a lack of qualifications. McDonalds and Aldi and Starbucks have lots of qualified people applying for these positions, meaning that they can be very picky with who they hire.
Now compare this to Flash/Coldfusion/Foxpro developers in 2012. I didn't know any of these at the time particularly well...but to my benefit neither did anyone else! As a result, they didn't get a ton of applications meaning their selection pool was tiny, meaning that they basically had to take whomever they could get.
It's a good philosophy, but I always cringe when I hear it. Only because I once worked with someone who would always proclaim they were going to tackle the hardest thing first. Real ego play, from him at least.
Idk, I often felt the opposite. I naturally tend towards working on hard problems but my feeling is that if I chose instead to focus on an easier "thing" I could execute really well and be overall more successful.
Liked this post a lot, well done! Definitely appreciated that it was a site that actual has a unique design, and isn't just another Medium article...
A book on a similar subject that I don't see mentioned very often but which I quite enjoyed as "Tough Things First" by Ray Zinn [0]. Not the most popular one, but really down to earth and approachable ideas. Kind of like PG's "do things that don't scale," just applied on a broader timescale.
My hardest thing took about 7 years to build (with a child getting born and slowing things down a bit) but still. Good to hear that I’m not the only one :)
In the current era of urge to make things faster/more, that article felt refreshing. Good things take effort and time to create, and it is not something bad, it's just the way the things become good.
(Author of the post here) I think the key point is that even bad businesses take time and effort to create!
The distinction is between "low-hanging fruit" ideas ("Let's start a cafe!" "Let's start a WordPress theme business") and "high-value, high effort" ideas ("It's 2003. Let's build VoIP software.").
Sure, I agree. I was more about encouraging to not be afraid of something hard.
Today's narrative pushes people to try vibe code as much ideas as possible, even in parallel, but I don't think it's a fruitful approach. One should not be afraid of doing something non-typical (hard) if they belive in the idea. And if you believe, dedicate some quality time for it. If you don't believe - why bother even with prototypes?
Well what if you take on an extremely ambitious project like writing a programming language complete with DAP step debugging, a full LSP, etc, etc?
That takes a lot of quality time to just figure out the right syntax and semantics, let alone having to figure out how all of these complex pieces fit together!
Agree.
But the tricky part is how much you believe in the idea. It is hard to be faithful to the right idea. One is influenced by other people, especially one's boss if it's in an corporation.
In my own tiny way, I applied this logic when trying to be a contributor to an existing and popular open source project. I found that puzzling out poorly-written bug report tickets, ignored by the extremely busy experts on the project, I could find work to do.
I started by looking at well written tickets (to-the-point descriptions, minimal reproduction examples), but that method got me no work: some expert on the project would have a pull request for that kind of ticket in just a few hours, whereas I would need at least a week to figure out the root cause and another few days to craft a fix and a test.
So I started looking at ignored tickets, i.e., tickets that had been sitting around for weeks or months with no activity. Those often turned out to be very poorly written tickets with either very little information, or a huge wall of text with much business domain-specific info. If those tickets contained repro examples at all, they were often complex and very long, using external libraries I never heard of, and devoid of table schemas and example data. Sometimes I could get the author to provide more information, sometimes the author would not respond. I might have to infer schemas and make up my own data, try different things based on a stack trace, install libraries I would have preferred to not install, etc. I would work on trying to reproduce the problem for a few days, and at least a few times I struck gold. Then I would work on a self-contained, minimal reproduction case, followed by a week of sussing out the root cause. It was pretty time-consuming, but I was able to get a few fixes merged using that method, such that I was no longer a total stranger on the project (which helped me get other things merged into the code base).
I learned this lesson kind of by accident. I've told this story before but I think it's relevant.
When I dropped out of college the first time around in January 2012, I assumed that my career options were extremely limited. I knew I needed a job, so I applied to pretty much every wage-labor job I could find: McDonalds, Lowes, Starbucks, Aldi, Publix, etc. Almost as a joke to myself, I sent exactly one application to a software developer position on Craigslist for a Flash, Foxpro, and Coldfusion developer position.
The only company that called me back was the software job. I interviewed there, got the job, and thus my career as a software engineer was kicked off.
In hindsight I realized something: the less qualified you are for a job, the more likely a company might be to overlook a lack of qualifications. McDonalds and Aldi and Starbucks have lots of qualified people applying for these positions, meaning that they can be very picky with who they hire.
Now compare this to Flash/Coldfusion/Foxpro developers in 2012. I didn't know any of these at the time particularly well...but to my benefit neither did anyone else! As a result, they didn't get a ton of applications meaning their selection pool was tiny, meaning that they basically had to take whomever they could get.
no realization in hindsight about luck? lol
Absolutely luck as well. No argument there.
no realization that luck is involved in every opportunity that crosses your path so there's no realizations to be had regarding luck
It's a good philosophy, but I always cringe when I hear it. Only because I once worked with someone who would always proclaim they were going to tackle the hardest thing first. Real ego play, from him at least.
Do the hardest thing or do the easiest thing cheaply
I worked for a camera company that made [still makes] some of the best cameras ever.
Their Quality was astronomical (with, of course, the rare exception).
It was the kind of thing that I was repeatedly told, by my peers in other companies, was impossible.
But my bosses wouldn't accept that. They could be real pains.
We did make top-shelf gear, but you won't really get rich, doing that (unless you're a SpaceX person, I guess).
I think the people that make a lot of money, do that by finding a "sweet spot," in improving the Quality of everyday stuff.
Idk, I often felt the opposite. I naturally tend towards working on hard problems but my feeling is that if I chose instead to focus on an easier "thing" I could execute really well and be overall more successful.
“Do the easy/hard thing first,” is the first of artist Tom Sachs’s Paradox Bullets
https://youtu.be/-Evrm03Y5hI?si=CvadZlyzR-PfwFh5
[Bonuses: narrated by Werner Hertzog and starring Ed Ruche]
Liked this post a lot, well done! Definitely appreciated that it was a site that actual has a unique design, and isn't just another Medium article...
A book on a similar subject that I don't see mentioned very often but which I quite enjoyed as "Tough Things First" by Ray Zinn [0]. Not the most popular one, but really down to earth and approachable ideas. Kind of like PG's "do things that don't scale," just applied on a broader timescale.
[0] https://toughthingsfirst.com/book/
My hardest thing took about 7 years to build (with a child getting born and slowing things down a bit) but still. Good to hear that I’m not the only one :)
In the current era of urge to make things faster/more, that article felt refreshing. Good things take effort and time to create, and it is not something bad, it's just the way the things become good.
(Author of the post here) I think the key point is that even bad businesses take time and effort to create!
The distinction is between "low-hanging fruit" ideas ("Let's start a cafe!" "Let's start a WordPress theme business") and "high-value, high effort" ideas ("It's 2003. Let's build VoIP software.").
Sure, I agree. I was more about encouraging to not be afraid of something hard.
Today's narrative pushes people to try vibe code as much ideas as possible, even in parallel, but I don't think it's a fruitful approach. One should not be afraid of doing something non-typical (hard) if they belive in the idea. And if you believe, dedicate some quality time for it. If you don't believe - why bother even with prototypes?
Well what if you take on an extremely ambitious project like writing a programming language complete with DAP step debugging, a full LSP, etc, etc?
That takes a lot of quality time to just figure out the right syntax and semantics, let alone having to figure out how all of these complex pieces fit together!
Agree. But the tricky part is how much you believe in the idea. It is hard to be faithful to the right idea. One is influenced by other people, especially one's boss if it's in an corporation.
100%