Getting stuck really sucks. It can be soul-crushing.
As developers, what do we do when we are stuck? We have a process for code review, unit testing and deployment.
What is your process for when I get stuck though?
I ran into a really frustrating problem during my live stream and after hours of struggling with it I just had to call it a day.
Speaking with a friend that evening, they asked me how the stream had gone and I lamented my getting stuck.
Their response inspired me to write this post.
You stream to help people learn, right? Maybe watching a professional work through hard problems is more useful to your audience than seeing you do everything as if by magic.
They were right.
The next day, instead of the previous feeling of dread at facing my own inadequacies, I felt inspired to build a strategy for when I was stuck, publish it, and ask for feedback and improvements from the broader development community.
So here we are. Please suggest additional steps in the comments!
Step 1: Collect Information
This seems like the obvious place to start.
Collect everything you can about the issue and put it in a file. I use a simple markdown editor to take notes while I work or stream.
Copy the error
Copy the exact error into your file.
Read the error carefully
Like actually read it.
Investigate and record the backtrace
If you have a backtrace, step through it and read the surrounding code. If anything looks suspicious, copy it into your file too.
Go through any documentation around the code or tool in question. Copy links or documentation into your file.
Look for code examples
Search the documentation for relevant examples and stick them into your document as well.
Step 2: Ask Google
You may be surpised that a Google search wasn’t step 1. Let’s be honest, you probably did a Google search before you even considered yourself “stuck”.
There is a reason this is step 2. Without the previous step (collecting information), you would be jumping into an ocean of information without arming yourself with some of your own.
Google is infamously good at solving programming problems, until when it isn’t. Then you’re really fucked. So do your research first. It’s too easy to get lost in pages of results otherwise.
Search the exact error
This should be your beginning point.
Uncaught TypeError: fs.existsSync is not a function at getElectronPath
Add quotes in appropriate places
If you don’t know how to use quotes in Google searches, I’d suggest learning them here. You should look at which parts of the error should always be considered together.
Uncaught TypeError: "fs.existsSync is not a function" at getElectronPath
Search the error without project-specific terms
Try and remove terms which are specific to your particular implementation. In the example, “uncaught” is probably not too relevant and
getElectronPathmay not be the only context which triggers the error. So let’s strip that out.
TypeError: fs.existsSync is not a function
Search for “what you are trying to achieve” instead
Maybe you’re trying to do the thing you’re trying to do in the wrong way. This is a good way to sanity check.
Remember, if you find any possible solutions, record them in your document!
Step 3: Ask a Human Asynchronously
Depending on your company culture, this step may come earlier or later. I do think it’s important to ensure that you reach out asynchronously first.
I believe people should consider their colleagues’ time and attention to be the most precious resource in any organization.
This means Slack, Microsoft Teams or god forbid E-mail.
Step 4: Reproduce the Error in a Simplified Manner
This is a technique I often forget, but can prove invaluable in your quest for answers.
The basic idea is this: reduce the problem space.
This means either commenting out or removing parts of your system until you can’t remove anything else.
Alternatively, you can try and work in the opposite direction and try and build the minimum amount of surface area before you run into your issue. This strategy often means starting an entirely fresh project and rebuilding a tiny subsection of functionality in isolation.
Step 5: Stack Overflow
Stack Overflow doesn’t hold the highest reputation for friendliness, but this is usually because people who ask questions there have been lazy and not done the appropriate work to prepare their question.
That’s why you should always search for your question first. Be considerate.
Ask on Stack Overflow, but make sure to use your handy document (there was a reason to record all of this after all!) for reference. Post context, be descriptive, be polite.
Step 6: IRC / Gitter / Reddit
Now we’re getting desperate.
Fortunately, you’ll often find that particular libraries and ecosystems have their own IRC channels. Yeah. IRC. Remember that? Check out FreeNode IRC here.
Barring that, check out Gitter. If you’re not familiar, Gitter is a instant messaging platform that plugs into Github and other coding tools to build communities around particular software libraries.
Step 7: GitHub (Issue)
Okay. Maybe you’re not the problem. Maybe it’s a bug in someone else’s code. GASP. I know, you certainly didn’t think that before now right? ;)
So, let’s use the same principles of considerate detail that we used with Stack Overflow here.
Let’s create a GitHub issue. But before you do, re-read the documentation again. And while you’re here, you may as well read the source code and look at more recent versions of the software that might already contain the fix you need!
Create a Git issue in the library you believe to be the cause.
Be polite and don’t assume they are wrong. You’re probably doing something stupid. I’ve been doing this shit for over 2 decades and I do incredibly stupid things in my code almost hourly.
Step 8: Can we do it better?
Can you implement what you want to do in an even better way?
Stop. Think about it.
What if you could achieve what you’re trying to do without using this tool, or method, or class? Could you do this thing in an even better way, that circumvents this whole problem entirely?
Step 9: Can we get it working, worse?
We’re getting to the end of our metaphorical tether. Okay. Deep breath.
What could we do to get this working “quick and dirty”?
What that be enough? Is there a “lo-fi” or “low-tech” solution here that allows us to dodge this issue?
Step 10: Rubber Ducking
This is a technique where you talk to an inanimate object like a lunatic. It actually works. Go find some private place (unless you already have a reputation for psychotic breaks).
Speak through your problem out loud. Externalizing the problem usually helps us approach it from a new perspective.
Step 11: Ask a Colleague Synchronously
Okay, by now your colleague should have responded to your earlier request. If they haven’t, they are ignoring you because they can detect your terror.
At this point you have my permission to interupt their ass. If they complain, send them my way. Really. I could use the publicity.
Pair on the problem.
Don’t just ask them questions. Get them looking at the code. Run them through it.
Your goal here is not to share your pain, it’s to share your understanding of the problem. Remember this.
Oh yeah, show them the massive document you’ve prepared with everything you’ve found out and tried.
When you find your solution don’t just forget the process and dump all of your good work.
You’ll probably encounter this problem again, and if you won’t, someone else will.
Take your notes and write them up. Post them on your company’s development wiki. Even better, post them on a blog somewhere. Share the love brah. Please!
This was just what I came up with.
If you have any recommendations… additional steps, reordering or improvements please comment! I’d love to add to this. :) Getting stuck really sucks. It can be soul-crushing.
So. Share the love. <3