My biggest advice to people getting into devtools: focus on tasks, not tools. Task model: what is a programmer trying to do? eg read, write, debug, find, document Process model: how are they doing it? eg grep, google, whiteboard, coworkers *Then* ask where a tool can fit.
-
-
"For a major task, programmers may need to switch among a number of comprehension strategies. Unfortunately, tool designers may only have an intuitive notion of what features are beneficial. A tool may impose strategies that are unsuitable because of the program, task, or user."
Show this thread -
Storey et al. "How do program understanding tools affect how programmers understand programs?"
Show this thread -
"Most automated debugging techniques have yet to demonstrate their practical effectiveness. One common limitation of existing approaches, for instance, is their reliance on a set of strong assumptions on how developers behave when debugging."
Show this thread -
Parnin and Orso, "Are Automated Debugging Techniques Actually Helping Programmers?"
Show this thread -
The history of devtools is a graveyard of tech-centered ideas. We would do well not to repeat those mistakes.
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
cognitive psychology. PhD