I'm working with Meteor, which is a relatively young Javascript framework. As such, it seems like I often run into problems which haven't been asked on Stackoverflow already.

In one such case, I was agonizing over something that wasn't working, and it turns out it was a bug with Meteor. When I was working through this, I made the assumption that it was a problem with my code, and didn't even consider the possibility of a bug in the framework.

It doesn't help that I'm pretty new with Javascript.

So my question is, in the future, how can I more quickly decide if a bug is mine or the framework's? It's frustrating spending a bunch of time trying to debug something that's undebuggable, especially when I'm not confident in my JS skills.

  • You can search their bug tracker to see if the bug is already reported. To do that, you often need to do some investigation first anyway - your symptom is often quite different to the underlying cause. In difficult cases, the only way to figure out if a bug is yours or not is to track down the actual cause - get the source for everything you can and go wherever the investigation takes you in that code. But generally speaking, if you're not confident in your ability and you're using stable-version libraries, you're pretty safe assuming the problem is in your code.
    – user8709
    Commented Nov 6, 2015 at 18:25

2 Answers 2


So my question is, in the future, how can I more quickly decide if a bug is mine or the framework's?

The key is making the bug reproducible and isolated. In general you want to follow the same process initially whether you suspect the bug is yours or the libraries.

Stack Overflow's MCVE page is a great primer on this. SSCCE also attempts to speak to the same idea. Make an example that is simple and reliably reproduces the error.

As a simple example, imagine you have a an external method that is defined as:

Meteor.foo(int, int) // returns sum of two ints

You are using this method in your code, and suspect it is not working correctly. After following the MCVE process you arrive at the following code:

print Meteor.foo(0,2) // prints 0
print Meteor.foo(1,2) // prints 3
print Meteor.foo(2,0) // prints 2

This is now a compelling reason to believe that the Meteor library is causing the problem (obviously..). In this case it is clear how to write an example that is a "bug is not in my code" MCVE.

The point of all this is to narrow down your usage of your code until you find the minimal amount of code causing the problem. Trimming out extra code until you resolve the bug. If you can't trim anymore because of external library calls... probably found the problem.

Unfortunately, the reality is that nearly all bugs of this sort will not be as simple as that to reproduce. With these (and your MCVE or 'mostly MVCE' example) it's a good idea to:

  • View release notes / known issues
  • View open bugs
  • Ask a question on Stack Overflow or the libraries listserve
  • View the source code itself or what tests it has

There are other questions one, two about what to do once you arrive at the conclusion the bug is in the external library.

These sorts of problems can be really nasty when working with very expansive and commonly used libraries. We had an instance where multiple people were trying to track down a ship-block bug which ended up being a combination of a mouse driver causing the graphics to not render correctly with an external framework.

  • This answers is good for once you suspect that the bug is in third-party code. It seems less helpful for coming to that suspicion in the first place. Commented Nov 6, 2015 at 20:27
  • 2
    @WinstonEwert - I have found that trying to create an SSCCE will either lead me to the conclusion that the error is in my code or there really is a bug in the library. There's quite a bit of value in this approach if only in that it gives you a structure approach to determine if you are (in)sane regarding that piece of code.
    – user53019
    Commented Nov 6, 2015 at 20:33
  • @GlenH7, that's true. But when do you attempt to create SSCCE? Don't you already suspect that the third-party code is doing the wrong thing? What leads you to that suspicion in the first place? Commented Nov 6, 2015 at 20:50
  • 1
    @WinstonEwert - I use the SSCCE specifically as a means of validating between the three cases you highlight in your answer. Generally, I think my code is correct at that point. But I'm still a mere mortal and acknowledge I sometimes make mistakes so I look for the SSCCE to call that out. Implied behind the OP's question is that a measure of debugging has already taken place. My first assumption is usually that my code is wrong, and so I debug. But once I get to the point of where the OP is in this question, I start creating an SSCCE.
    – user53019
    Commented Nov 6, 2015 at 20:59
  • @GlenH7, I see, I read the OP as not being that far along. Commented Nov 6, 2015 at 21:15

I'm sorry to say this, but there is no magic bullet.

There is no way in general to easily tell whether:

  1. You have a bug in your code.
  2. You misunderstand what third-party code is supposed to do.
  3. Third-party code is doing the wrong thing.

The only solution is to improve your knowledge of javascript and get better at debugging.

  • Indeed, when being "not confident in my JS skills", using a "relatively young Javascript framework" is contraindicated. If you're using a library as an alternative to understanding your world, pick one that is mature. Commented Dec 23, 2015 at 13:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.