An unanticipated deadline has kept me from posting the assignment I wanted to give to you this week — so we’ll have to make it up next week. However, if you have some time before class on Thursday, consider the following (not-required) exercise:
If you have time between now and Thursday AM (15 February), this is my challenge to you, with respect to our class in Digital Research Methods and doing data science: Do something that strikes you as interesting or meaningful: Learn a new technique for capturing data; experiment with different versions of a specific function or command. Download and install a different text editor and force yourself to learn a dozen keyboard commands. Go to Github.com and search for snippets of Python code that seem promising to you.
Set out to answer a question that you’ve had about Python for weeks now. “I don’t understand the idea of a “for/in” loop in Python,” you say. So find a few examples online, sit down in front of Jupyter for half an hour, and experiment. Give yourself permission to indulge in evidence-based learning: Start in a blank notebook with an hypothesis about, say, how variables work in Python. Try to disprove that hypothesis, try to break it. Broken? Now put it back together, better this time.
Play with a strange new library just to see what it does. Force yourself to work in Jupyter with one single function until you come to understand it completely and intuitively.
Now this part is *crucial*: **You must, in some small way, document what you have done.** Make a point of learning publicly. Jupyter is perfect for this. I’ve included an imperfect, quickly-built sample, just have a look (note that I’d need to clean it up before I shared it with anyone). If you have the opportunity to experiment with this idea, try to make your effort 50% personal journal (a real, if simplified, record of your self-education) and 50% performative learning (this is what it looks like when I learn; this is the nature of my thought).
SO: Why do this? Here’s my thought: The engineering sciences (and Computer Science) have long been notorious for thinking in chiefly problem-based terms (that is why the advertising industry has been obsessed with the word “solutions” for 30 years now).
If you ask a software engineer a question, there’s a good chance that she is trained to see that question as a problem, and so she’ll define it thus and then move to solve it. OK: That isn’t necessarily a bad thing. But it can be reductive, and limiting, and overly simplistic — even if it is the most “efficient” approach.
Engineers are not (typically) interested in process, only in outcome. If we’re going to have to live with code and data all our lives, I think we’re well-served to see value in process, too. I like the idea of modeling our imperfect, idiosyncratic processes of learning because it suggests that it isn’t just engineers who should be using Python to think. Other people — opera singers and dog walkers and house painters — should do so, too.