I have this Unfrozen Caveman Lawyer kinda schtick: “I’m just a simple Bad Programmer. Your nested ternary conditions confuse and frighten me!” It’s a nice way to point out when a hunk of code is too complex. It’s a posture that also frees you up to admit what you don’t know, and ask for help.
Some of your bugs and features are going to be slam-dunk gimmes, but they’re not the ones you’re avoiding by reading this post. When your momentum’s snagged on one of the other tasks, and you’re pretty sure the editor screen in front of you doesn’t have enough information to pull it loose, here are four stages of unsticking:
“What can I copy from Stack Overflow?”
This is a common first step, driven by the fear of annoying your coworkers or being sent a LMGTFY link.
When the problem is obscure, or understanding the solution doesn’t add to your understanding of the larger project, copypasting a solution is okay. It’s the mental equivalent of adding a little node package: somebody else already worked out the edge cases, and there’s no reason to spend your day duplicating that work.
Example: Googling for a good URL validation regex.
“Does anybody know how to—?” (less awesome)
or
“Here are my assumptions about this bug, and here are the steps I’ve taken to try to fix it. Do you see any holes?” (more awesome)
Assuming you’ve done a little work to define the problem, there’s never a bad time to take the more awesome approach here. Ask questions out in the open rather than in private when possible. You get the benefit of everyone’s experience, and it makes asking for help seem normal.
Bonus point pre-step: rubber ducking.
“How would I describe this problem generally? Have others used the same description, and solved it well?”
This is where you enter the world of Design Patterns, the Catalog of Refactorings, and other useful programming heuristics. Frameworks and languages come and go. You can apply generalized solutions over and over. See also: code smells.
Examples: Write a high-level explanation of the problem in pseudocode, and see if you can change its shape. Avoid that nested conditional.
“What’s happening under the hood?”
This is the main thing I’ve observed in better programmers: they’ll take the time to slow down, read the lowest-level source code that applies, and work toward a new, unGoogleable solution from scratch when nothing else fits the bill. It reminds me of one of Teller’s “secrets”: “You will be fooled by a trick if it involves more time, money and practice than you (or any other sane onlooker) would be willing to invest.”
If you’re new to the whole problem domain, Julia Evans writes often and well about taking on intimidating technological territory.
Don’t jump straight to this step, though. That’s the way of NIH Syndrome, arcane in-house custom frameworks, and that Hacker Newsy “we can solve any problem in this comment thread because we’re smart” canard.
In watching screencasts of really good programmers, you realize they’re a) starting one level of abstraction higher or lower than you’d think, b) taking lots of small, dumb steps, and c) not skipping ahead. And that’s it.
The order I presented these above is the one I stick with, but we all mash the steps up a little bit. Avoiding a particular step, though, usually points to an unspoken fear.
Everybody gets stuck. One of the ways bad programmers like me can learn from better programmers is by observing their many approaches to getting unstuck. Notice which tack you’re taking. Notice which you’re not.
And if you’re still stuck, get random.