Failure Modes in People Who Develop Math Skills but Don’t Capitalize On Them via Coding
1) Difficulty grappling with complexity when it grows so big that you can't fit everything in your head. 2) Lack of understanding or willingness to accept practical constraints of the problem and incorporate them into the solution. 3) Getting distracted by low-ROI features/details. 4) Being unwilling to do "tedious" work.
Want to get notified about new posts? Join the mailing list and follow on X/Twitter.
I know some people who are skilled in math but never really capitalized on it.
Two trends I noticed:
- they were typically not very skilled at coding, and
- they also lacked discipline to work on things that had to be done but weren't inherently intellectually enjoyable.
The idea of someone being good at math but not coding is sometimes surprising to readers who think that being good at math naturally transfers over to coding.
While there is definitely a positive correlation, the correlation is nowhere near as high as you might expect.
In particular, here are 4 failure modes that even mathematically inclined people can fall into, that prevent them from capitalizing on their quantitative skills in the form of coding.
1) Difficulty grappling with complexity when it grows so big that you can’t fit everything in your head.
Not organizing and naming things well, not understanding or maintaining scope, letting responsibilities bleed too much across scope. Accepting needless complexity, sometimes even viewing complexity as a friend rather than the enemy.
2) Lack of understanding or willingness to accept practical constraints of the problem and incorporate them into the solution.
It’s good to think about the Platonic ideal and build towards it by default, but you can’t let it become a constraint in the sense of the great becoming the enemy of the good.
3) Getting distracted by low-ROI features/details.
In math there’s typically a clean line separating details that are absolutely critical versus completely irrelevant.
But in reality there’s more of a spectrum: lots of things matter at least a little bit, and some things matter way more than others, and it can be hard to tell them apart if you’re an abstraction astronaut who lacks boots-on-the-ground experience.
You need a good sense of what things matter a lot and how costly their implementation will be relative to their impact.
You have to be able to sniff out the things that have a 100x or 1000x impact and ROI relative to other things.
4) Being unwilling to do “tedious” work.
This plays into item #3 because in order to get that good sense of what really matters, you have to get your arms around the problem, which typically requires getting your hands dirty and doing enough manual grunt work to develop strong intuitions and gut feelings.
Mathy people sometimes justify avoiding the grunt work because it’s tedious and they already have it all figured out in their head, but the issue is that the contour of the problem space in their head doesn’t match up with reality.
Their reasoning tends to be sound, but it’s the assumptions that get them: there are parts of the real-life problem that they haven’t loaded up in their head. Sometimes they think important things are negligible, other times they think negligible things are important.
Want to get notified about new posts? Join the mailing list and follow on X/Twitter.