Category: Code

Working Remotely and Tangible Craft

Before I started working at Automattic (the folks behind WordPress.com and the Jetpack WordPress platform), I had a career in what I call progressive coffee: high end coffee, well made, ethically sourced, that kind of thing.

(I’ve written a little about my journey from a hospitality job to a job with a tech company here and here, if you’re curious about that)

While I was working at Seven Stars Bakery in Providence, Rhode Island, our biggest day of the week was Saturday, especially Saturday morning. One part of my job there was designing the layout of the employee space, as well as building and improving the training programs. Spending my Saturday mornings at the busiest location on the busiest day was a great way to ensure that my work was successful, and was adding value to the company and customers when the rubber hit the road.

During one of these shifts, I’d typically clock in 14,000+ steps: it is borderline insane to think about, now, when I struggle to get in 10,000 steps in a whole day!

Preparing really excellent espresso, tasting coffee to decide what to bring on as an offering: these are inherently and importantly physical and sensorial activities: awareness of the body and what it’s telling you is part and parcel of finding success in these pursuits. You have to not just heat the milk, you have to listen, to watch it, to gauge the temperature of the pitcher against your hand. You spend a lot of time focused on and attending to your sense inputs, using your body and its inputs in increasingly focused and demanding ways.

The combination of focused precise work (which being a quality-focused barista in a busy espresso bar absolutely is) with 14,000 steps meant that the days were cognitively and physically exhausting.

Moving away from this career into what I do now, working for a software company, and more specifically working fully remotely, was a real shift. It was a real change, in some ways I expected (I didn’t have to work on Saturdays anymore!) and in some ways I did not expect.

One of the unexpected changes was that I found I was attracted to hobbies that were much more manual: gardening at first, and more recently woodworking.

Over time I’ve come to realize that the part of me that is fulfilled by building things and planting vegetables is the same part of me that was fulfilled by those busy Saturdays: there’s a value to using the body, to getting to know what your body can do and how many amazing things you can teach it to accomplish.

Part of it, too, is that manual pursuits, physical crafts, impose humility on the practitioner: you cannot Google how to cut a perfect dovetail.

Well, that’s not true – you can Google it, and get lots of results! But, you can’t Google how to actually do it, like Neo in the Matrix. Once the saw hits the lumber, the truth comes out. There is no quick route: if you want to make beautiful things out of wood, you have to spend a lot of time making pretty ugly stuff first.

You simply have to put the miles on: there aren’t any shortcuts.

(This is also true for another new pursuit of mine – Brazilian Jiu Jitsu, but you’d have to substitute “make ugly stuff” to “get choked out by strangers” – different but the same!)

Like everything, becoming someone who works with code means re-learning everything I’ve known to be true again, in a new pursuit. I realized and came to appreciate the need for exposure, for time with my saws and chisels and on the mats – and at the outset it seemed so different from writing code. Coding, for the beginner, many times does feel like there are short cuts, with Stack Exchange, with other folks’ code or libraries, etc.

It turns out that what all those folks on Stack Exchange have been saying all this time (but are mostly ignored) is true: copy-pasting a solution that works is different from understanding the problem, from getting a deep sense of the solution and how to pursue it. It’s like buying someone else’s chest of drawers rather than building it yourself. It’s different from having the answer in your bones.

The more I learn, the more I learn that everything is the same. For me, I’ve learned that remote work is an amazing way to work, and writing software and doing data work is special, and important, and so satisfying: but the brain and the body, or my brain and body at least, really need that opportunity to do work in the physical space, to hold something, to engage in craft that doesn’t happen on my laptop screen.

If you are a remote worker, and you don’t have a hobby or pursuit that takes you off of your computer and into the garage or the gym – you should give it a try!

Pies and Waffles: Delicious Charts

I’m trying to catch up on my massive Pocket back scroll, and in surveying the massive and diverse landscape of its contents, noticed a few pieces all from the same site,  eagereyes, and all on the same topic, pie charts.

So, naturally, I read them. 

(As a sidebar, am I the only person who struggles with this with Pocket, or other content saving services? Am I coining the term “Pocket Zero” right now? Am I the next Merlin Mann? )

Here are the pieces – they’re all quite short, less than ten minutes reading, even if you do take in the discussion with Hadley Wickham in the comments section:

A Pair of Pie Chart Papers
Ye Olde Pie Chart Debate
Pie Charts
One thing I was surprised to learn was just how long the Great Pie Chart Debate has been going on – over a hundred years! And yet,  the pie chart lives on. 

It’s also interesting to me that,  despite their ubiquity in popular media, we don’t have a great sense of how or why we perceive pie charts the way we do – it makes me consider firing up the Doc’s eye tracker, just to see how eye patterns map onto different visualizations.

In this series of posts I was also introduced to the Waffle package for R, which makes it easy to put together a pie chart alternative which I quite like – like this:

It strikes me as easier than a pie chart to compare each of the pieces to one another, and indicates that each point is part of a continuous whole in the same sort of way that a pie chart does. 

I’m excited to play around with this package some in the coming days. I’ll have to dig a bit and see if it’s supported in Shiny yet!
 

STILL Visualizing the Support Driven Survey

I have been away from the blog for a bit – during the time I normally spend blogging and thinking about blogging, I’ve been spending trying to get to know a new tool for my R toolbox, a web app platform for R called Shiny.

Those of you who have been around for a while are familiar with my bizarre love of the intersection of information and design that data visualization represents, especially given that I am neither a statistician nor an artist.

(The heart wants what the heart wants!)

As demonstrated previously on this blog, I learn best by doing (hence my 30 day visualization sprint wherein I took a dive into the R library ggplot2) – so after going through the Shiny tutorial, I gave it a try, and pushed live my first ever web app, a super rudimentary user-adjustable visualization of the recent Support Driven compensation survey.

So, here’s a link. Check it out. I would genuinely and with a full heart appreciate your feedback. 

Munging NASA’s Open Meteor Data

Munging NASA’s Open Meteor Data

In snooping around the US Government’s open data sets a few months back, I found out that NASA has an entire web site dedicated to their publicly available data: https://data.nasa.gov/

Surely, you understand why that would excite me!

I dug around a bit and pulled out some information on meteor landings in the United States, with tons of information, mass, date, lots of stuff.

To simplify the data set and make things tidy for R, I wrote a quick Python script to strip out some columns and clean up the dates. Here’s the gist if you want to have a go at the data as well.

I ended up looking to see if there was a trend between date and meteor mass, to see if maybe there were obvious cycles or other interesting stuff, but some super-massive meteors ended up shoving the data into pretty uninteresting visualizations, which is too bad.

We can do some simpler stuff, even with some super-massive meteors. For instance, here’s a log(mass) histogram of all of the meteors:

Screen Shot 2016-01-05 at 7.49.24 PM.png

Check it out! It results in a somewhat normal, slightly right-skewed distribution. That means we can use inferential statistics on it, although I am not sure why you would want to! The R code is a super quick ggplot2 script.

It’s pretty amazing how easily we can access so, so much information. The trouble is figuring out how to use it in an actionable and simply explained way. The above histogram is accurate, and looks pretty (steelblue, the preferred default color of data folks everywhere), but it isn’t actually helpful in any way.

Just because we can transform a dense .csv into a readable chart doesn’t mean it’s going to be useful.