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).
Hard doesn't mean impactful. In fact that's one of the biggest mistakes I see junior engineers make! But glad you got that learning experience, as you become more senior you'll definitely develop a better understanding of what drives actual impact.
Not everything in life is correctly evaluated according to Meta performance review criteria, probably not even what people are doing at Meta.
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.
Example: you know what would be harder than anything we're talking about here? Quadrupling the performance of the best compression algorithms. It's hard. In fact, maybe there's some information theory that even says it's mathematically impossible. That makes it really hard, which makes it what all of us should immediately start working on.
The author writes elsewhere that you also have to have an edge, but that's frequently omitted from this "hardest thing" advice.
The sort of people it's usually directed at, though, are knowledge workers (like computer programmers). "Hard" in our context is "something I don't yet know how to do". Always. No exceptions. Every time. If I know how to do it, it's trivial. If I don't, I have to figure it out.
And in my experience, the "do the hardest thing" VC-founder cheerleader types (who are always telling you, never themselves) absolutely lose their shit when they see somebody trying to figure out how to do something. Reading docs? Setting up controlled experiments? Why are you wasting time with all of this nonsense and not just getting to the "hardest thing" so I can bill the client and you can move on to the next "hardest thing"?
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.").
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?
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!
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.
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.
Unfortunately, the safety net necessary to support oneself while they do the hardest thing isn't guaranteed.
naw but this kind of mindset ended up burning me out at times; some of us clearly take general ideas like this in different ways than intended perhaps
but I think the actual "trick" here is about finding unfilled niches rather than necessarily doing "the hardest thing"
The addition of that last word is the difference between the chance at eventual success and the human burning out on world peace, time machines, free energy devices.
https://youtu.be/-Evrm03Y5hI?si=CvadZlyzR-PfwFh5
[Bonuses: narrated by Werner Hertzog and starring Ed Ruche]
Self driving cars were the "monkey" 10 years ago but now they are largely derisked. I'd like to see Alphabet working on the next generation of innovations. For me personally, I'd like to see them work on:
- Teleportation. - Talking animals. - A cure for death.
I'm not seeing them work on anything remotely as ambitious these days!
As someone once said: any fool can do for $2 what it takes an engineer to do for $1.
I could try to swim across the Pacific Ocean, walk across Siberia or consume a family size portion of McDonalds in a single sitting. All those things are hard. All those things have zero to negative ROI.
Doing hard things won't get you anywhere. Most hard things are useless. And a lot of the most valuable things are not hard at all.
"You should take care always to be inclined
not to the easiest thing, but to the hardest;
not to the tastiest, but to the most insipid;
not to the things that give the greatest pleasure, but to those that give the least;
not to the restful things, but to the painful ones;
not to consolation, but to desolation;
not to more, but to less;
not to the highest and dearest, but to the lowest and most despised;
not to the desire for something, but to having no desires.”