From 54385320c1d45b742420f421e87664abfd333720 Mon Sep 17 00:00:00 2001 From: Isaac Slavitt Date: Sat, 23 Apr 2016 16:41:01 -0400 Subject: [PATCH] Fix typo --- docs/docs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/index.md b/docs/docs/index.md index aa9720d..6bbd02a 100644 --- a/docs/docs/index.md +++ b/docs/docs/index.md @@ -4,7 +4,7 @@ _A logical, reasonably standardized, but flexible project structure for doing an ## Why use this project structure? -We often think of data analysis as just the resulting report, insights, or visualizations. Even though these end products are generated by code, it's easy to focus on making the products _look nice_ and ignore the _quality of the code that generates them_. While these end products are generally the main event, **code quality is still important**! And we're not talking about bikeshedding the aesthetics or pedantic formatting standards — it's ultimately about correctness and reprodcibility. +We often think of data analysis as just the resulting report, insights, or visualizations. Even though these end products are generated by code, it's easy to focus on making the products _look nice_ and ignore the _quality of the code that generates them_. While these end products are generally the main event, **code quality is still important**! And we're not talking about bikeshedding the aesthetics or pedantic formatting standards — it's ultimately about correctness and reproducibility. It's no secret that good analyses are often the result of very scattershot and serendipitous explorations, tentative experiments, and rapidly testing what works and what doesn't. That is all part of the process for getting to the good stuff, and there is no magic bullet to turn data exploration into a simple, linear progression. That being said, once started it is not a process that lends itself to thinking carefully about the structure of your code or project layout.