rmurphey

I need to say a few things.

Posted

Over the weekend, there was a tweet announcing that Google was going to provide "scholarships" to qualified women to attend JSConf.eu. There was then a tweet by another person calling this "disgusting" and "illegal." Nicole Sullivan has a level-headed and well-articulated roundup of the back-and-forth and some of the surrounding issues, and I suggest you read it.

I take no position on the scholarships. I question whether they will have any meaningful or lasting effect. I fear the availability of the scholarships will lead to ill feelings about the women who do attend. Simultaneously, I yearn to discover, against hope, that they make it possible for some highly qualified but unknown woman to gain access to the JavaScript community. Whatever. Smarter people than me have a better idea than I do as to how effective they will be, and lawyers can tell you whether they're illegal. I'll stand firmly in the "no" camp on the disgusting count.

You know what's disgusting? Being groped at a conference after-party by a drunk married man. Opening your hotel door to discover said drunk married man stumbling down the hall, asking himself into your room, and literally having to slam the door in his face. Having a video of you posted on the internet, suggesting that you were engaged in a sexual act with the yayQuery logo. Seeing someone ask, publicly, on Twitter, if anyone knows the name of the hot conference chick. That, dear reader, is disgusting.

I adore my male friends in the tech community. They have encouraged and supported me and welcomed me into their inner circles. But even they can act like 12-year-old boys sometimes, and while I don't begrudge them that, it is hard, because it's at those moments that I realize how much I am not them, how much I long to have more than the barest assembly of female peers who have any idea what this is like. And then I remember: those peers I long for will have to put up with so much shit to be in that cool kid's club, and you know what? If Google wants to pay them a measly few hundred bucks to put up with it, maybe that's OK. Hell, maybe they ought to pay them more. Perhaps, as ham-handed and questionably productive as the scholarships may be, it's only fair to pay women to look the other way when some asshole treats them like a thing instead of a person.

I am angry. I have been angry since Saturday, when this all started. I have spent the last year trying to be the thing that I want to see: the woman on stage. I have formed groups to encourage other women to do the same. I have reached out to women who show potential and tried to give them the encouraging nudge they need that no one really gave me. And right this very moment, I feel incredibly selfish. This weekend reminded me what I am asking those women to enter into: a world that presents no tangible barriers, but that will objectify them every step of the way. And if these women have the guts -- well, let's be community-appropriate here -- if they have the balls to speak up and say that it is hard to be a woman in this field, that it takes a thick skin and determination and a willingness to be one of the boys even when that's the last thing in the world they want to do, then they should brace for a chorus of men to rise and tell them they are wrong.

Men, guys, boys: I am not asking you to give up Star Wars and The Matrix. I'm not even asking you to give up gratuitous phallic references and #twss jokes, though I hope we're all grown-up enough to know that there's a time and a place. And you know what? If you want to DM your friend about trying to hook up with that hot conference chick, well, good luck with that. We're all human. But for the love of all that is good: this being a woman in your world thing, it's not easy, OK? Maybe you can't understand it, and I even believe it when you say you don't mean it. But when you deny it, you just look like an ass.

Lessons Learned from Taking On a Project in Crisis

Posted

I just got done with an emergency project for an agency developing a public-facing application for a mutinational technology client you've most certainly heard of. I developed the entire front-end -- HTML, CSS, and JavaScript -- for a non-trivial application with a limited spec in just seven days. The experience was so eye-opening that I feel the need to write down some of the things I've learned, in hopes that I can benefit from my experience in the future.

• Demand all technical source material up front, such as functional specs, mockups, work that's been done to date, etc. Give the client a fixed amount of time to deliver that source material, and don't make a decision about taking on the project until you've seen it. What the client can deliver in that fixed amount of time will shed a lot of light on the state of the project and whether their expectations are realistic.
• Set clear time expectations. Am I willing to work 16 hours a day? Am I expected to? Are there hours during which I'll be expected to be available? Am I willing to work on the weekend?
• Find out whether the client expects me to be available after the imminent deadline, and to what extent. The last thing I want is to snatch defeat from the jaws of victory by being unable to support the code I've written.
• Do not accept responsibility for commitments made on my behalf. The recruiter said I'd be available six hours a day when I told him four? Not my problem. The client committed to having a feature ready for review without consulting me? They probably won't make that mistake again.
• Ascertain the rest of the team's commitment to the project. If I'm expected to work long hours, will they be there during those long hours to get me what I need? Are there any constraints on their availability?
• Establish a single point of contact at the client, and make clear I'll be depending on them to get me any information I need and I'll be treating their decisions as final. Insist that they participate in all calls I'm expected to participate in.
• Limit the amount of work I do before I have access to all client systems I'll need access to: version control, testing environments, ticketing systems, etc.
• Insist on a ticketing system. I'm new to the project and I have a lot to get up to speed on. I don't want emails flying at me from all directions -- decisions and technical requirements need to be documented in a single place that everyone can see. This is my only insurance when someone wants to know why something isn't done, or why it wasn't done the way they expected.
• Insist on version control, even if it's something crappy like CVS. I'll need a way to make sure the rest of the team has access to my latest and greatest. FTP blows, especially when I'm FTPing to a server where another developer is constantly deploying a new build, overwriting my work.

What other advice do you have?

On speaking at the 2009 jQuery Conference

Posted

One of my personal goals for this year was to start being part of the solution to the dearth of female speakers at tech events. Though I’ve talked at a couple of smallish local events over the past few months, this past weekend I got to do it in a big way: I presented a talk on using objects to organize your jQuery code to an audience of around 100 people, more by far than I’ve ever spoken to before.

[This post isn’t so much about the talk itself as my first experience with talking at a conference. If you’re interested in the talk, I encourage you to check out the slides, links, and code at the link above.]

I decided I wanted to try to talk at the jQuery conference after I saw the initial very smart, very male speaker lineup. I submitted my talk based on an article I wrote earlier this year, and by the time it was all said and done, mine was the second most popular topic and I was slated to have 30 minutes in “the big room.”

There is something sort of out-of-body about that moment when I am standing in front of a roomful of people right before I talk — I had it when I gave my first Refresh talk, when I taught my first jQuery class, when I spoke at my first BarCamp RDU, and yet again this weekend. For that moment, in my head, I am a complete and utter case, and can’t quite fathom that I thought this was a good idea. And then I start talking, and then it is OK. And then when it’s over, people clap, and I like that part.

Back when I set out to start speaking more, I decided to take an improv class. For six weeks, we practiced being spontaneously funny, and at the end, we got up on stage in front of a bunch of strangers and tried to do it for real. Knowing what that feels like — what it feels like to run up the aisle like you’re excited when really you’re terrified because you’ve never done this before and in real life you sit at a desk all day and talk to no one and what were you thinking? — makes the thought of talking to a bunch of strangers about what you actually know how to do seem like a completely reasonable thing.

My experience this weekend was nothing short of excellent — people I barely knew rallied around me throughout the weekend to help me improve my presentation (most notably Chris Williams, organizer of JSConf, to whom I owe many thanks for all the images — especially the Liger). The audience graciously tolerated the part in the middle where I had to leave the podium to (very publicly) blow my nose. People asked great questions, and audience members gently pointed out things I might want to rethink. With the exception of one creepy off-the-wall comment about my “fine-boned features,” the reaction was overwhelmingly positive.

Reliable sources told me that of 300 attendees, approximately 282 were men. I was the only woman to submit a talk. So this is the part where I encourage other women to do the same. I think women, on the whole (of course there are exceptions), are way more inclined than men to think they aren’t good enough speakers, that they don’t know a topic well enough to tell it to other people. Two truths: one, the speaking skills of the speakers I’ve seen have been all over the map; two, you’d be surprised how much you actually know about a topic, especially given the right audience. Go speak at a small event — a local meetup, a Refresh, even a lunch-and-learn at your office. Get to know the people who do speak at events, and discover that they’re people just like you. Go out on a limb and try something that’s

On gaining respect as a front-end developer

Posted

Someone wrote me today:

Where I work, design is highly valued with the leader of that group being our Creative Director, back end programmers are also highly valued, but front end ... not so much. Partly I think its that I don't toot my horn but I know there are other reasons. At times, my bosses haven't even understood what it is that I do. Back end programmers look down on front end assuming that its trivial or something that should be relegated to compilers. I was wondering if this is a common thing or more so something that is happening at my particular company, and if you have any advice or pointers on this.

I thought my response might be worth sharing: I do think this attitude is common but not necessarily the rule. In my experience, I've found that by having a proven value proposition, you can gain converts and respect. Front end developers are in a unique position to improve page performance (perceived and actual) by using best practices such as the YSlow tests. Front end developers are also in a unique position to help develop templating systems and to write thoughtful CSS, both of which help enable the rapid prototyping and rollout of new features. A focus on results and best practices -- demonstrating that you aren't just pushing pixels around -- is the key. Back end developers respect people who think like they do. Be mindful of opportunities for abstraction and reuse. Write object-oriented CSS and JavaScript. Craft solutions that are maintainable and documented. Learn and make use of version control systems. Look for opportunities to participate in developer conversations about new features, and understand what the back end developers are up against. They'll appreciate all of this. Take the time to teach and to learn. Be sure you have at least a passing understanding of the code the back end developers are writing, and leap at opportunities to share your knowledge. I've worked with more than one back end developer who was surprised to discover what all they didn't know about the front end, and through our conversations about how we approached problems, we both learned a lot. Finally: identify opportunities for quick victories, execute on them, and make the results known. Benchmark before and after. Can you reduce the number of HTTP requests on a page, decreasing both the perceived and actual rendering time? Are you keeping your JavaScript out of the <head> as much as possible, preventing pages from stalling while rendering? Can you write JavaScript that is primed for reuse, and demonstrate opportunities for that reuse? Has your carefully crafted CSS allowed the rapid rollout of a new feature? Don't be afraid to tell these stories -- they'll tend to strengthen your position by clarifying the important role the front-end developer plays in a site. Good luck :)

Announcing Triangle Web Women

Posted

When I noticed that a conference I'm attending didn't have any female speakers listed, I contacted the organizers to see what was up. As soon as I wrote them, though, I realized that I didn't even have anyone to recommend for inclusion. Thus was born Triangle Web Women, my local effort to foster connections, promote knowledge-sharing, and generally establish a community among local female web professionals. Interested? Check out triwebwomen.ning.com, the fledgling website where I'm gathering participants and sharing events. Before the site was even set up, we had an initial gathering at a local restaurant, with five of us drinking wine, eating tapas, and talking about everything from accounting software to time-tracking to whether the world needs yet another content management system. I'm looking forward to our next gathering, March 19, location TBA, with a few more web-working women. We may not take over the conference circuit, but it's a start, right?

5 reasons you don't really want a jack-of-all-trades developer

Posted

I've spent the last couple of weeks trolling Craigslist and have been shocked at the number of ads I've found that seem to be looking for an entire engineering team rolled up into a single person. Descriptions like this aren't at all uncommon:

Candidates must have 5 years experience defining and developing data driven web sites and have solid experience with ASP.NET, HTML, XML, JavaScript, CSS, Flash, SQL, and optimizing graphics for web use. The candidate must also have project management skills and be able to balance multiple, dynamic, and sometimes conflicting priorities. This position is an integral part of executing our web strategy and must have excellent interpersonal and communication skills.

Really. Now I don't know about you, but if I were building a house, I wouldn't want an architect doing the work of a carpenter, or the foundation guy doing the work of an electrician. But ads like the one above are suggesting that a single person can actually do all of these things, and the simple fact is that these are fundamentally different skills. The foundation guy may build a solid base, but put him in charge of wiring the house and the whole thing could, well, burn down. When it comes to staffing a web project or product, the principle isn't all that different -- nor is the consequence. I've thought a lot about this these last couple of weeks, and I don't think this post is sour grapes about the fact that I don't have the top-to-bottom, front-to-back web development skills that this ad and others seem to be asking for. I'm proud and confident of the abilities I've assembled when it comes to front-end development, and I have a rock-solid understanding of what makes websites tick. The thing is, the more you know, the more you find out you don't know. A year ago I'd have told you I could write PHP/MySQL applications, and do the front-end too; now that I've seen what it means to be truly skilled at the back-end side of things, I realize the most accurate thing I can say is that I understand PHP applications and how they relate to my front-end development efforts. To say that I can write them myself is to diminish the good work that truly skilled PHP/MySQL developers are doing, just as I get a little bent when a back-end developer thinks they can do my job. So to all of those companies who are writing ads seeking one magical person to fill all of their needs, I offer a few caveats before you post your next Craigslist ad:

1. If you're seeking a single person with all of these skills, make sure you have the technical expertise to determine whether a person's skills match their resume. Outsource a tech interview if you need to. Any developer can tell horror stories about inept predecessors, but when a front-end developer like myself can read PHP and think it's appalling, that tells me someone didn't do a very good job of vetting and got stuck with a programmer who couldn't deliver on his stated skills.
2. A single source for all of these skills is a single point of failure on multiple fronts. Think long and hard about what it will mean to your project if the person you hire falls short in some aspect(s), and about the mistakes that will have to be cleaned up when you get around to hiring specialized people. I have spent countless days cleaning up after back-end developers who didn't understand the nuances and power of CSS, or the difference between a div, a paragraph, a list item, and a span. Really.
3. Writing efficient SQL is different from efficiently producing web-optimized graphics. Administering a server is different from troubleshooting cross-browser issues. Trust me. All are integral to the performance and growth of your site, and so you're right to want them all -- just not from the same person. Expecting quality results in every area from the same person goes back to the foundation guy doing the wiring. You're playing with fire.
4. Asking for a laundry list of skills may end up deterring the candidates who will be best able to fill your actual need. Be precise in your ad: about the position's title and description, about the level of skill you're expecting in the various areas, about what's nice to have and what's imperative. If you're looking to fill more than one position, write more than one ad; if you don't know exactly what you want, try harder to figure it out before you click the publish button.
5. If you really do think you want one person to do the task of an entire engineering team, prepare yourself to get someone who is OK at a bunch of things and not particularly good at any of them. Again: the more you know, the more you find out you don't know. I regularly team with a talented back-end developer who knows better than to try to do my job, and I know better than to try to do his. Anyone who represents themselves as being a master of front-to-back web development may very well have no idea just how much they don't know, and could end up imperiling your product or project -- front to back -- as a result.

If your budget really is limited to a single position, you might want to consider whether you'd be better off working with several contractors with specific and proven skills, rather than a single person who claims to encompass everything you're after. Your management overhead will increase in the short term, yes, but your headaches down the road will decrease exponentially. In the process, you'll gain access to people who can help you evaluate potential full-timers, and probably gain some insight into the actual list of skills a full-timer needs to provide. If you're one of the people who's written these ads, all is not lost. Invest in a technical consultant -- probably one you can't afford to hire full-time -- to help you really understand your needs and the skills required to solve them. Often they can assist you with writing and posting the ad, and interviews too. For example, I'll meet with a client, write and post a detailed ad, identify candidates, and interview contenders; if I don't have the technical skills required to evaluate a candidate, chances are I personally know someone who can. Doing that homework up front, and understanding and describing what your needs really are, is vastly more likely to give you the perfect fit you're after than if you just cast a wide net and see what you catch.

Why niche networks will flourish and Facebook will flounder

Posted

It was just a couple of months ago that I was naively lobbying my friends to join Facebook. I envisioned creating a place where I could find out what everyone -- especially people who were more acquaintances than friends -- was doing, without the burden of keeping in contact with them individually. Joe was going on vacation? I'd know not to be looking for him online. Corye was studying for a law school exam? No sense inviting her over to play cards this weekend. Then came the applications, and then came the pirates. And the vampires. And the causes and the superpokes and the invitations and the ... well, and the noise. I started to wonder whether some of these people actually had jobs, and I started to visit Facebook less and less. I felt a glimmer of hope when Facebook offered what seemed to be the ability to silence some of the noise, but no matter how much I clicked to hide useless News Feed items, they persisted with a vengeance. Then it occurred to me: I'd blithely assumed that everyone would want to use Facebook the same way that I did -- as a source of information. When applications made it a source of entertainment, its value to me as a source of information collapsed. Instead of being the general social networking site that I'd wanted it to be, and that I think it sought to be, it became a niche network for people who like to spend their time with pirates and ninjas and movie quizzes; in the process, it stopped appealing to people like me who had come to it for the information service it provided. It makes sense that this happened: the internet has been groundbreaking in the opportunities it provides for like-minded people to gather and share their common interests. And that's why, when I was asked the other day what I thought about social networks, I said I believed the future is in niche networks that target specific interests, rather than general networks that try to make room for any and all interests. The concept of critical mass dictates that general networks will become specific, sending the dislocated people packing to search for networks that provide what they want. It's why I'm spending more time on LinkedIn; why an avid reader might gravitate toward Shelfari; why a music lover might head over to Last.fm; and why my game-playing, time-killing acquaintances are still pirate-ing and ninja-ing each other over on Facebook. These niche networks will have more value to advertisers than general networks, too, as sites figure out how to leverage data contained in a person's network to target content and advertising. That two people have established a relationship on Last.fm says far more than that two people have established a relationship on Facebook -- membership on Last.fm indicates some degree of passion for music (which can serve as a sort of prequalification), whereas membership on Facebook indicates little more than ownership of a computer. Just as RSS transformed how people interact with information, allowing people to remix and repurpose websites (or avoid them altogether via an RSS feed reader), the next step in the evolution of social networking -- be it OpenSocial or something else -- is going to transform how people interact with their people. It's going to put the focus on the data, not the presentation, and allow users to remix the data and the presentation to suit their needs. The quality and interesting-ness of the data will dictate which sources a user chooses, and the user will be able to trivially tie together as many of the sources as they want. Facebook, Shelfari, Last, LinkedIn, and all the rest will continue to be destinations for the niches they cater to, and the real competition will be in offering the best data. Choosing a one-size-fits-all site -- and naively inviting all of your friends, hoping they come for the same reasons -- will be a thing of the past.

Salivating over server-side Javascript

Posted

I came across The End of Web Frameworks in my dzone RSS feed this morning, and it echoes a thought that runs through my brain as I get more and more comfortable with jQuery: who needs the server when you've got Javascript? Wouldn't it be great if the server just handed out data, and the client figured out what to do with it? After talking directly to the DOM for the last several months, a trip back to PHP left me utterly disoriented for a few minutes -- why, exactly, couldn't I take the anchors from that unordered list I'd just built 50 lines ago and reuse their hrefs for something else? As a couple of commenters pointed out, it's not that easy -- there's still graceful degradation (the yin to progressive enhancement's yang?) to worry about. It's easy to say "oh, I don't have to worry about that," but until the day that's actually true, Javascript on the client side simply can only supplement good, solid, server-generated markup. That's why stuff like this discussion about server-side jQuery has me nearly salivating. I'm imagining getting JSON data from a simple bit of server-side code that's not encumbered by messy markup and then writing some Javascript to build the DOM of my dreams. The added bonus would be server-side code that could serve that clean, pretty JSON data up to anyone I wanted to have it. Of course, that DOM would still need to use semantic HTML and not rely on client-side Javascript for anything -- and not just because a visually or otherwise impaired person might drop by someday and want to use my site. Progressive enhancement is good for SEO, too, (and so are web standards in general). One only wishes that would lead SEO-focused companies to fall all over themselves in pursuit of it :)

How I learned CSS

Posted

I remember when I first tried to understand how to produce designs for the web -- coming from the paper-based world, it was hard for me to accept everything that was suddenly out of my control. When I first tried to grasp CSS with the help of now-defunct Adobe GoLive, I bailed pretty quickly. Table-based layout and font tags didn't make much sense to me either -- why did I have to slice up a page into a bunch of adjoining cells, instead of just drawing independent boxes like I did in Quark? A couple of years later, I decided to try again, motivated by the realization that my eight-years-younger brother seemed to be better at this web stuff than I was. I spent untold hours trying to wrap my brain around the difference between margin and padding and exactly how to get floated elements to bend to my will. I remember the epiphany that one could use left-floated list items for a horizontal menu, or that the right DOCTYPE can force Internet explorer to behave more like a real browser. These days, I have an honest-to-god job doing this stuff, and every now and then, someone will ask me how they can learn it too. It all makes so much more sense to me than it used to that it's hard to remember how I got here. In the interest of getting this stuff written down for passing along, though, here are a few thoughts:

The Tools

These are things without which the rest is impossible:

• A text editor Notepad will do just fine; for a few bucks, you can get TextMate for Mac or the e Text Editor for PC. If you use Dreamweaver, hide everything but the file navigator panel and the code editing view. You will learn nothing from Dreamweaver's "design" view.
• Firefox You'll need to test anything you do in Internet Explorer, but first, you'll get it working in Firefox. Whereas Internet Explorer enjoys mocking web standards, Firefox does its best to adhere to them; plus, it has all sorts of extensions that make it easier to troubleshoot your work.
• Firefox Web Developer Toolbar This has all sorts of useful tools in it, including a real-time CSS editor that opens in the browser's sidebar so you try changes to your CSS and see the results immediately.
• Firebug This is most useful for Javascript debugging, but it has some nice features for debugging CSS as well.
• HTML Validator Incredibly helpful for finding errors in your HTML.

(An aside: A few months ago I booted up an old laptop and found a preview release of Firefox 1.0 installed beside a well-worn Internet Explorer 6; when I abandoned the laptop, I was in the process of abandoning IE too. I can't help but wonder how difficult my learning would have continued to be without the arrival of Firefox, which, with the extensions mentioned above, makes it so much more possible to learn all of this stuff in a very tangible, immediate sort of way.)

Learning with Firefox

Once you have the tools above, open Firefox and start with a page someone else built -- like the one you're on right now -- and see what's inside. It pays to be curious about every web page you visit; if you see something interesting, view the source and figure out how it got there. Some tips:

• Ctrl-U will show you the HTML for a page, and with the HTML Validator extension, you can "clean up" the HTML so it's easier to read.
• Ctrl-Shift-E will open the Web Developer Toolbar CSS editor, which will show you the CSS for the page, with a tab for each CSS file. You can edit the CSS in the editor and see the effects immediately.
• F12 will open Firebug. In the top left of the panel that opens, click the Inspect menu item, then move your mouse back to the page itself and click on an element to find out more about it. You can also click on the HTML tab to view the HTML and expand and collapse sections of it to see the structure of the page. Hovering over an element in the HTML panel will highlight it on the page; clicking on an element will let you find out more about it in the Style and Layout tabs of Firebug. (Firebug is an incredibly powerful tool that you really need to play with to fully appreciate. It's a completely non-destructive tool -- you can't hurt anything with it unless you try really, really hard -- so don't be afraid to click around and see what happens.)
• Remember that these days, lots of page elements are built with Javascript rather than with straight HTML. Ctrl-U will show you only the HTML; Firebug will show you the "generated source," including any elements built with Javascript. Firebug also lets you look at the Javascript on a page, which can be helpful when you're trying to understand how something got there.

POSH

Plain-old semantic HTML. When you go to make a web page, write the simplest HTML you can, and use standard HTML elements whenever humanly possible. Start by creating HTML that represents the actual sections of the page -- header, navigation, sidebar, content, footer -- and give the elements names that say what they are, not where they go. When you think you're done, view the HTML in a browser, without CSS, and see if it makes sense. Then, and only then, open the browser's CSS editor and start styling the elements. See how far you can get without adding any design-related markup to your HTML. If you find yourself writing convoluted HTML or adding purely presentational markup, to make something work, it's time to reconsider your approach. Once you have a good stylesheet started, copy it to your text editor and continue working on it there.

Strategies

It helps to give yourself deadlines, even if they're imaginary. I've learned more about HTML, CSS and Javascript in the past 12 months than I learned in the three years before, and I think that's largely because deadlines have forced me to solve problems rather than pondering them. Don't be afraid to do something less than perfectly; there can be value in just getting it done. I constantly look back at things I did three months ago -- let alone three years ago, and sometimes three weeks ago -- and I cringe when I think how differently I would do them today. But half the reason I know what I know now is precisely because I didn't know it then, and I learned it along the way. Understanding the building blocks of the web is an iterative process, and you'll do better if you remember that you cannot know everything you wish you knew.

Using ems for font sizing in css

Posted

A List Apart had a great article recently on using 'em' for CSS font-size declarations, which served as great back-up for some conversations I'd been having among coworkers. (It turns out that people who didn't have a former life in print don't necessarily understand what an em is: a self-referential unit of font size measurement, equal to the height of the capital letter M. Back in the typesetting days, it was a unit for measuring space, especially horizontal space, in the form of an "em dash" (rendered now as —) or an "em space." There was also a sister unit, the "en.") Anyway: I just came across this post, by someone trying to put ems into practice; at the end, he gets into tools for doing conversions from pixels to ems, and it struck a surprising nerve with me. Here's the thing: While I can see how pixel conversion seems useful when you first make the switch from px to em, I think the whole point of using ems instead of pixels is to embrace the concept that, on the web, sizes are relative, not absolute. If you're focused on matching an absolute size in a mockup by converting pixels to ems, the chances seem good that you're dealing with a layout that wasn't intended to work with relatively sized text to begin with, and/or that your ultimate product won't work if the user makes a different decision than you about how they will consume it. If you receive a Photoshop mockup where body copy is 10px tall, I think it's a tremendous waste of time to measure that 10px and convert it to ems -- 10px on my 1024x768 monitor is a far cry from 10px on my 1600x1200 monitor, nevermind on the HDTV sitting across the room. When you're designing and styling text for the web, better to:

• Assume from the start that users will consume your site differently than you do.
• Make decisions in your design, CSS and HTML that will consistently convey the content and hierarchy of your site, regardless of how it is consumed.
• Assume that the user knows better than you what a good base text size is for them.
• Use a reset styleheet — I like Eric Meyer's CSS Reset Reloaded — to set everything to that base size.
• Vary the sizes of elements relatively using ems.