Rebecca Murphey

Rebecca Murphey is a JavaScript developer, the co-host of the yayQuery podcast, a co-organizer of the TXJS conference, a contributor to The jQuery Cookbook from O’Reilly, and the author of the online book jQuery Fundamentals. Rebecca loves JavaScript and speaks about it passionately at events around the world. She lives in Durham, North Carolina, with her partner, and maintains a highly respected blog when her cats and her dog allow her to do so.

Rebecca is on Twitter. You can follow her @rmurphey.

Published Thoughts

Over the last few weeks, the team I work on has been observing a holiday code freeze — no new features, and lots of time spent fixing bugs and paying down technical debt. Morale is through the roof — even our designated curmudgeon seems to be enjoying himself — but my favorite thing has been seeing the snowball effect that occurs when we start fixing little things. We took the time to add some logging to a fickle process, and discovered that a little caching could go a long way. We created a Chrome extension to help us work on and debug our app; suddenly, bugs are easier to investigate, and we have a place we can add new utilities as they occur to us. We buckled down and rewrote and documented a swath of code whose original developer left the company over the summer, and now we have new insight into how we can use it to solve problems in the future. We made more than 40 improvements to our application’s accessibility, and baked an appreciation of its importance into our team’s DNA in the process. We finally addressed a longstanding // TODO by adding a handful of lines to our codebase, and cut several kilobytes from our production app in the process. We instrumented our code to give us real-world performance numbers from actual users, and created a page where we can see those numbers in real time so we know if something is going wrong.

At our team retrospective the other day, the happiness and enthusiasm was palpable, and the list of answers to “what went well?” was long. Whenever I give a talk about refactoring a codebase, someone in the audience always asks, “How do I convince my company that this is as important as the next big feature or deadline?” My answer is simple: for the sake of the health of your team and your project, you can’t afford to not pay attention to these things. If the powers that be don’t believe you, well, we’re hiring. :)

Process is not inherently toxic. Yes, a bad process can obfuscate what’s really happening and delay progress toward a goal. But a good process standardizes the communication around an effort, reducing the propensity for the overhead of communication to suck time away from actually getting things done. If you don’t like process, maybe what you really mean is you don’t like your process — your team’s, your company’s, your own. Fix it; don’t throw it away because it has a dirty name.

When communicating with fellow team members who are probably just as buried in a deluge of email as you are, it’s important to re-read everything you write and, if you can find a way, say the same thing but use fewer words.

Next time someone tells you “I probably shouldn’t review that code, I’m not that familiar with it,” remind them that that’s exactly when they should review the code: they will learn new things, they will find things other people will not find, and the ownership of the code will extend beyond the person who wrote it, to the benefit of everyone.

Under-promise. Over-deliver. Never the other way around.

It’s very easy to announce that you’re going to do something. Be wary of announcing what you will do, and make a point instead of celebrating what you have done. When you’re planning and plotting, that’s not the time for pronouncements or fanfare about the great work you’re going to unveil sometime in the future. Save it for when there’s something to see. It will be all the more impressive if people don’t see it coming.

I made a website the other day. You might say “but don’t you make websites every day?” Not so much, actually. I work on websites every day, yes, in a manner of speaking, but only insofar as the end product of my effort is consumed via a web browser by visiting a URL. It’s so rarely, though, that I actually make websites that I had to rely on my editor to give me the basics of an HTML page. I just about stopped breathing, hours later, when I pulled my work up in IE and saw that everything was utterly broken, until I realized my editor had left out the oh-so-magical <!doctype html> incantation. Oops.

It’s been so long since I’ve made a website that I sort of lost track of how much better life has gotten in the last few years. Do you remember what we used to do to get rounded corners and fancy fonts? Do you remember what it used to mean to decide to change the width of a layout or to globally tweak a particular shade of green?

Things were terrible and wonderful back then. In some ways I feel bad for people who have arrived at this amazing profession in the last few years. They’ll never know what it was like to read about CSS sliding doors for the first time — a concept so transformative back in 2003 that it makes me a little wistful to see the gentle reminder at the top of the article now that this “no longer reflects best practices.” We spent our days hacking our way to pixel perfection back then, and it was inexcusable and intoxicating all at the same time.

I’m a thousand feet above Burlington, North Carolina, and out the left window I can see the airport that I intend to land at approximately two minutes from now. My left wingtip points directly at the giant “24” at the end of the runway; the windsock beside the runway says I’ll have a headwind and a slight crosswind from the left when I’m landing.

Power to 1,800 RPM. Spin the trim wheel three times, and start descending as my airspeed bleeds off to about 80 knots. Flaps 10 degrees. Soon the end of the runway is over my left shoulder. There’s no control tower here; it’s up to me to tell other planes what I’m up to, and it’s up to them to listen.

Burlington traffic, Skyhawk 6026 Sierra, left base runway 24.

I ease the plane into a gentle left-hand turn—not too steep, or things could end quickly and badly—and the nose of the plane moves through 90 degrees. Flaps 20, 70 knots, descending steadily.

Burlington traffic, Skyhawk 6026 Sierra, turning final runway 24.

Another shallow turn, even more careful this time because I’m moving even more slowly through the air and the flaps angled down from the wings make the airplane feel sloppy and sluggish. I roll out of the turn with my nose pointed slightly left of the runway to make up for the crosswind I’m expecting, but a peek at the windsock beside the runway says the breeze has died, and the picture I see out the front window isn’t right; I’m too high.

Power idle, flaps 30, 65 knots, but not only am I too high, the missing breeze means I’m also moving over the ground faster than I expected and the end of the runway is rapidly approaching, and you might think I could point the nose of the plane down to fix all of this but you’d be wrong because the plane would start moving over the ground even faster while simultaneously descending more slowly.

Well, shit.

Burlington traffic, Skyhawk 6026 Sierra, short final runway 24, going around.

I’ve practiced this plenty of times, but still. Full power, use all my strength to push the control yoke forward as the plane starts climbing or else I’ll stall the plane and crash into the runway, step on the right rudder pedal to compensate for the sudden change in torque, retract the flaps, but slowly or else I’ll also crash into the runway, edge the plane to the right so if I do crash I won’t crash into the runway or a plane that wasn’t listening and decided to take off even though I was landing.

And start over.

Which, as it happens, is the point of this story: sometimes, you do your best to get everything right, and yet you have to start over, and starting over can be damn scary at first. But, as my instructors endlessly impressed upon me during the 60 hours of training that earned me a plastic card that says I am allowed to fly an airplane, there should never be any shame in it—indeed, perhaps the worst thing one could do is to stick with it, and find oneself standing on the brakes as the plane skids off the end of the runway.

You said hi as I made my way up the stairs at Brighton’s Duke of York Picture House. You were looking forward to my talk, you said, especially the part about Grunt, and I nodded and smiled and hoped that you couldn’t see on my face the fact that, with an hour or so to go, I hadn’t actually written that part yet.

I made my way upstairs again after my talk and bumped into you again. You said you’d enjoyed my talk, and we headed to the balcony and chatted and you told me your name, which I’ve since misplaced because I was busy basking in that feeling of being done with a talk that had been occupying my brain for weeks.

And then you asked if you could ask me a question and you seemed very careful about it and I said sure of course you can, and you said:

“Are you ever intimidated?”

Yes. Oh god, yes. A thousand times yes, I am intimidated every day by everything I don’t know and everything I need to learn and all of the people I am so lucky to know who are so much smarter than me. Anyone who was up on that stage or any other stage who tells you they’re never intimidated is either lying or broken. I don’t know how it is that I get to fly to faraway cities, get a microphone clipped to my shirt, and talk for 20 or 30 or 40 minutes and then when I’m done talking, people clap. I know for certain it’s not because I have all the answers, or even more than a few of them.

And you seem relieved to hear this, and even though my foot is broken and I have laryngitis and I’m kind of ready to be back home, I am so damn grateful right then that I get to do what I do, because every now and then I get to let someone like you in on the secret that there’s not all that much that stands between the people on the stage and the people in the audience, we’re all just normal people with normal-people insecurities, glad when someone says hello on the stairs.

We programmers like our if/else statements: If this is true, then do this; otherwise, do this. Indeed, I think part of what I like about programming is that it makes it seem possible to express complex processes as a set of rules.

This tidy approach fails us, though, when we can’t express a decision in terms of a series of booleans that, when ANDed and ORed appropriately, lead us to the Right Decision. Backbone or Ember? SASS or plain CSS? Rails or Node? Progressively enhance or HTML that’s nothing but some scripts and an empty <body> tag? False dichotomies, every one of them, and plenty more that you’ll see argued to death with facts and figures and passion.

Rarely are real-world decisions as straightforward as a simple if/else statement. Details, nuances, constraints… they all matter. The ability to see the big picture, to understand that there is no One True Way, and to use the judgment that comes with experience — that’s what makes for a truly good developer.

At Bocoup, we recently conducted an internal survey about working remotely and methods for communicating with people who aren’t working from the Boston office. We used a Google Docs form to gather responses, and when all of the answers were in, I had a spreadsheet with about 300 data points.

It probably surprises no one here that I exported the data as a CSV and then wrote a small program to tell me what everyone had said. I used Ruby because there are still times when the asynchronicity of JavaScript makes a solution perfectly absurd, but certainly I could have written it in JS, or Python, or Perl, or probably even Java if I was a special kind of masochist. There wasn’t much to it: key concepts included iteration over lists of things, turning strings into lists of things, and using hashes to accumulate the totals. If I didn’t know about hashes I still could have made it work, though it would have been a wee bit less flexible. It was about 40 lines of terrible but working code.

Where my partner works, there are grown-ups who make a very good living who can barely use Excel, even though they work with data every day. Their processes are as inefficient as you might expect as a result. These colleagues of hers aren’t fresh out of college, but they’re young enough that they have decades ahead of them where they will need to make money. I know my partner could readily learn how to write little programs like the one I wrote, but she is reluctant to invest the time because she knows that no one else at her job could understand them, and she’s already an order of magnitude better at the technology side of things than most of her colleagues.

I wonder often what will happen in fields like this. It is sobering to remember how far behind they are: still crunching data by hand, still versioning documents using filenames, still emailing documents around and around and around because it’s the most reliable solution that everyone involved can understand. On the one hand, it makes me feel like my comfort with technology means I will probably always be employable; on the other hand, I have to remind myself that I could probably never bear to work there.