I've been on a pretty decent roll the past couple of days. I got to compile a lot of resources on visualization, and also experienced a bit of a realization about how to and how not to learn things. Today, I began to revert to old patterns (not habits; they're larger in scale than habits) because of two main things:
- I went to sleep pretty late, and needed to take Marlon in the morning
- I took a rest during the day
The weird thing about this was that I wasn't even planning on doing any visualization/data science learning today. I was supposed to focus on house renovations that have been dragging on.
Being sleep deprived always makes sticking to the plan sort of worrisome. When I got home, before taking my nap, I started reading the Structure and Interpretation of Computer Programs! I've been meaning to start learning for a while (and actually created a Trello board to keep my place in the lessons) but started reading because I was thinking about functional programming in R.
While I think this is a pretty worthwhile study, I don't think going through SICP or learning Lisp should be my focus. SICP confers a lot of cred for programmers, but at the same time the hardcore stop-and-think nature of the material threatens to stop me in my tracks on any particular day that I don't have a ton of energy. I was actually having a good time reading it on my phone, but when I started trying stuff out in the REPL, I began to see that the tiredness was affecting my lack of focus.
Then, I decided to go ahead and take a rest, to recover my focus and energy. Was that the right move? Should I have switched to doing the bathroom (a task that doesn't require a ton of concentration) instead? I'm still not sure, so let's think this out: ideally, I'd like to make sure I'm getting to sleep on time, which didn't happen. What do I do on days where I'm lacking sleep?
I think that, in the future, a shorter nap and some tea would have sufficed. The habit I'd like to set is revisiting what I had planned for the day. If I'd remembered that I'd planned on doing renovations before getting so caught up in SICP, I think it would have been easier for me to negotiate a strategy earlier on.
Switching to renovations is a pretty difficult calling. I'm pretty eager to learn as much as possible as soon as possible with data visualization. Doing house renovations doesn't bring me any closer to getting a job or contributing to finances. At the same time, the time spent on the work is certainly commutative--the bathroom needs to be done whether I do it now or later. And the effect of having the bathroom done would probably be better than having it hanging while I try to get into learning.
So, there we go. As it stands, it's usually better for me to stick to the regular housework days.
I have to keep telling myself that things will be okay, one way or another. The choices I can make can lead to better or worse outcomes, certainly, but things will be okay in some way even if I make the best choices I can but things don't turn out all that great. It might not be all that great, but it will be okay.
A lot of my "push" style motivation comes from the desire for things not to be a certain way within a certain amount of time. I don't want to be living with my parents several years from now, for instance. Ideally, I don't want to be living here come 2016, as much as I like being close to Marlon and Bryce when he comes home. I'd like to have work prospects before my 31st birthday.
Still, I had a good many similar sentiments last year, and the year before. Although I'd learned as early as 2009 that, "What pushes you forward holds you back" (PJ Eby), the natural way to formulate my aspirations is something along the lines of, "I want to leave this stuff behind". And sometimes that translates into a particular timeframe: "By this time next year, I promise that I will have left these crappy things behind". It sounds pretty good. Saying things that way is specific. It's measurable. It's very time-bound. But is it achievable? Is it realistic?
I even feel that's a bit of a distraction. I don't really like the SMART framework for setting goals anymore--it doesn't result in very good defaults. Instead, goals that I set based on my AJATT experience, or experience derailing on Beeminder are much better. What does that look like? It means looking at what you can do now in the context of the bigger picture.
Here's a nice quote from Mike Bostock, in reply to a Reddit AMA question:
I recommend patience. To become proficient, you will need to master multiple skills: data collection and cleaning, quantitative analysis, visualization design, programming, web development, etc. It’s tempting to want to learn all of these things and do something amazing in a very short time frame—like, say, during a hackathon—but really the best approach is to be diligent and methodical. Keep practicing, keep tinkering with smaller problems, and you will gradually improve. [...] the best thing you can do is to think of small coding problems that you are comfortable solving, and then increasingly ramp up to larger problems as you go. The satisfaction you derive from solving the smaller problems will motivate you to keep going.
In other words, you can have a larger-context goal, like learning to make useful and insightful graphics in D3--and getting a job doing that. But the basis of that is the really specific success spiral.
I think there's probably something like an increasing nonlinear complexity to nailing down specifics of a large solo project where you have to learn along the way. Setting down some specifics can certainly get you moving, and inspire you. If things suck for you now, setting down some specifics to your goal in the future can make you feel like you have more hope, and more control over the future. But when thinking about it, you can really fool yourself about the amount and loci of control. How much control do you have about how long a certain learning process takes?
I think setting goals is actually quite a bit like the data analysis process--there's a requirement for exploration and iteration as you refine your course.
Or maybe it's just me. Maybe if NASA sat down and crafted a data science/visualization study regime for me to follow, there would be very little uncertainty. And I guess if I gave myself six years, I could make it more certain that I'd learn this stuff--say, if I were in a PhD program, instead of a once dropped-out student trying to pick this up on his own so someone will pay him for it.
Mike Bostock's quote relates to what Josh Kaufman reminded me about. Here's a bit from his article, "Status Malfunction":
Here’s a different way of thinking about skill: independent of status, picking up a new skill is always a win from a capability standpoint, since the skill opens up new options and opportunities. Some skill in an area is always better than no skill.
From a status perspective, being average is terrible, since it doesn’t differentiate you from others, and doesn’t improve how other people think about you in a meaningful way - if anything, being perceived as average decreases your status in the eyes of some people. From a capability perspective, being average is fantastic, since it lets you accomplish things you otherwise couldn’t do without that average level of skill.
That’s the thing: you can accomplish millions of valuable and meaningful things with skills that are mediocre in every way.
On the way to getting better, you are going to be worse than everyone at some point. Even after a lot of practice, you might still be pretty average. But many times, that doesn't matter as much as you'd like to think. You can still do useful things--and maybe some very useful things, with a combination of skills that might only be useful at best. And from there, you can always improve. Anyway, there's no getting to the expert level without being pretty mediocre.
So, while it may be more exciting to aim for something really impressive during a hackathon, Bostock is right--that has to come from the small things. Persistent practice, with fast feedback, is really the best for skill development. This fits with the framework Kaufman discusses in The First 20 Hours.
I've had to keep repeating these lessons from the past few days. When I go out looking for a job, I don't want to appear like a complete beginner, or just another one of semi-frauds calling themselves "data scientists". The concern that I'll get laughed at, or have nothing to show tends to grab at my attention as I look forward. If left unchecked, it'll affect what I learn and practice. Will I frustrate myself trying to pile on the most hardcore-sounding textbooks and programming frameworks in order to (eventually) show people I actually know what I'm doing? Or will I learn useful things bit by bit?
I also have to remind myself the biggest reason for doing this self study: this is work I can be passionate about. Whatever the hell the experts say, being excited about what I'm doing is the best strategy I have. I think the strings of stops and starts and shown that. Maybe excited is not a strong enough word--unless I can become obsessed about my line of work, there's a huge chance of falling off, of failing once again. Obsession can come from fear or fascination. I have great respect for people go work through dire situations. Yet I'd really prefer a good life--I choose fascination if I have the chance.
So, I've got to regard any kind of self study I'm doing for reassurance--which boils down to signaling--with suspicion. Do I need this? Or am I doing this for some vague sense of street cred?
I think the status malfunction deal also ties into the cultural overvaluing of virtuosity. It's rife in American culture, but probably also within some disciplines. I sympathize with the idea that some people deserve respect because of challenges they ran into during their process--all that up the hill in the snow, both ways sort of stuff.
But why undertake hardship that doesn't contribute significantly to your training, your experience, or the results of your work? If you're going to learn more doing things the hard way, that can be valuable. But if the difficulty of putting in that practice jeopardizes your enthusiasm for the whole project--and your consistent output--you have to make it easier. Take the easy way when you can!
My motto these days is, "Reject virtue! Be pragmatic!"