I have a strong reflex to not do complicated things when I’m writing code—I flinch away and try really hard to avoid them. I think this reflex often serves me well, because complicated code is a pain to maintain and in real life you usually don’t need it. When I watch other people code, I often see them start down a complicated path to solve a problem, and then persevere through it. When faced with the same problems as them, I’m much more inclined to start down a complicated path, then realize it’s going to be complicated and reflexively give up. Most problems that I run across actually have relatively simple solutions, so this serves me well: I end up flailing for longer at the start, but then I end up with simpler code than I would have had otherwise.
But sometimes programming tasks are actually complicated and difficult. And my reflex against doing hard things really serves me wrong there. I find myself procrastinating and circling around the problem. I start attempts and then give up on them. Eventually I notice that I’m not getting anywhere and I need to just suck it up, get a coffee and sit in a quiet room and actually plough through it. But I’m sure I’m much worse at this than many other programmers who are as good as I am at easy things.
For this reason, I’ve never implemented in-place quick sort, or a correct alpha-beta pruned minimax, or any kind of self balancing binary search tree. I’ve started all of them, but I always give up. I’m pretty sure that the most complicated small-scale code I’ve written in my life was written in my technical interviews at Apple, because they asked hard questions and they were watching me so I was motivated to not give up. (But even that pressure wasn’t enough—towards the end of one of the interviews, my interviewer asked if I could modify the code I’d written to handle a more general problem. I basically said “I could, but I really don’t want to” and half-assedly tried to evade the question.)
Satvik Beri made a particularly great comment:
I try to maintain separate mental modes, searching for simple solutions vs. implementing tricky ones, with a trigger to switch–if I’m stuck on a problem and it genuinely looks like there’s no easy solution, I mutter “I ain’t afraid of nothin’” (stolen from Claude Shannon: https://www.cs.utexas.edu/~dahlin/bookshelf/hamming.html) and dive in.