I just gave a talk at PyData NYC to an absolutely fantastic audience. I’ll write more about it later. If you’re looking for the slides, links, and books I recommended, they are here.
Based off the material in his book, we argued that it is easy to crunch some numbers and feel like you’re doing data science, but in the end to come up empty-handed since you didn’t pick the right problem in the first place. This is a particular danger since data scientists love data and programming and the latest tools, so it can be very tempting to just dive into the data set without first considering where you’ll end up.
We looked to the design world as a case study for how other disciplines have handled this very same problem, and propose that it’s not enough to be technically and mathematically competent. Effective data scientists must also be skilled at drawing out the actual need from underneath the stated need.
The second half of the talk, where we lay out a framework for structuring scope conversations, was drawn from previous talks Max has given. This iteration of the talk saw two new things. First, I added more justification and urgency around why you should care about doing this well. I imagine that everyone who chose to be in our session already believes this, but chances are extremely good that there are other people in their organization that are skeptical. Hopefully our arguments are portable enough that attendees can persuade their coworkers and managers.
The second thing I added were symptoms of scoping poorly. Just as it’s difficult to see that you’re in the Matrix when you’re in it, it’s difficult to know that you’re bad at scoping when you’re bad at it. The presentation has four red flags so you can spot weak scoping and have the language to address it. The nice thing about these is that once you give them a name, everyone on your team is more likely to spot them and call them out.
O’Reilly is working on the video and we are working on the annotated slides. I’ll update this post when they’re out. In the meantime, please enjoy this totally unrelated visualization of the most popular American names over time:
I spent most of the rest of the conference on the “hallway track” meeting new folks and catching up with colleagues from around the world. The sessions look awesome and I bookmarked a bunch of them to watch later. Literally too many to list right now. Will pare them down the list for the next post.
I should really have switched to vim ten years ago when I first started using the command line. But vim has a hell of a hill to get over, and I never made it high enough to keep going. I’m revisiting it because I love keyboard shortcuts! Once they’re in your brain, you hardly have to think to move the whole program around at a blazing speed. Then you get to feel like a wizard.
Starting August 1, I deleted my symlink to
subl and went cold turkey. It’s slowed me down pretty significantly, but that’s been a great incentive to set aside time every day to learn new vim stuff, and investing in the tools you use all day every day is always a great investment. I still feel pretty clumsy, but I now find myself editing non-code things in vim! Which is a good sign!
Resources I’m Using
I’ve been working my way through Practical Vim, which is great at getting you thinking in the vim way. I suspect this will make me effective much faster than just googling for things as they come up.
When I want to look something up on the fly, Google usually points me to the Vim tips wiki, which is encyclopedic for one-off solutions and quick fixes, even if they’re not well contextualized.
I’ve been pestering my colleagues, developer friends, and other Hacker School folks for their favorite config and tips and tricks, which has been very fruitful.
ALSO, I bought the domain thedailyvim.com, and am considering setting up a daily tips feed there. Send me a tweet if that’s something you’d be interested in!
I recently hit a bug with Blaggregator, a Django app I’m running in production on Heroku, and the fix needed each user to log out and then log back in for it to take effect.
So how to log out all users at once? A bunch of threads around the internet suggested deleting the Session table, as that stores all session information for users (that they are logged in, shopping cart info, etc). That’s easy enough with the
dbshell, but I’m hitting a weird psql bug on Heroku that I don’t have time to diagnose, and plus, working directly in the dbshell makes me feel icky. So here’s how to force all Django users to log out on your Heroku-backed app using the ORM, which is one layer of abstraction farther from shooting yourself in the foot.
Be careful since this can have adverse effects for your customers (remove items in a shopping cart, etc). It will also confuse and annoy visitors who are currently on your site. There are more graceful ways to accomplish this, but in my case it was quick and effective. I’m not storing anything important in the Session for Blaggregator, and the site has < 1,000 users as it’s constrained by the total size of the Hacker School alumni population. That’s a small enough number that none of them were on the site yesterday early morning when I was deploying. So this was a quick and dirty way to deploy the fix and make sure it was applied.
To get started, fire up the Heroku Django shell:
When you get the Django shell prompt (
>>>), then you can import the Session model. (If you want to go read the code, the module name tells you where to look: django.contrib.sessions.models looks in your virtualenv’s lib/python2.7/site-packages/django/contrib/sessions/ for models.py)
Now, you can iterate through all the Session objects and delete them. (caution!)
Or, as Jacob Kaplan-Moss pointed out, if you delete them straight from that queryset, you not only win at code golf, but the query will be faster due to how Querysets work under the hood:
See our Twitter conversation or the Django docs if you want more info on Querysets.
Congradulations! Your site is now very lonely.
I am not an early adopter.
Until last week, I was running 10.7. Yes, it’s true. Don’t judge. I had code to ship. No time for yak shaving!
But finally I bit the bullet. After dual redundant spatially-distributed backups, I ran the upgrade. And everything went great at the GUI level! And the Messages app is awesome! But Ruby, virtualenv, and Java were all borked. I don’t even Ruby, but I use Octopress and Heroku, so I couldn’t even blog or restart Hubot. Sadness!
Some tips in your upgrade:
Homebrew links will probably be messed up.
brew unlink fooand then
brew link foofixed most of these. Consider scripting it to save time and heartache! E.G.
for i in $( brew list ); do brew unlink $i; brew link $i; done
Ruby has a new version, and RVM is now using
.rvmrcto keep track of Ruby versions. It automatically moved these files around without telling me, which is half of what broke my blog.
Ruby 2.whatever will complain about Readlines or Yaml or OpenSSL depending on its mood. Try uninstalling Ruby with RVM, installing whatever it demands, and then reinstalling Ruby and seeing if it works. At this point, I’m basically thinking of Ruby as a demanding newborn that is astonishingly articulate about its needs.
Java is gone because reasons. Here’s how to reinstall it.
I’m still not sure what’s going on with my virtualenv but I think it has to do with my questionable decision to use a third-party Python distro. Passing in a path to the system Python with
-pseems to be a decent workaround.
A bunch of packages wouldn’t install through pip, and it turns out that the new default when flags are not recognized by gcc is to CATASTROPHICALLY CRASH rather than keep calm and carry on. Don’t have time for this drama? Add the following to your environment:
Back to work!
I had the pleasure of spending the weekend attending ORDCamp in Chicago. It’s an unconference bringing together a wide range of artists, founders, engineers, educators, writers, and even a couple of beekeepers. I learned so many things I expected to learn (cool new ideas, tools, and stories) but the overall Gestalt experience brought several unexpected realizations.
This is my fifth or sixth unconference. This format bring together people around some common philosophy or topic. Unlike a conference, there is no content set ahead of time. No confirmed talks, no pre-arranged speakers. The attendees construct the schedule together on the first night. This works way better than you’d think.
Session leaders are not necessarily even experts in their topic. It’s perfectly acceptable to just start a session around a question you have been pondering, creating a space for an interesting discussion. I ran a session called “Training Animals (and Humans) for Fun and Profit.” I’m not an animal trainer and I’ve never had a pet. A dog training book  changed the way I think about parenting, strengthening relationships, software user interfaces, and how to change my own habits. I wanted to share what I’d learned.
Sessions don’t have to even be about ideas. One of the more popular sessions was watching someone play the video game Spelunky. Others were more hands on. I’m particularly sad I missed Flaming Nunchucks, which was exactly what it sounds like.
One reason this format works so well is that it creates just enough structure. Organizers make sure social norms and expectations are clear, give advice on how best to navigate the experience, and then put the content squarely in the hands of the attendees. This works so well precisely because there is a void to fill. If you don’t step up and offer something interesting to the community it’s going to be a pretty boring day. It puts people in a contributor mindset, which changes everything.
At normal conferences, you can really phone it in. Sit in the back, half-listen to the sage on the stage, flip through Twitter, hang out with people you already know. But at well-run unconferences, opportunities to engage feel precious and fleeting. You want to attend every session and meet everyone.
At the intro session, organizers Fitz and Zach encouraged us to settle in, “carefully place your stuff precisely anywhere” and lay off the tweeting and posting to indulge in a weekend for ourselves. I left my laptop and phone in my bag the whole weekend. I knew it would help my focus, but I didn’t expect it to so radically improve my energy level. Instead of sliding into Twitter or email when I had a down moment, I had time to be thoughtful: to say hello, ask a question, get some water, or play Chopsticks on a musical Tesla coil. Twitter and email feel stimulating but are actually shallow and exhausting: aspartame for the mind.
When we felt the urge to check our phones, organizers and ORDCamp veterans enouraged us to see that as a sign to get up and leave the session we were in and explore others. Making it socially acceptable to say ‘no’ politely and find something that’s a better fit for you isn’t disrespectful. Quite the opposite: you get a better session, and the other folks in the room get engaged, excited partners. 
The other piece of unexpected advice came from ORDCamp veteran Bill. “Choose the session you’re least interested in.” I couldn’t resist the interesting sessions for the first few rounds, for the 5pm slot I chose The Art and Science of Smoking Pigs. I’m never going to have the space to do it myself, and how much could there possible be to say about pig roasting?
Moshe blew me away. He’s spent years refining his barbeque technique, and showed us the science, art, and culture that went into the best barbeque I’ve ever had. Not only that, but he fed us rib tips and barbeque sauce-covered Cap’n Crunch. And he brought a blow torch and charred up a few different wood samples so we could get a sense for the different smoke flavors.
Luck surface area  is an immensely useful concept. Bill’s advice was essentially to increase my serendipity surface area, exposing myself to ideas that perhaps weren’t interesting because I just hadn’t seen them in the right light before.  I’ll certainly never see barbeque the same way again.
Unconferences in general are all about increasing serendipity surface area. They are just enough structure to create an amazing skeleton, and then get out of the way and allow the incredible brains in the room to fill the space deliberately left empty. It’s a structure that gets out of the way.
Hacker School is such a radically efficient educational experience for exactly the same reason. In some sense, it’s a 12-week-long unconference with ad-hoc one-to-two person sessions. It’s a school that gets out of the way of your learning. This is also why I chose an unstructured hack night as the first format for Women Who Code. The group simply a social platform to bring together phenomenal people and then get out of their way so they can build the code and relationships that they need.
The most surprising thing I’m taking with me is perspective on my daily life. NYC hardens you around the edges quickly. There’s so much noise and hubbub to filter out, and so many people demanding your time, attention, and money. With world-class everything, it’s easy to slip into casual jadedness. Seeing people share their excitement and passion for beekeeping and parenting and schools and tattoos and nunchucks and games and sousaphones, I couldn’t remember the last time I was that viscerally excited about something. I want to put that feeling in a jar and keep it with me in the big city.
I’ll let you know how it goes. In the meantime, get yourself to an unconference. Or make your own.
 Recommended to me by habit formation expert BJ Fogg, whose work has also been immensely useful.
 This is also great relationship advice.
 Luck surface area means increasing the opportunities you have to be lucky, either by increasing your exposure to opportunity or by preparation to take advantage of it when it comes around.
 Someone’s offhand comment on Friday gave me a great new metaphor: ant trails. Ants wander around exploring somewhat randomly. As they go, they lay down trails of pheremones. When other ants come across these trails, they follow them. In short order, the entire workforce are no longer exploring, just trucking food back and forth on established trails. It’s the best way to efficiently keep their colony fed…at the expense of exploration. It’s very easy to go to sessions in your wheelhouse. Bill’s advice got me out of my ant trails.
We were having some great conversations about fellow Hacker Schoolers’ blog posts in Humbug, but that channel is too high-volume for most alums.
Enter: Comments! The Hacker School community can now privately discuss blog posts in a pretty interface with a high signal-to-noise ratio. Check it out (Hacker School login required).
Monday is the first day of the summer batch of Hacker School. You and about 70 other bright-eyed and bushy-tailed programmers will be starting twelve amazing weeks together.
In addition to the excellent advice that Dave and Nick will give you on day one, here are some ideas to help you get the most out of this awesome experience.
Did you know that you can turn on autocomplete for git? A quick survey of other Hacker Schoolers turned up that most Linux distros come with this built in, but most Mac users didn’t have it installed.
- Streamline your tools
- Save time
It’s super easy. Put git’s autocomplete script in your home directory. Then add it to your .bashrc by running
There’s more detail here, along with aliases, which are a MUST. I added
git unstage FILENAME which I find much more intuitive than
git reset HEAD -- FILENAME. Hooray!
Part of my morning routine here at Hacker School is learning a few new things about Python, bash, and git, since in the long run, knowing these tools like the back of my hand saves tons of time.
Let me know on Twitter/Humbug if you want to hear more about this routine.
A big part of life at Hacker School is code reviews. Sometimes facilitators review code but for the most part, it’s our super talented peers.
Getting reviewed is really valuable to accelerate learning. It points unclear parts of your code, and blind spots you didn’t know you had. In some of my projects I’ve implemented things in a brute-force way, and my reviewers have pointed me to data structures or libraries I hadn’t yet discovered that allowed me to cut out lots of code.
Today Allison (a facilitator) offered a demo code review, so we could see how she thinks about a code review. We went over a Lisp implemented in Python written by Nick.
The crowd watching was pretty diverse, so everyone took something different away. Some learned about Python, some about the Git workflow, and some about Lisps.