Aspirations

I've spent a lot of time recently kind of floundering. I have projects that I work on, but as a solo dev, I think I'm aiming too high to start. There's a lot of merit in just focusing on creative volume, rather than trying to make something perfect the first time. You never really know what your requirements are until people are using something anyway.

Thinking about the future, I think the expansion of automation is inevitable, and the question is how to do it better. I think a lot of this will come down to making sense of huge data sets to drive better decision making, and that means analytics, and new ways of interacting with data. It probably also means new data visualizations.

I've written before, a little bit, about speed cubing, and breaking it down and focusing on specific steps to continue to make progress, but I didn't go into any real detail.

In a nutshell, there are a few well established methods for solving a cube that are all some variation of progressively solving some subset of the cube, while leaving previous work intact. You start out with a high degree of freedom, and it's gradually constrained, with distinct phases, or steps.

The steps basically have a precondition and a postcondition, and each step deals just with a subset of the pieces on the cube, and that allows them to be practiced in isolation.

Given a precondition, there are a finite number of cases to deal with to progress to the postcondition. Practice generally consists of some partially random scramble version of the precondition, and getting to post, optimizing for speed, or movement efficiency or something.

Figuring out how to practice is generally much more straightforward than figuring out what to practice.

Figuring out what to practice, I think, is a common problem to any kind of learning. If you have a mentor, a very large part of what they'll do for you is just identify what you need to work on at any given moment.

Once you know what to do, actually doing it usually isn't that bad. Conversely, having to make a decision about what to do when you don't have enough information can be paralyzing and stressful. It's incredibly easy to waste your time working on things that don't lead to progress.

In speed cubing, this generally looks like just doing full solves, over and over. You don't know what to practice, so you just practice everything, superficially. This is akin to a dancer expending their energy doing every routine they know, when what they need is to drill arabesques, or just stretch more.

You'll make progress to a point, but will likely plateau early.

Not everyone has access to a mentor. And not every mentor has the experience to correctly identify what's holding you back.

I'd love to learn more about how to do this better, and to make guidance more accessible to anyone who'd like it. I think this is more easily automated than is intuitive.

In speed cubing, it's common practice to use a timer to check your progress (i.e. decreased solve time equals progress). Most people just time their full solves, but more granular timing can make your data yield more insight.

e.g. If I know that the fastest people who use my method spend 25% of their time on a given step, and I spend 50% of my time on that step, it's a clear sign that drilling all or some part of that step might give me my greatest gains.

Conversely, if I do a step in roughly the same absolute time as people who solve twice as fast as I do, I know that drilling that step will likely be a relative waste of my practice time.

The problem is, I have to know the timing splits of people who are faster than me, and my own timing splits. Ideally, I'd like to know what these are like for everyone.

If I had this data, practice could be almost entirely mechanical and devoid of doubt and fretting over making bad decisions about how I'm allocating practice time. I'd be a progress machine.

I've got a pet project that addresses this, and I've been working on getting good with D3 to help make the data easier to parse and make decisions with.

Making D3 play nice with Ember is a little tricky. Sometimes I think I'm overthinking how to divide up the responsibility. SVG can be templated, or just generated entirely in JS. Mike Bostock has made a bazillion D3 examples, which are incredibly useful to showcase how different parts of D3 can be used, but the code is kind of inherently ugly, in the way that JS of yesteryear (i.e. endless JQuery callbacks and whatnot) was ugly. Once you're beyond the simplest of graphs and interactivity, keeping your code organized can be a nightmare.

This is a problem worth solving, though. Netflix is working on some cool stuff with ember-nf-graph. The docs were a bit lacking when I tried to use it initially. I should probably pitch in more there, but I need to get a little better with naked D3 first, I think, before I can really contribute.

My last post, I said I was committing to posting weekly, and I think that was a Monday, and this is a Friday 11 days later. I wasn't really specific about if I meant like the week of whatever, or up to 7 days apart. I think week of whatever works better for me, in that I tend to want to write about a lot of topics at once, but frequently will go 7 days without feeling compelled to discuss anything in particular.

So let's go with that.