Most people seem to think of debugging only as finding and fixing unexpected behavior in finished software projects, but it is actually a big part of the development process itself: When I implement a new feature, I normally use the following pattern:

* Make a mental model of what I want to accomplish (e.g. "add payment form to the web app")

* Split that into individual chunks of work (e.g. "create the web form and have it accept the data")

* Write a chunk of code and see its effect on the software

* Find unexpected behavior (i.e. "debug" the feature)

* Fix the unexpected behavior to match the desired one

Ideally, the loop above is not performed once for an the entire feature but many times on tiny, individual parts of it (writing tests for each small step is even better). By this definition I probably spend 50 % of my time "debugging" code, if not more.

Debugging is also the most important skill that I try to teach to other programmers when onboarding them into a team. Why? Because a programmer that is effective at debugging will save himself/herself and everyone else on the team an incredible amount of time. Developers that aren't able to efficiently debug problems themselves will get stuck frequently, which means that someone else on the team has to "unblock" them by doing the debugging for them. In that case, the "debugger" will usually be a more experienced team member, which means your team will waste not only the time of the inexperienced developer, but also that of the experienced one. I believe this is the main reason that adding another programmer to a large team can actually slow progress down rather than accelerating it.

On the other hand it's of course the responsibility of the experienced developers and the team lead to make sure that only a minimum amount of (unexpected) debugging is required to begin with. In practice this means having (among other things) strict development guidelines, software tests, a continuous integration system, very good documentation and a thorough code review process.

Also, I might be saying nonsense here but I think the reason that people from Physics or other STEM fields are usually very good programmers is that they are thaught a lot of "debugging" skills during their training, especially in experimental fields.

I believe this is true, at least for myself, if you limit the STEM to Science, but I'll note it starts with your first bullet point, "Make a mental model". Here's a pretty good (top Google "process of science") diagram and description of the The Scientific Process: http://www2.nau.edu/~gaud/bio372/class/behavior/sciproc.htm and you can see how pretty much every part of it has direct utility in the mechanics of software development.

I'm weaseling with "the mechanics" because software development almost always involves a lot more direct, unscripted, and frequent interaction with other people. By comparison, what happens in science can be a lot more constrained, with the closest part of that sort of thing being funding. You also need to keep the people who you're delivering your results to happy, be they scientific journals or superiors and peers who need them for more direct uses, and having a working relationship with those under you, which for a PI could be postdocs, grad and undergrad students, and lab techs. And depending on the field the usual bureaucracy regulating what you do.

The mentoring model is almost infinitely stronger in science. When you're an undergrad, you get mentored by your grad student TAs, and if your smart, you spend at least a little time your favorite professors (in the best cases, they get free or much cheaper labor, potentially on high risk and/or apparently low gain work). In my personal experience, if you don't waste their time, Nobelists are at minimum happy to provide a little advice in passing.

The grad students both mentor the undergrads and are mentored by their PI and his more experienced postdocs and grad students, it's an apprenticeship model. Once you have your Ph.D., there's still a good chance you'll do, or should so, some mentoring in whatever lab you end up in, industrial or academic. In the academic track you'll be expected to formally teach classes, and good schools will demand adequate performance. If a PI, you cultivate your crew of lab techs, students, and postdocs. Personal reputation is also more generally important, especially lower down.

(Note that I've seen these positive behaviors at 3 levels of academic institutions, the low end one level above community college 4 year college where the professors are there to teach, a highest end "R1" university, and a middling "high research activity" university.)

Hmmm, there's also a lot of gatekeeping in science which isn't present in our field. It's legendary how many "college dropouts" for whatever reason ($$$ in mine) go on to be successful, whereas it probably isn't easy to become a bottom of the totem pole lab tech without an undergraduate degree. Which is the gateway to grad school and the Ph.D. where you can become more independent, and doing that in the American model requires passing quals, doing original research and defending that. There are of course exceptions to the typical path, but they're a lot more unusual.

http://stackoverflow.com/a/1268464/59087

Its pretty awesome https://github.com/node-inspector/node-inspector

Does he means he only uses JS for scripting CSS and producing information?

And i kind of feel similar. I spend most of my time coding the actual app, making tests, etc... Less than 10% of it is just taking data from the dom, and putting it back in.

(this is all for web-app style things instead of your average website)