Menu Sidebar

Shut the hell up and listen (Avdi)

Microsoft CEO Satya Nadella will be returning to the Grace Hopper Celebration of Women in Computing conference again this week, but don’t expect him to make quite the splash he did last year.This time, he’ll be watching from the safety of the cheap seats.

Source: Microsoft CEO Satya Nadella skips speaking role at women in tech event, will listen and learn this time – GeekWire

This news item reminded of something that happened last year at RubyDCamp.

It was during the Code Retreat day at the beginning of the conference. If you’re not familiar with the format of Code Retreats, you spend a day writing the same program over and over again. Each time, you pair with someone new. Each time, there is a new constraint, like “this time, no if-statements”. At the end of 45 minutes, you stop wherever you are and throw your code away, then gather and share what you learned. It’s not about finishing; it’s about gaining new perspective from the constraints and from who you pair with.

During one session, I was paired with a programmer I had met the previous year. At the time of our last meeting, she was new to the community and relatively new to coding.

We were coding the Game of Life in Ruby. I don’t recall the constraint at the time, but I remember it was her turn on the keyboard. She was coding the core logic of GoL, the algorithm for counting up the number of living neighbor cells.

I watched as she got started, then told her that I knew a really good way to implement it. She nodded and said something like “Cool! I’d love to see it, I just want to get the tests passing with this version first.” I agreed, and proceeded to sketch out my solution on a notepad as she continued.

A little while later she finished up. I was eager to show her what I’d written down. But first I took a look at the code on the screen… and was immediately blown away by an elegant solution which had never occurred to me before.

I realized that I had just spent the last 5 or 10 minutes with my head down, scribbling away, recreating something I already knew. Meanwhile, I was missing a novel solution that was taking shape right in front of me.

I was gobsmacked. Was this really the frame of mind I was coming into the conference with? One where I talk and everybody listens and nods along to how clever I am?

I had definitely learned something new during this pairing session.

Had I barged ahead with my own solution, ignoring my pairing partner’s work, in part because she was a woman? I don’t know. I like to think not, but the science of implicit bias tells us we often aren’t aware of it.

Was I biased by my perception of her as a “newbie”, and my assumption that I had all the answers? Yeah, almost certainly.

I spent the rest of that conference just listening. A lot. I did a lot of opening my mouth… and then shutting it again. I remember feeling suddenly insecure, but not in a bad way. I folded in on myself a bit, tried not to take up so much metaphorical space, and listened.

I still think back to that experience regularly.

I like to run my mouth. I was basically born to do it. My wife complains, justifiably, that I’m always in lecture mode. Thank God I’ve finally found an outlet where my blabbing tendencies are welcome.

I’m pretty good at talking. I still need to work at listening.

I don’t really have a big motivational finish for this article. Feel free to insert something clever about “winning at the Game of Life” or some such. I’m just posting this as a confession, and a reminder to myself to shut the hell up and listen now and then.

(Posting this on my programming blog because honestly I can’t think of many things more important to successful software development than the ability to listen.)

Mad Max with car. © Warner Bros. Pictures

Programming in a Mad Max Wasteland

we were actually trying for a qualitative shift in belief structures—a new Kuhnian paradigm in the same spirit as the invention of the printing press—and thus took highly extreme positions which almost forced these new styles to be invented.

— Alan Kay, The Early History of Smalltalk

As I’ve become more familiar with the history of projects like Sketchpad, Smalltalk, and Self, I’ve been fascinated by the qualitative difference in approach their builders brought to programming system design, compared to most recent languages. These were systems that flowed out of a distinct philosophy and the intent to change the world. If existing language or interaction paradigms were insufficient to realize the goal, new ones had to be invented. If the implementation couldn’t keep up, new implementation techniques had to be created.

Among other advances, we have this approach to thank for the HotSpot compiler, technology originally created to make dynamic programming in Self feasible on 1980s hardware.

By contrast, most programming languages I’ve worked with professionally were born from much less ambitious visions. Usually, the vision amounted to “help programmers serve the computer more easily”, or sometimes “be like $older_language, only a little less painful”. My language of choice for the last ~10 years, Ruby, is very much in this vein. Most of the design decisions that cause me to love it turn out to be difficult to explain to someone who has learned to program in Ruby. Things like “optional semicolons” and “open classes” are less exciting if you haven’t spent the preceding five years coding in Java or C#.

Programming in 2015 feels a bit like Mad Max sometimes. Most of the “new hotness” technologies are cobbled-together bits of older technologies. And where there is innovation, it is often in service to the cold gods of performance or predictability, rather than opening new vistas of computer-mediated creation. Witness the rise of languages like Go (“C with GC and CSP”), Rust (“C++, but less horrible”), Elixir (“Erlang, but less horrible”), and Clojure (“Lisp without the cruft and mutability”).

These are all great languages, with a lot to recommend them. They are languages I use and enjoy. But they are are languages that exist because someone said “I like programming as we know it, I just want to change X and Y”. Or, alternately, “I’m tired of programmers screwing X up. Let’s disallow it completely.”. These are fundamentally derivative ideas.

Building incremental improvements on old things is good and important work. But in the 60s, 70s, and 80s, people like Alan Kay and Ivan Sutherland dreamed bigger, and even their “failures” changed the face of programming and computing. I wish I could point to areas where this kind of transformational, philosophically-driven innovation is being performed today. But if it’s happening, I haven’t come across it.

An alternative to `puts` in Ruby

As you know, I like to talk about idioms on this blog. A carefully chosen idiom can convey a lot in a few lines of code. Today I realized there’s an idiom I commonly use in my code that I haven’t really talked about before.

Typically, in Ruby, when we want to put a line of text to the console, we do it with puts:

puts "Hello, world!"

Now, there’s nothing wrong with this. It works just fine.

But for a while now, in place of using puts, I’ve been using guys instead.

guys "Hello, world!"

I feel like this adds a familiar, conversational style to my code.

And the great thing is, in Ruby this works perfectly! The Ruby interpreter is smart enough to understand that “guys” is a neutral, nonspecific way of addressing everyone in the room, just like puts.

Well, I should say it usually works. On certain builds of MRI, you may see an error like this one:

NoMethodError: undefined method `guys' for main:Object

Now, on the face of it this may look like Ruby can’t figure out what you mean by guys. But don’t be misled. Ruby understands what you mean perfectly well. This is really just a way for MRI to signal that it’s part of a politically correct clique of SJW programming language VMs.

If you get this error, be persistent. Remember, it’s the interpreter’s job to understand you.

But if you keep at it and you still get the error, that’s OK. There’s an easy fix. You just need to remind Ruby of the correct definition of guys.

module Kernel
  def guys(*args)

All better. No more need to worry about Ruby taking exception to your choice of words.

Wanna know something even cooler? You can do this in real life, too!

The only thing that’s different is the keyword you need to use. Instead of def, you can use well actually. Like this:

Well actually, “guys” is a gender-neutral term in our language and has no connotations of traditionally male-only contexts whatsoever.

That’s all there is to it! If you just read that sentence, you now have a brand-new, correct definition of the word “guys” installed in your head. If you ever felt vaguely excluded by the term in the past, you don’t have to worry about that feeling ever again.

You’re welcome!

Author’s note: Because Poe’s Law is unfortunately alive and well, it is possible that some readers will not realize that this is a work of parody from beginning to end. “Guys” is gendered language, and as such can feel exclusionary. As one commenter on Twitter put it, how many women do you see going in the “guys’  bathroom”?

It is a source of ongoing bafflement to me that programmers who will happily learn a half a dozen different programming syntaxes will vehemently balk at changing their use of one little word in order to help women feel more welcomed to the field.

Newer Posts
Older Posts

Virtuous Code

"The three virtues of a programmer: laziness, impatience, and hubris" — Larry Wall


News, notes, and commentary from Avdi, weekly-ish.

Books and Screencasts

RubyTapas Screencasts

RubyTapas Screencasts

Small plates of gourmet Ruby code.

Confident Ruby

Confident Ruby cover

32 Patterns for joyful coding.

The Making of

Confident Ruby cover

Watch me build an app in Sinatra and Rails

Objects on Rails

Objects on Rails

A developer notebook on applying classic Object-Oriented principles to Ruby on Rails projects.

Exceptional Ruby

Exceptional Ruby

The definitive guide to exceptions and failure handling in Ruby.