Friday, July 18, 2008

"How do you know all this stuff?"

Disclaimer: I'm not here to toot my own horn, my intention is to make this post an introspective analysis.

A couple of days ago a coworker came to me asking me for some advice on a javascript related problem he was having. He said he "had been beating his head against the keyboard for the whole afternoon" on a issue where calling Element.scrollIntoView() on a <div> with overflow:scroll caused the entire document to scroll as well as the intended div, causing the whole page to "jump" awkwardly.

After listening to him describing the problem, I almost instinctively suggested to save document.body.scrollTop, call the function and then reassign the saved value back to document.body.scrollTop. I noted that there is also the little quirk of having to sniff between document.body and document.documentElement, and once that was ironed out, the code worked beautifully.

I've had this same developer asking me other fairly hairy questions before, and somehow I actually knew how to solve his problems, often by just looking at the page. This last time, he just expressed how impressed he was with how promptly I could come up with working solutions to problems and asked me the question: "how do you know all of this stuff?"

Indeed, where the hell did I learn about all of that stuff?

I wished I could have given a short insightful answer that would genuinely help him improve his skills, but I couldn't. I ended up just saying that I read a lot, all the time, from a lot of different sources. But something about that question made me think: I can't possibly know how fix incredibly strange and unintuitive bugs just from reading random articles (most of which aren't even about bugs), can I?

On one hand, yes, a large class of problems can indeed be fixed quickly, if one takes 2 seconds to do a google search for them. But on the other hand, there are bugs that are extremely application-specific, for which a google search would do no good.

Once, I came accross an incomprehensible bug (an element would redraw strangely after an Ajax call), and the solution I came up with was equally quirky, involving assigning a DOM element property to itself (i.e. element.innerHTML = element.innerHTML). What drove me to think "well innerHTML is ultimately handled as a setter, so there must be an internal redraw call within the browser native code, and maybe I can force it the underlying function to kick in correctly by calling it this way."? I don't really know.

But I think that the ability to think of completely non-intuitive ideas that can ultimately serve a purpose is something that a lot of people possess. Good quality assurance professionals are constantly thinking about new "what ifs", and the whole infosec research industry revolves around the ability to look at what everyone looks at and see what no one has seen before.

Bruce Schneier often speaks of this so called "hacker mindset", and according to him, it's supposedly a hard skill to develop. I don't have a degree in psychology or pedagogy, so I wouldn't really know if that's really the case, but I do wish sometimes that the abiliy to think critically was easily teachable, because I think it helps in many aspects of life, not just programming.

Digressing a bit

Anyways, at least as far as front end web development goes, I think there are a few ideas that can help one become better at problem solving:

  • Maintain codebases on an ongoing basis: fixing those nasty bugs oughta teach you something :)
  • Read source code: javascript library authors have already gone through the trouble of testing for browser inconsistencies and bugs, and their code reflects that experience. Reading their code not only gives more insight into how the underlying DOM works but also reveal obscure gems in the libraries themselves.
  • Programming is a hobby too: spend some time working on your own project. Try a new language. Contracts. Macros. Annotations. AOP. Static. Dynamic. Porting. Bindings. Plugins. There's a lot of cool stuff out there.
  • Read about crazy mashups and unorthodox ideas: they often use little-known browser features that may be useful to you someday. Don't be shy to delve into the code.
  • Listen to Confucius: he said "choose a job you love and you'll never work a day in your life". You can see bugs as challenges just waiting to be defeated, or you can dread them and curse them forever. Zen aside, I think it's very hard to get distracted or lose interest when there's something you're itching to dive head first. If fixing javascript bugs is not your thing, maybe you'll be happier working on back-end stuff with static typed languages. Know your enemy and know thyself. (ok I'm done with chinese quotes)
  • Sleep: I kid you not. Letting your head rest helps your brain re-organize ideas and create new correlations between concepts.

Damn, that's a lot of work

Unfortunately, I don't have a simpler formula, but hopefully this is helpful or inspiring to someone.

1 comment:

  1. I like the sleeping part ;)
    In all honesty though, sleep and rest is a very important part to being a good programmer. If you don't take time off now and then to recuperate, you'll either burn out, or just sit there staring at the screen not being able to figure out what to do.