It's Always Something Stupid
One thing that really grinds my gears from time to time is the way others, even myself sometimes, tend to assume the worst whenever the slightest thing goes wrong. This is especially true as deadlines approach. Oftentimes the reaction to the issue is proportional to the resulting effect of the problem. If the effect of a bug is that the whole entire app stops working, people start losing their minds. One line change and a commit later and then everything is normal again. I started thinking about why I have to deal with this so often when I realized that, as usual, it's just one of those human responses that we need to train ourselves not to do.
I was working on a project recently with a team of great developers. We split the project up with half the team working on the back-end API and the other half working on the front-end application that would talk to the API. In the beginning things were quiet because each half of the team was busy making architectural decisions and reasoning through various implementation details as the foundation of both halves of the application began to come together. Eventually however, there came a time when the back-end was pretty much finished for the first iteration and the front-end had to build on that.
Once the back-end API was mostly finished our team was brought back together and the API guys got to learn more about our client-side codebase. Of course, as developers do, they had opinions about some of the choices we made. One of those choices was a decision to use AngularJS. I'm not one of those developers who gets out his pitchfork over silly debates about which of two "competing" frameworks is better; the only reason we went with this choice early on is because the entire team knew the Angular framework well enough that we could just hit the ground running and start using it.
As I'm sure you can guess, some guys on the back-end half of our team prefer to use another framework. I won't bring it up here just to avoid the inevitable framework war in the comments (however ironic that would be). As our deadline came closer our whole team started feeling the pressure, which seems to be pretty standard no matter how well done a project is as the deadline approaches. One day someone opens up Safari and starts testing the app. I hadn't done too much Safari testing up to that point, but I did enough to know that our app was at least working with no obvious issues until at least the week prior.
When someone brought up that Safari had "major performance issues" with our app I immediately knew that something had to have changed. Either Safari got an update and we were stepping on some weird edge case it introduced, or someone changed code in our app. Here is where I get really frustrated. This situation seems to be common occurance and has become a huge pet peeve of mine, though I don't quite know how to mitigate it. You would think the reasonable response to "Something is wrong and we have no idea what." would be "Okay, what else can we do to try and narrow it down?" Instead what I often see is people getting upset, oftentimes even throwing a mini fit. They get so caught up in emotion that they immediately spew the worst or first "conclusion" (usually the same thing) they can come up with.
In this particular case it took all of a few posts in our team chat before AngularJS was thrown on the table as a possible explanation for slowness in Safari. It didn't help that this was accompanied by irrational generalizations like "the whole app should be refactored." Normally I just bite my tongue and quietly mutter to myself in annoyance, but this time I couldn't help myself and called them on their alarmism. I hadn't even debugged the issue myself yet but I already knew it was going to be something stupid. I worked two hours longer than I normally would that day just to squelch the exaggerated cries as quickly as possible.
Despite the fact that literally thousands of Angular-powered apps in production on the web target Safari just fine, I still felt the need to prove just how solvable this supposedly fundamentally-unsolvable-bug-because-Angular-is-the-worst-ever actually was. Sure enough, when I finally found what was causing Safari to completely lock up, fail to show data, and even crash, it was (drum roll please) something stupid.
http://codepen.io/Chevex/pen/PqXoGb
I can't embed the above demo or else this very page would suffer the same performance affliction as our project. As of this writing if you open that link up in the latest Safari on OS X your browser tab will completely freeze. If you wait long enough it becomes sort of usable but with extreme lag. It even lags a bit here in Chrome when I try to highlight text, but not bad enough to be obvious. The issue seems to be a combination of a simple CSS3 text-shadow with a 500px width being applied to some uncommonly styled elements with transforms to make the boxes look slanted. I removed the text-shadows from the offending page and imported some pre-made SVG elements our design team put together and then everything was fine.
What annoys me isn't that they couldn't fix the bug right away, it's that when they couldn't fix the bug they just threw their hands in the air, got upset, and blamed the whole app for being crap. That reaction accomplishes absolutely nothing constructive whatsoever. The individuals jumping to conclusions remain upset because when they're done crying nothing has changed. The individuals whose code they're blanketing with vague generalizations just get a sour taste in their mouths about both the project and the team in general. The domain experts who also happen to be in the same chat channel see nothing but a petty war and finger pointing about some huge sky-is-falling issue that actually isn't that big of an issue. Everyone loses. I really admire and respect the guys on my team, which only makes it sting that much worse when they start exhibiting that kind of behavior. This knee-jerk reaction is most certainly not unique to my team. This is a behavior I have seen time and time again at literally every single corporate programming job I've had. I myself have demonstrated this behavior several times. I think I've matured a bit since the last time I acted like that. Running your own business and having clients rip out your soul on a semi-regular basis helps to toughen one up a little.
After everyone was done throwing their hands in the air and moved onto other things I was able to sit down and start debugging the old-fashioned way. With git bisect and the tried and true comment it out until it works again method, I was able to resolve the issue in a couple of hours. Of course after I fixed the issue the group chat mysteriously forgot about the entire thing and went back to business as usual. I've been thinking about this all day and I've concluded that there really isn't anything I can do to stop this from happening except to try my hardest not to be that way myself and lead by example. I've already been complimented by a couple of my colleagues for my level-headed nature so I'll take that as evidence that I'm doing something right this time around :)
In conclusion I think it's important that we all remember, it's almost always something stupid. Even if that stupid thing is bringing down the entire server, freaking out isn't going to fix it any faster. Try to remain calm, even while everyone around you is bursting blood vessels, and before you know it you'll be the one that fixed the thing that supposedly couldn't be fixed without sacrificing your first born.