Much of my work consists of trying to communicate what DH is, how it can be useful, and how the library and other campus partners can help people get started. Contrary to this excellent reflection by Matthew Lincoln, I find that tools can be a constructive way to spark engagement with DH. On a good day, when I talk about a tool it includes not just the results of the tool, but also extends to how the tool was made, who made it, why they made it, its disciplinary heritage, and analytic errors to avoid when first testing the waters (h/t Jennifer Vinopal, Scott Weingart, Ben Schmidt).
A tool based approach to introducing DH is in line with a recognition that some people become interested enough in a thing to explore it further via different paths. Some might choose to become acquainted with Network Analysis through a text, learning the theories, principles, and so forth before trying to bring it into conversation with a research agenda. Others might prefer to come to Network Analysis by looking at a finished product that intrigues them, focusing on the “how did they make that?” question before delving into underlying theories and the technical competencies they need to develop.
This approach favors presentation of results first and the tools that made them possible. These results might be wrong. Their initial interpretation could be somewhere out in left field. However, whatever grist they are able to add to the interpretation mill may spark enough interest and curiosity in DH to commit hard fought time and attention resources to venturing down the rabbit hole – a journey which requires critical engagement with the literature that gave birth to the tool, the methods employed, the tool itself, and interpretation of results.
I make no claim that a tool based approach is best, its just another route that wends its way toward the same goal – the critical literacy, fluency, and mastery needed to do DH well.