Kristina Chodorow's Blog

Hello, Glass

On Friday, I got Glass, which is pretty cool so far.

I got to “bring a guest,” so Andrew and I went over to the Glass studio in Chelsea Market after work. I had been there before for a workshop on designing Glassware (or, as I prefer to call them, Glapplications), so I knew that when they asked, “Would you like anything to drink?” they weren’t just offering soda: the Glass Studio has a full wine bar available. Andrew and I got glasses of red wine and settled in.

When I got the glasses, the guy was like, “Are they lighter than you imagined?” which seemed like a required question. However, they weren’t, they were like sunglasses with a chunky earpiece.

The guy showed me how you say, “Ok glass, take a picture” and I turned to take a picture of Andrew but didn’t quite make it before I think I blinked and it took this:

Which I’m pretty delighted about, because it’s one of the best pictures I’ve ever taken, light-and-focus-wise. So, it’s got a pretty good camera and, unsurprisingly, the less involvement I have with it, the better the picture comes out.

Other cool things:

I hate talking on the phone, and this makes it easier (don’t have to hold anything to my ear, just tap the glasses to answer the phone).
Directions on them seem super useful. Again, way better than phone.
You can screencast whatever you’re doing with Glass super easily, which seems like it might have cool possibilities.

Interestingly, my hair got in the way a lot when I was swiping: I guess whoever designed the UI didn’t have long hair. Also, I find that its dependence on voice interaction is kind of annoying. I don’t really like talking, period, and I feel like a moron talking to my glasses. The last downside I’ve noticed so far is that the battery doesn’t seem to last very long. I wish they had put a second battery in the other side, so that the glasses were at least symmetrical.

So far, my verdict is: seems like an awesome tool. 7 out of 10, with points deducted for looking nerdy.

Davy Jones’ Freezer

Last weekend I participated in The Arbitrary Gamejam #5, with the theme “Damn the Torpedoes! Full Speed Ahead.” I came up with “Davy Jones Freezer,” where you’re an ice cream transport that needs to get through a minefield to deliver ice cream to an island.

This wasn’t as tight a game as The Little Volcano, but I learned a lot of new things. Things that worked:

Having a tutorial class. I always loathe doing the tutorial and it was almost painless.
Figuring out exactly what to deploy. I deployed exactly three files: the index.html, the javascript, and the spritesheet. Previously, I’ve ended up throwing a ton of unnecessary crap up because I’m not sure if I need it or not.
Having a goal for the player. The judge for the last Arbitrary Gamejam pointed out that a goal would have been nice and he was right!

Things that didn’t:

The workflow of drawing something in ArtRage, exporting it to Gimp, magic-selecting the canvas away from the edges, resizing it, exporting it again… ugh. I’m sticking with pixel art from now on, the workflow feels a thousand times more efficient.
The ocean class kind of got away from me. Not only did it become one of those mutant classes that contain references to everything, but I spent a long time struggling to create an infinite board. I think I probably could have broken the problem down better with a few minutes of thought (and maybe a piece of paper).
Up through the end, the background was irritatingly flicker-y. Still not sure why, but I think I need to understand the LimeJs rendering code better.

I wanted a font that said “Here there be dragons.” When Andrew saw it, his reaction was, “Would you like a Dove bar?” Now every time I see it, I think “Dove bar.” The theme of the game doesn’t help, I guess.

All in all, I’m glad I did it, I learned a lot, but I’m a bit disappointed in the final product. This weekend is Ludum Dare, so hopefully I can create something that I’m happier with.

Getting Better All the Time via Code Review

I read a great blog called Ask a Manager, which recently posted a question that I think had more of a technical than business solution:

[New coworker’s] HTML and CSS work are terrible. This is his first “real” job out of college, so I understand that he has some catching up to do as far as honing his skills (as well as how he conducts himself in the office, but that’s another story entirely), but I don’t think that excuses his lack of front-end coding skill if that was part of his job description. I’m currently trying to jump in to help develop one of his projects, and I’ve wasted the past two hours trying to pick apart his code into something I can use. My other coworker has met the same frustrations when trying to use this person’s code.

If someone’s straight out of college, they don’t know how to code professionally. They might be an irredeemably terrible programmer, but they can probably be whipped into shape by code review.

But won’t code reviews take a long time? Well, honestly, yes. It slows you down. However, you’re making your code base better, saving future pain, and passing it forward by teaching the next generation. One of my coworkers came up with a good strategy to review code as fast as possible by making multiple passes:

Pass 1: Style

Make sure spacing is sensible, variable names are more than one letter, it looks like the code around it, and generally follows whatever style guide you’re using (Google has public style guides for most languages, just use one of those if you’re a small company).

Pass 2: Readability

Now that the code isn’t blinding you on contact, see if you can comprehend what the code is supposed to do. If it takes you more than a minute to understand a section, leave a comment that you don’t understand what it’s doing, it needs to be simplified or, if it really has to be complex, it needs a comment explaining what it’s doing.

Pass 3: Functionality

Now that you understand what the code is doing, make sure there are no obvious errors and that there are tests. For new employees/interns, I’ll actually run the tests and make sure they actually pass, since that seems to be a problem sometimes. Also in this pass, make sure the interface is documented and makes sense.

Pass 4: Sparkle

This stage can be project-specific, but it’s the general gotchas that you, as an experienced engineer, know to watch out for that they may not. Do they need to add hooks for monitoring? Are there error cases they’re missing? Should they add another layer of abstraction or use a different class hierarchy?

You can combine these passes, especially as the coworker starts producing better code.

Finally, if you’re reviewing their code but they just aren’t getting any better, you can resort to Joel Spolsky’s advice for slowing down a lousy programmer (see the “Neutralize the Bozos” section).

Scratches & Bruises

Last week, I volunteered at an NYU event (hosted by my old club!) to teach high school girls how to program. It totally changed my mind about what to use to teach kids how to program: they should start with Scratch.

It probably helped that one of Scratch’s creators, Tammy Stern, introduced it. In a few minutes, she created a program that made Beyonce’s head larger and smaller depending on how loud the audience clapped while a funky beat (programmatically generated) played.

90% of the groups of high schoolers ended up with a program that fit a single formula: find celebrity that they liked, find a horribly tacky background, find a song that they liked, then make the celebrity move back and forth on the background while the song played. I only noticed two groups that programmed something interactive, the rest basically used Scratch to make a movie. User interaction seems more conceptually difficult, so it makes sense, but I thought it was interesting.

Each volunteer from Google brought two old-school 15-inch MacBook Pros with them for the students to use. They were really heavy, but I felt like a wimp for hardly being able to carry two laptops. The next day my neck felt stiff and, when I looked in the mirror mid-afternoon, I noticed that my right shoulder was about six inches lower than my left. I tried shrugging it up. It wasn’t painful, but it also didn’t stay up.

I checked in with Andrew about it (one of the perks of working in the same building). He took a look at my shoulders and said, “Let’s go to the doctor’s right now.” The doctor said that a muscle in my back had been “bruised” by the exertion, which was pushing my shoulder out of whack. Over the weekend, my muscle recovered and now my shoulders are just about even again. Phew!

unicorn

P.S. At the Black Girls Code thing I did a few weeks ago, the students had to look up images that they wanted to use on their webpage. One of the girls did a Google image search for unicorns. The first result was the photoshopped image on the right. The little girl gasped. “Unicorns are real?” she asked me, completely seriously. It must be confusing to be a kid in the age of Photoshop.

User Support

On my last post, Jaime asked:

How the whole “Hacker News MongoDB random bashing” situation was dealt with from inside? There is a lot of MongoDB-hate out there, and I guess that it has to be difficult from an emotional point of view (especially when so many silly comments are made)

What I found the most difficult was when someone posted that they hated something that I, personally, was responsible for. They’d say something like, “the PHP driver sucks” on Twitter. Then I’d quietly go batshit, take a couple deep breaths, and reply with something, like, “Hey, I wrote the PHP driver, what’s up?” Once I had helped them debug the problem, they would often totally change their tune and proclaim MongoDB to be the best, which was very rewarding. However, it was really draining to have people casually hating my work, as though it was make by some uncaring drone at a big company.

More generally, if a user was bashing MongoDB, we would try to reach out and offer help. There was sort of triage process: someone would notice a blog post or tweet and put it up on the group chat. We would provide practically unlimited free support to anyone: their success was our success, after all. Sometimes we couldn’t help or they didn’t want help, but often we could turn bashers in boosters. And that was very rewarding.

The High Ground in Low Country

Part of MongoDB’s company philosophy was not to trash-talk any of our competitors, no matter what. If we were asked, we should describe what the other solutions’ strengths and weaknesses were, and what good use cases would be.

My coworkers researched the other databases out there and gave presentations on them, so we’d all be able to talk fluently about them. And then we took the high ground.

But sometimes it was so. hard. When the competition attacked MongoDB, I found it impossible not to take it personally. But you know what? Taking the high ground actually worked. People remembered MongoDB, not whatever company posted the inflammatory blog post.

However, I’m glad that I don’t have to say nice things about those craptastic databases anymore 🙂

(Except for Redis. That dude was always classy, and his database is cool.)

The Little Volcano that Could

This weekend, I participated in The Arbitrary Game Jam, a once-a-month game jam with randomly-chosen topics. My entry was The Little Volcano that Could, a turn-based strategy game where you’re a little pool of lava in a big scary world.

The jam started at 10pm on Friday night, at which point I was at a Halloween party. I checked my phone and the topics were lava, “love hurts”, and “be a stranger to fear.” I started thinking about making a platformer and then thought it might be fun to play the lava and try to burn as much as possible.

Saturday morning, I pulled out a pad and some dice and tried out some ideas. It turned out killing villagers was a lot of fun, so I decided to focus on that.

I created a new Github project for it and got a 3×3 square of grass with lava in the middle:

The beginnings of a game.

I implemented being able to “move” by placing adjacent lava:

Next, I implemented the villagers who’d throw water at the lava to cool it and a “thermometer” to put a cap on how long the game could last:

At this point things went a little off the rails. I was thinking I’d implement A* search for the enemies to find lava, but I started freaking out that I wouldn’t have enough time to do it. I ended up scrapping a couple hours of programming and just making the villagers random walk. I was getting pretty tired of programming at this point, so I took a break and worked on art most of the night.

First I came up with a palette I liked in ArtRage:

It’s really fun using to the palette brush to mush around the colors. Next time I’m going to add a few more shades, I think, this was just too difficult to work with.

I used the palette to implement a bunch of pixel art in Sprite Something (which is a fantastic sprite editor for iOS, by the way).

I’m not sure why, but the grass took hours longer than everything else (even the animations). It also ended up looking more like tentacles than I really wanted.

I was pretty happy with this tree, but then I found out it was almost invisible against the grass.

Saturday night I started plugging the art into to the actual game:

Sunday was mostly getting the animations to do the right thing. I had to slow them down, make the water throwing not repeat endlessly, and set up this nice chain of events:

villager-animation

It involves:

The throw animation above.
Fading out the lava to reveal the “cooled” surface.
Lifting and fading out the cloud of steam.
Once the throw animation is complete, the villager can walk away.

And the villagers have to be facing the right direction, which there are still some bugs with on the walking.

Deploying was as annoying as always, but around 4pm Sunday everything was set to go and I tweeted my entry to the organizer.

All in all, it was a lot of fun! It went a lot smoother than the last game jam did and, although there are about 50 things I wish I’d had time to add (ranged weapons, fog of war, lava lamps), I’m pretty happy with how it came out. Theoretically I could have worked on it for 6 more hours than I did, but I was pretty happy with it and tired.

Please give my game a try and let me know what you think!

MongoSF

I flipped to the next slide. “You can think of MapReduce like a chicken… ” I couldn’t think of the verb. “Like…” I looked out at the audience and tried to concentrate. What was the verb for what a chicken did to create eggs? It felt like my brain was at a standstill, all that was coming was “poop.” I went with it. “Like a chicken pooping eggs.” It went over big. As though it were planned, I smoothly continued describing MapReduce in terms of chickens pooping eggs.

After my talk, I fled to Starbucks, got a very froofy Frappuccino, and checked my Twitter reviews. It had been a popular talk (programmers love poop jokes), but I was shaky and exhausted.

The night before I had been up almost all night, physically sick with nerves, going over my talk it again and again, then trying not to think about it, then going over it again. MongoSF 2010 was 10gen’s first major conference. I was giving the first talk of the morning in the biggest room and, worst of all, my coworkers would be watching. I had given a hundred talks before, but never ones my coworkers were at. (And it definitely made an impression: when I left 10gen earlier this year, one of the goodbye emails I got mentioned the chickens pooping eggs.)

P.S. 10gen hired a guy to teach employees how to give better tech talks. He said that before a talk, your body surges with adrenaline and people who like roller coasters, bungee jumping, and other heart-pounding activities tend to like public speaking. This made a ton of sense to me, as I’ve always loathed that shaky fight-or-flight feeling.

The Joy of Programming

Last weekend I volunteered at Black Girls Code, an organization that encourages black girls to enter STEM fields. I was a teaching assistant for the “Build a Webpage in a Day” workshop, which basically covered some HTML and a tiny bit of CSS.

The problem is, HTML isn’t very interesting. After a few hours some of the girls started complaining about how this was boring and one told me, “I thought we’d be making games.” Nope, you’re formatting documents for six hours, enjoy.

HTML is also a terrible first language because it has all sorts of weird quirks. We were using Thimble so the girls could code on one side and see the results on the other, which is pretty cool. However, imagine that you’ve gone to this site and you’re seeing HTML for the first time:

Okay, now ignore the first line, that’s way too deep for us to get into. Now everything in the <html> tags is your webpage. Except the <head> isn’t actually displayed on your page. Except for the <title>, which isn’t a title on your page, it’s a title for your page. Then you see how the end tags have this extra, easily-missable, “/” character? That “closes” the tag. Got all that?

There were two groups and I was working with the younger one, 30 kids age 7-10, most of whom had to learn copy/paste and where and how to type the <, >, and / keys. Repeatedly. I didn’t mind, but boy did the kids get frustrated trying to type < and > and looking up a few seconds later to see “,” and “.”.

Most of the girls seemed to be most excited about showing their families what they had done after the event. To actually have a webpage to show, the girls had to log into Thimble and hit the “Publish” button. The head teachers told everyone to use IE, but they hadn’t actually run through the curriculum beforehand and so they didn’t realize that Thimble doesn’t let you log in from IE.

So all of the girls spent hours working on a webpage before I tried logging one in. I let the teacher know about the problem and then she tried to explain to 30 7-10-year-olds that they had to open another browser and cut-and-paste their work into it. Many of them ended up getting really frustrated, confused about which browser they had open, and never ended up logging in at all. At the end of the day, one of the girls on her way out was begging me to add one more thing to her webpage so it would look impressive when she showed her folks later. After she was gone, I went over to her computer and she wasn’t logged in. She had no webpage to show her folks at all.

If it was my workshop…

If I had to redesign this, I would have started with JavaScript. You can get a “web app” started in three lines:


alert("Hello, world")

It’s not actually correct HTML, but it gives you immediate feedback and you can start playing with it. And I got the distinct impression that these girls wanted something to play with.

To create a webpage they could show their folks and use later, I’d have the kids install Dropbox. Then they could save files to the Dropbox folder and Dropbox would serve them.

And I’d run through the curriculum before I taught the course.

Speed Mentoring

On Thursday, I did a “Speed Mentoring” event at Google, where a Barnard & Columbia woman had five minutes to ask a Googler questions and then we’d move on to the next student. It was an odd format for mentoring, but I think by the end I had a useful set of quick advice for undergrads. Here it is:

What languages should I learn/what classes should I take?

Learn one of Java, C, C++, and Python and don’t worry about too much about it, you’ll be learning new ones your whole life. Learn the pluses and minuses of the languages you know. It’s fine to have a favorite, but don’t be obnoxious about it.

The only class that I took in college that applies to what I do day-to-day is Unix Tools: learn what version control is and how to use Linux.

How do I get an interview?

For small companies: focus on the cover letter. Tell them why you think their company’s cool, why you want to work there, what you’ve done in relation to their company (e.g., used their API in a hackathon).

For any size company, do something other than the standard undergrad crap you can put on your resume. Almost all undergrad resumes are basically identical. Be ready to talk about anything you put on your resume.

I had an internship programming frozen yogurt machines in .NET, should I put that on my resume since it’s not “real” programming?

YES! That’s interesting and memorable. (And it’s totally real programming.)

What can I do to stand out from other applicants?

Get a referral from an employee if you know anyone there. Create a website, do some hackathons, contribute to an open source project. Get some cool stuff on Github, think of it as your portfolio.

I did a hackathon where I did a Foursquare mashup iOS app and my code was really ugly. Should I still put it on Github?

No worries, all undergrad code is butt-ugly. No one expects you to be able to code beautifully yet. Put it on Github! Then talk about it in your cover letter when you apply to Foursquare.

How do I get through the interview?

All the stuff above, plus study the heck out of Cracking the Coding Interview and similar books.

What if I don’t really know what I want to do?

Totally fine, I had no idea what I wanted to do. Do some internships, that should help you figure out what kind of company you want to work for. When you’re interviewing, interview them right back. This is like dating, sure you want to impress them, but they should also be impressed. You’re probably going to be spending more time at work than with your significant other.

Small companies offer the flexibility of everyone has to do everything, so I found it easy to wiggle my way into a “perfect fit” job. Conversely, at Google, you can switch teams if you want to work on something else. Flexibility varies on the company, though.