Skip to main content

Kimberly Blessing

The Web at 25: Lessons Learned, Forgotten, and Rediscovered

1 min read

I was honored to be a part of Denmark's first front-end focused web development conference, At the Frontend on November 4, 2014. There I talked about the history of the web through the story of my trip to CERN as part of the line-mode browser hack days project, and some thoughts on how lessons from then are still incredibly relevant today. (slides)

Kimberly Blessing

Giving Credit Where It's Due on Ada Lovelace Day 2014

3 min read

I haven't written a post for Ada Lovelace Day in a few years (last in 2010) and recent conversations have made one feel necessary. When the contributions and accomplishments of my female contemporaries on the Web are unknown to people just a generation behind, I get extremely concerned. After all, the making of the Web is the making of history in modern times. As I've pointed out before, we have the opportunity to document our times and lives unlike never before -- but data loss can occur. And it is.

Twenty years ago, when I was in college and learning how to create web pages, I pretty much had two sources of information: documentation written by TimBL and USENET newsgroups. But once I started working professionally, I realized that there was a wealth of information being printed on paper. And what I saw was that large numbers of these books on web development and design were being written by women.

Me and Molly HolzschlagMe with Molly Holzschlag

Women such as:

I wish I could tell you exactly how many books these women have collectively written -- I'm sure it's over 100 -- but quick searches of their bios and websites doesn't always make this data clear. Is it modesty? Do multiple editions make the numbers tricky? I don't know.

But when I mention the names of these women -- all of whom are still active online, many of whom are still writing (or speaking) about the web and programming -- to web developers today, I'm often met with blank stares. I'll have to mention that Lynda founded Lynda.com, (still!) one of the top online training sites, or that Jen co-founded the extremely popular ARTIFACT conference. I have to explain that Dori has helped run Wise Women's Web, one of the earliest communities for female developers online, and that we have Molly to thank for convincing Bill Gates and Microsoft to be more open about Internet Explorer development at Microsoft (there are so many articles to link to, but I want to link to Molly's old blog posts, which are gone *sadface*).

While my past ALD posts have been happy remembrances of people who've made positive impacts on my life, this post is written out of frustration -- and even a bit of anger -- that the contributions of these women are being forgotten or overlooked in their own time. Let's give credit where it's due. Comment or blog or tweet about the books written by these women that helped you learn your craft. Send them a thank you email or tweet. (In Molly's case, you can give to her fund.) Share this post or the links to these women's websites with someone who needs to learn about their foremothers. And just be thankful that women helped light the path for others by sharing knowledge about building the World Wide Web.

Kimberly Blessing

BlogHer '14: Preserving Your Online Content

4 min read

BlogHer 10th Anniversary Celebration

Earlier this year, I read (and raved about) Book of Ages: The Life and Opinions of Jane Franklin by Jill Lepore. One of the obvious realizations when reading this book is that today we have little first-source material of the average person's life from this era -- and especially little of it from women. It's only because of Jane's famous brother that her writing has survived -- and through that correspondence, we can learn so much.

That seems to be a theme for me, this year: I've been thinking a lot about how we document and preserve information -- stories, photos, videos, etc. -- online, whether for ourselves (ooh, the cloud), to share with family and friends (social media), or for posterity. I was first drawn to the web, 20 years ago, as cheaper means of communication... but like so many others, have realized the wealth of history we're documenting as well. It's important to me that we preserve that history... because, even though we think the Internet never forgets, it does.

So, when the good folks at BlogHer approached me about participating in this year's 10th anniversary conference, I thought this would be the perfect subject to talk about. Except I'm not talking... I'm running a Geek Bar instead! This means that I'll be helping bloggers who are interested in hands-on learning and help on how to preserve their online content. This post is a short summary of some of the material I expect we'll review and resources we'll need to reference, mostly for WordPress users (non-developers). Whether you're at my session or not, you may find this information useful and you're welcome to contribute your own! (I'll update this post later with anything else we cover.)


Backing up your blog

If you're blogging on a free or paid service, learn about what backups they're creating and whether or not you can get access to them. If you're paying for hosting and running your own blog, add a backup subscription service or set up your own backup solution.

  • For WordPress: VaultPress, Backup Buddy, and loads of other plugins.
  • If you're looking for something that will (likely) outlive you, submit your site to the Internet Archive for archiving (via the "save page now" form). Make sure your web page templates or robots.txt do not include NOARCHIVE.

Better broken links

Nobody likes getting a 404 (page not found)... and they're not good for search engines or archiving tools, if you want them to get your content! Help 'em out:

Moving and taking down content

If services go offline, you choose to switch providers or domains, or you simply choose to take content offline, you're going to want folks (and search engines) to know.

  • Familiarize yourself with the HTTP status codes. Here's a quick review of the most relevant ones:
    • 200 OK - this is what you want folks to get, in addition to your content
    • 301 Moved Permanently - if you're moving between services/URLs, you want this to be the redirect type
    • 302 Found or 307 Temporary Redirect - if you're having momentary issues and want to send readers somewhere else for a short time
    • 404 Page Not Found - the one we don't want people to get
    • 410 Gone - what you want to send when you've taken something down and don't ever intend for it to come back
  • If your site runs on Apache, learn about Redirect and Alias directives which you can set in your .htaccess file.
  • Yes, there are WordPress redirect manager plugins, too.

Solutions for all of your online content

What about your Facebook posts, tweets, Instagram pics, and other content on third-party sites? You can save those, too!

Kimberly Blessing

My Nerd Story

8 min read

Rosie the Riveter reminds you that we can do it!These are cute totems. I have the Tesla doll.

A few days ago, I was directed to Crystal Beasley's Nerd Story post by Kirin Kalia, my Bryn Mawr College classmate. She asked me to share my own "nerd" story.

I hesitated. I hesitated because I saw that Crystal was prompted to write her story in response to one of the current sexism-in-tech spotlights. (I'm not trying to downplay whatever is going on currently -- I'm just not following it and can't speak much about it.) I hesitated because I know that my story is laden with the exact kind of privilege that is often attributed to white men in technology. I know that some women don't so much see me as a potential role model as part of the problem.

Still, I considered it. Then I went back to Crystal's post and read the comments that had been left and thought, "I don't need to deal with this shit." Crystal's post had brought out the trolls, haters, and real misogynists. While I've read my fair share of hate mail, I am past the point where I want to deal with online harassment because it wastes *my* time to have to handle it.

After thinking about it some more, I figure that if my story guides or inspires just one other person, or validates something going on in their brain (or heart), then any grief will be worth it. So, here goes.


I grew up in a middle class family that was extremely focused on education. My grandfather was an engineer in the midst of the CAD revolution; my dad and aunt were pharmacists dealing with the computerization of their field. Math, science, and tech geekiness ran in my family.

I started elementary school in 1980 and, from day one, got used to seeing a variety of TRS-80s in the building. Soon, I got used to using them on a regular basis, first through the gifted program, and later through a before and after school program, which I've written about before. BASIC was my first programming language. I wrote programs to make sounds, change the screen color, print text to screen, draw shapes -- all of which culminated in me programming a TRS-80 CoCo 2 to play the harmony to "Yesterday" by The Beatles, while I played the melody on the flute.

TRS-80 CoCo 1My TRS-80 CoCo 1, salvaged in 2008. I don't like getting rid of old tech.

Meanwhile, at home, we had Pong, then an Atari 2600. Playing games was fun, but I wanted to write programs. I got a Commodore 64; in the summer of 1983, after seeing War Games, I spent weeks trying to program my own "Joshua" artificial intelligence. Thankfully, no one ever discouraged me from working on that fruitless program. I don't think they even knew that building an AI wasn't possible. I sure as hell didn't.

The Commodore 64 eventually became a 128 and was a mainstay for everything from gaming to doing homework to getting online. In 1985 or 1986, my aunt purchased an Epson Equity PC (8088) and thus I was introduced to DOS (version 2.11, and all of the upgrades from there!). She was using it for basic word processing; I quickly figured out how to do mail merges for her, create spreadsheets, and other more "office-y" type things with it.

As I made my way into junior high and high school, my interaction with computers was limited to home and the library. Whereas every classroom in my elementary school had a TRS-80 or an Apple IIe, the only computers in the upper schools were in special computer rooms, which were mostly used by the "business prep" students. Honors/gifted students, apparently, didn't need to use computers. At home, with more and more homework to do, my computer use became much more practical -- checking math and typing papers. There wasn't time for programming.

In reality, I didn't make time for programming anymore. It wasn't in the classroom anymore, so I suppose I didn't see it as important anymore. Although I started seventh grade already knowing some trigonometry, I went back to algebra. Yawn. Science was still fun, at least, but my language and music teachers were much more encouraging of my work and progress. I turned my focus to where I got feedback and positive reinforcement. By the time I graduated high school, I had dropped out of calculus but took AP French. I had skipped the one and only programming class at my high school -- but when I saw the homework assignments, I yawned again. They would've been pretty repetitive for me.

Thanks to my grandfather, I started college with a brand-new Packard Bell 486/33, which came with 4 MB RAM, a 120 MB hard drive, a sound card, a 2400 baud modem, and Windows 3.1 -- better than my boyfriend's! In my single dorm room, I had plenty of time to noodle with my new tech. Word 6 and NCSA Mosaic had just been released. I had accounts on AOL, Prodigy, and Compuserve but also quickly learned how to dial in to my college's UNIX server. That computer lasted me one year; I built a new computer the following year and upgraded it consistently, until I got to grad school and bought a fancy Dell machine with a Pentium processor.

At the same time, I was rocking my liberal arts education experience, with my intended romance languages major, until the reality of completing the quantitative (i.e. math) requirement reared its ugly head. I wanted to love calculus, but I struggled. Where to turn? Intro to computer science, of course. I figured it should be easier than suffering through more calculus. I didn't count on it changing my educational direction.

I wasn't a great student, that first CS class. Instead of really trying to learn something new, I relied on my existing knowledge and prior experience to get me through. But I guess it was clear that I "got" it enough to warrant the encouragement of the professor, my friend Deepak Kumar, to continue studying CS. So I did. It was as simple as someone saying, "Hey, you're good at this. Ever thought of majoring in it?"

Me in college with an X-TerminalIn the X-Term lab. I think Sarah and I were writing a program to play Konani.

Being a major in computer science at a women's liberal arts college with only one CS professor wasn't easy. I had to lobby the school to be a CS major, and I had to take classes at other colleges and universities in order to complete my CS requirements. I remember taking computer organization (my favorite subject) at Carnegie Mellon University, and being one of about four women in the hall of perhaps 200 people. It's only strikingly odd to me now; at the time, I knew I was a rarity, but it didn't really faze me. (Later, in grad school, the ratio was a bit better because the classes were smaller.)

I made friends with Sarah Hacker (yes, her real name) who had already decided on a CS major; she worked for campus IT services and helped me get a job. Because I knew UNIX, I made an extra 25 cents an hour! Sarah introduced me to HTML (and helped me fix my first markup bug) and I started cranking out websites on Deepak's server. Other members of the team taught me everything I know about software and hardware support. It was a perfect storm of interest, opportunity, and encouragement. The rest, as they say, is history.

Today, after 20 years of experience in large internet/tech companies (AOL, PayPal, and Comcast) and other organizations, I head up the web development team and growing technology consulting practice at Think Brownstone. I've architected and built some of the coolest publishing systems and web sites in the history of the internet -- and I still get excited when I'm presented with a challenge that requires strategic thinking, technical know-how, and organizational savvy. I've been able to take my experience and turn it into book contributions, conference presentations, and a for-credit CS class at my alma mater. I'm still a technology junkie, but as a manager and leader, I get the biggest kick out of coaching younger talent and helping them grow their skills.


Disney's Kim Possible

The moral of my story is: discouraging a young mind can stop its progress, but encouragement can help get things moving again. If you're an adult, figure out who you can encourage today. If you're a young adult, avoid the discouragers (as much as you can) and find the encouragers.

Write your own Nerd Story -- don't let it be written for you.

Kimberly Blessing

On the Writing Process

4 min read

I am not a storyteller.

This was the thought I had the other day, after reading Neil Gaiman's tribute to Lou Reed. Those guys are storytellers.

I love listening to stories. Reading stories. I love the way they take me on a journey. I'm able to just sit back, take everything in, have the plot laid out for me, the characters developed, and the whole thing resolved, all for my enjoyment and entertainment.

A good storyteller is a magical thing.

I bring this up because storytelling is an incredibly effective way of communicating. Because I am not a storyteller, communicating is often very difficult for me.

I recently published a blog post that took me over six weeks to write. Now, I wasn't working on it continuously for six weeks of course -- but I did have all of the important information I wanted to communicate identified six weeks ago. Structuring it so that it made sense is what took so darn long. And, by the time I published it yesterday, most people had moved on from thinking about that topic, and so it went over like a dud.

That's okay, I tell myself. I'm only writing for me: to practice writing, to capture my own thoughts. And then I call bullshit on myself, because I'm reloading the stats window and watching to see who retweets the link.

Once upon a time, writing wasn't hard for me. I just sat down and wrote and wrote and wrote. Creative writing, they called it -- and through 6th grade, it was among my top favorite things in school (probably after math and computer time and reading). Come junior high, I had to discipline myself and structure my thoughts to write five paragraph essays.

Ugh, five paragraph essays: an introduction, three supporting points each in their own paragraph, and a conclusion. I really sucked at those, and I have the bad grades to prove it.

Mr. Weaver, my history teacher, and my grandmother both spent a lot of time with me to help improve my structured writing approach. No longer could I just sit down and write, because the editing process made such a mess of my work that I couldn't look at it any longer. And so I began writing out individual sentences or thoughts on index cards, and sorting those into groups and then writing connector or transition statements on new cards and adding them to the mix. And, in the end, all I had to do was copy my index cards to paper and submit. Done. A+. I still have the first paper I ever wrote this way (on Henry Clay) -- and the supporting index cards! -- to show me that this approach works.

And this approach works for a lot of things. It's great for making slide decks, which I do a lot of in my work -- and with all of the practice I have, I do it rather quickly. I also wonder if this approach to writing didn't influence the way in which I code, since I really love the modular approach.

But when it comes to writing -- well, it's hardly writing, is it? I mean, it is, but it seems rote. Perfunctory. Emotionless. And so this is why I struggle to write now -- because I write from an emotional place. But my emotional place doesn't do well with logic and often communicates its point by feeding information between the lines, and so only the most careful of readers will get the point.

Storytelling is all about emotion -- great storytelling makes you feel something. Most of my writing falls flat from lack of emotion. But at least it gets the point across...?

So, what to do? Write and ramble and never quite get my point across? Or structure my thoughts, compose the thesis, defend it, all stocky and blocky and templatized and boring? How does one combine the two approaches?


PS: I wrote this in one sitting, and mostly in one shot straight through. The end is where I got hung up the most -- when I was trying to figure out what my point was. The opening and a few of the statements I wrote in my head, in the shower yesterday.

Kimberly Blessing

Code Archaeology: Dusting Off the Line Mode Browser

6 min read

Photo of an old IBM computer running the line mode browser, with the explanation page displayedThe line mode browser (LMB) info page, running on the line mode browser.

It's been over a month since I returned from my trip to CERN to participate in the line-mode browser hack days and I'm finally getting my photos and my notes in order. If you haven't read much about the event, Jeremy wrote an excellent summary of the whole experience.

I was on the "coding" team and spent a good deal of time reading through and tracing the logic of the line-mode browser (LMB) source code. It felt like every few minutes I was finding something new or interesting, and pointing it out to the rest of the team, so we could be sure to make note of a feature we needed to implement or something that might be a pitfall. I referred to this work as "code archaeology". Here are some of my more interesting findings:

  • The earliest style sheet (compiled into the browser) had six styles: normal, list, glossary, monospace, address, and heading. (Heading had a further seven nested styles for TITLE and H1-H6.) What changed with each of these styles? Left indent (two levels), right margin, alignment, capitalize states (two, one for each left indent), double spacing, number of blank lines before and number of blank lines after.
  • There's code in place to handle H0 as a heading level. It was mapped to the title heading style -- so if both TITLE and H0 were present, H0 would overwrite what was shown in the TITLE location (at the top right of the screen (see picture).
  • If you've been doing web development for long enough, you'll probably recall the ISINDEX element -- and perhaps, like me, wondered it was supposed to do. If it existed in a page, it added a keyword command to the list of options in the prompt (see picture). It doesn't look like this feature was fully implemented in the LMB -- I don't see any code that would return a list of pages matching the query. In addition, the LMB only recognized ISINDEX if the opening tag was in all caps.
  • Here's an HTML element that was new to most of us: LISTING, which is supposed to render plain text. The LMB code we were looking at had a bug, however: only the opening tag was parsed and any closing tag was left to render in the page (see picture).
  • Another element that we'd never heard of before was HP, for highlighted phrase. HP comes from SGML. It had the effect of forcing text into all caps. The LMB that we reviewed parsed and only.
  • Because of the way the LMB parses a document, HTML comments (e.g. ) are ignored -- even though there were no comments in any of the early HTML documents we reviewed. In fact, any unknown tag is thrown away as a "junk tag", yet its contents (what's between the opening and closing tags) are still rendered to the screen. Thus, a modern web page with a or block would end up showing the user a whole lot of code!

My handwritten notes from my time at CERN My handwritten notes tracing the logic of the LMB, with Tim Berners-Lee's original proposal in the background

I'm not sure that we explicitly discussed it, but it soon became clear that we were building a simulator that we expected could render both current web pages as well as the earliest markup found in the first web site. This led to review of some very old markup, written by Tim Berners-Lee himself, and lots of experimentation with the old IBM system we had with us, which was running the LMB. Some more fun discoveries:

  • The HEAD element doesn't yet appear in HTML -- it would have been parsed out as a "junk tag". That said, in some old HTML documents, you'll find HEADER tags surrounding the TITLE and NEXTID. Fortunately modern browsers handle this old markup pretty well, so we didn't have to code anything special for our simulator.
  • These days, we're used to surrounding paragraphs of text with opening and closing tags... and, back in the day, we just putt hem at the start of paragraphs. Originally

    tags were used as paragraph separators, to create space between paragraphs. This made the work of writing the simulator CSS, to render both old and new code correctly, a little tricky.
  • The LMB indicated a hyperlink by placing a number in brackets following the link text, e.g. [1]. If your link text was more than one word, it might be confusing or hard to determine what text was part of the hyperlink. That said, the list command would show all of the hyperlinks in a document... but it was only helpful if your URLs were descriptive (see picture). The LMB could be started with flags to disable the showing of hyperlinks, which may have been useful when also running in non-interactive mode -- perhaps when trying to cat contents to files for storage or printing.

You, too, can get the line-mode browser source code and read through the main file (www.c). See what jumps out at you!

As I've expressed before, I'm concerned that many web professionals don't understand the history of the web and thus are doomed to repeat past mistakes. My biggest hope is that anyone who writes code for the web today will spend just a few minutes using the LMB simulator to browse the first web site as well as to check out their own site -- and notice, at the very least, that well-marked up content was and still must be the foundation of the web, in order to have a decent experience, regardless of browser capabilities. Good markup never goes out of style.


Kimberly Blessing

Want to become an expert? Study (web) history

5 min read

Lately I've been spending a lot of time thinking and talking about the past.

I'm at the airport awaiting a flight that will take me to the Line-Mode Browser Hack Days at CERN. CERN, perhaps presently most famous for being the home of the Large Hadron Collider, is also the birthplace of the World Wide Web. More on that in a moment.

Screen shotMy first personal web site, circa 1997

Twenty years ago -- What the hell? Where did the time go? -- I started college. I arrived at Bryn Mawr College a French major, soon to switch to Romance Languages. My Italian professor assigned us reading on a Web page. I was one of the few people in my dorm to have a computer (and modem! and laser printer!). I had email before I got to college, on both AOL and Prodigy. Bryn Mawr had a gopher space, but no web site -- in fact, there were only about 500 web servers up and running at the end of 1993. And yet, that seemingly meaningless introduction changed my life. I took computer science classes. I changed my major to computer science. I started building web sites -- heck, I designed and built the first web page to be hosted at www.brynmawr.edu. For me, that was the start of it all.

And so here we are today. You, reading. Me awaiting my flight to Geneva. To CERN. Holy freaking crap! Understand that, for me, this is akin to visiting Mecca, except I am worshiping ideas, and code, and technology, and the propagation of all those things that has help fuel the evolution of our world into its presently hyper-connected state.

But I must admit that I was surprised, when telling some other web developers about my trip, that they didn't know about CERN's relevance to the web. The popular history of the Internet as an American creation dominates, and it has consumed the WWW creation story for some. So I educate and inform, to set things right, to help those whose careers are based on HTTP and HTML understand their domain's history.

Now, here's where I get preachy, because I run into scenarios like this -- where a web developer will make statements about web-related history that are completely wrong -- frequently. "Oh, IE doesn't support inline-block." Wrong, it has supported inline-block for a long time, but it couldn't just be assigned to any old element. (I've heard this one a lot lately -- perhaps because I'm interviewing and one of the coding problems I give can potentially be solved with inline-block.) "Old browsers don't support the HTML5 doctype," is another popular one. Misunderstanding the origin of CSS3 properties, incorrectly attributing computer accessibility to web accessibility, explaining IE compatibility mode based on one or two simple tests rather than reading the documentation -- even attesting to a lack of JSON support prior to 5 years ago (?!) -- are things I've encountered lately.

I admit that I am quite privileged to have, essentially, grown up with the web. I've been active with it, as a user and a developer, almost as long as it's been around. I do fondly remember using both Lynx and Mosaic to not just surf the web, but also test my own sites. I remember "playing around" with CSS to layer text, and trying to get it to work in both Netscape 4 and IE 3.

But I digress -- this isn't about me. This is about getting other web professionals to better understand our field. To be correct in what they say about the past, when trying to educate others. To not make false statements, based on lack of knowledge or direct experience, which lead to wrong assumptions and misinformed decisions about code and architectures.

I realize I sound like a crotchety old geek, complaining about the young whippersnappers who don't respect their elders. This isn't the case at all. I've had the pleasure of working with many younger people, or just less-experienced people, who have taken the time to learn about the web's history. (Admittedly, some of those people were required to, when they took my course on web app development.) And just knowing facts about history doesn't do much good, without analysis or thought of impact, for today or beyond.

Genuine curiosity and a desire to learn all that one can is ultimately what makes an expert. And, truth be told, any real "expert" will be the first to admit that they're hardly such -- they're still on the quest to become experts, themselves.

So, here I am, about to board my plane, hoping to enrich both my understanding of web history, and yours. Assuming I haven't entirely turned you off, I hope you'll follow my travels on Twitter.

Required Reading

Kimberly Blessing

Web Developer Job Search: Your Resume

6 min read

I estimate that I have spent a full work-week, over the course of my career, reviewing web developer resumes. That's enough time to produce some strong opinions on the topic. Allow me to finally continue the Job Search thread by sharing my advice for creating a top-notch web developer resume.

Resume Format and Structure

Your resume format should work to highlight your strengths. The chronological resume, perhaps the most traditional format, fails in this regard. A functional resume does a much better job of highlighting your experience in a specific role, but most web developers are good at more than one thing. I suggest mixing aspects of the two formats, organizing them in a way that makes sense for you and your strengths -- then you'll have a resume that stands out.

Here are the general sections found in a great web developer resume. With the exception of the first two, the rest can be ordered and/or further broken out according to your needs.

  • Objective: If you're searching for a job, you ought to know what you're seeking! Customize your objective, as needed, when replying to job postings. (Note: If you're not actively seeking a job, but still want to have a resume posted online, it's okay to omit this section.)
  • Summary of Qualifications: It's a cheesy headline, perhaps, and all too often the summary is filled with buzzwords -- but I have read really compelling summaries that made me want to know more about a candidate. Focus on describing your strengths and what you contribute to an organization.
  • Skills: This is where the keywords and buzzwords will start showing up. That's okay: you'll back them up with evidence in the other sections. You can subdivide this section in any number of ways: Technical vs. Soft Skills, Front-End vs. Back-End Skills, Design vs. Development Skills, etc.
  • Professional Accomplishments: Here you can include project accomplishments, awards, public speaking engagements, publishing credits, or descriptions of really awesome things you've accomplished. Like the Skills section, you can also break these out separately.
  • Work Experience: If you've done any combination of full-time work, freelancing, and volunteering, this is the most generic title you can use for your work history. Some people like to break out their professional experience from other work, but I think that can undermine the importance of having taken on freelance or volunteer work. If you list accomplishments for each job in this section, don't repeat them elsewhere, and vice versa.
  • Education: I don't like to see this section missing from a resume. Haven't gone to college? That's okay. Be proud of what schooling you have made it through and list it here. Oh, and that includes training programs, conferences -- anything you've forked out money for that you've learned something from!

Required Information

If your resume were to consist of only two things, it should be these:

  • Contact Information: You'd think this would be a no-brainer, but I have seen resumes where developers didn't list a phone number, email address, or personal web site (more on that below). In my opinion, it's a waste of space to display your full home address, especially if you are looking to relocate. No one's going to snail-mail you an invitation to interview, so city and state will suffice. HR will collect the rest of your contact information later.
  • URLs: I wish I could tell you exactly how many of those ~500 resumes didn't include a single URL... but my gut says that at least half didn't feature even a personal web site URL. Seriously? If you're a web developer, you should have some URLs to share. If you're brand-new to the field, put some of your school projects online. If you've only ever done intranet-type work, get permission to copy parts of the code and make it available, or create other projects of your own to demonstrate your skills. If you're serious about getting a web development job, you need this.

On the flip side, don't waste space on these bits of information: references (or the phrase, "References available upon request"), GPA, salary requirements, or personal information (except if you have hobbies that would be of interest to another geek and would increase the likelihood of getting invited in for an interview).

Frequently Asked Questions

Does my resume have to fit on to one or two pages? No, I don't think that it does. However, I think it's nice if a resume is so well edited and structured that, when printed, it fits to exactly one or two pages (one page if you're young, recently out of school, or switching careers; otherwise two pages). However, if you truly have so much awesomeness to report, then, by all means, go on! If you're really that super-duper, I'm sure I'll want to know all about it.

Does one resume fit all jobs? NO! Don't be afraid to tweak your resume format or content to the job you're applying for. In fact, if you have diverse enough skills and interests (design vs. development) you should probably have completely separate resumes for these purposes.

I am graduating soon and don't have much web development experience. What can I do to beef-up my resume? Use the "Objective" area to make it clear that you're looking for an entry-level position. Highlight your strengths in the "Summary of Qualifications" area and place the "Education" section next, so it's clear you're just coming out of school. List your technical skills, as well as any soft skills that you can support with extra-curricular or volunteer work. If you have been active in a tech community or have attended technical or web conferences, list those.

I'm switching careers. I've taken some web design and development courses and done some small projects. How do I reflect all of this in my resume? First, don't hide the fact that you're switching careers! Your prior experience, even if in a completely different industry, has (hopefully) taught you how to deal with people and has helped you understand your strengths. Start your resume with an "Objective" statement that spells out your desire to move into web development. Then list your skills, training and experience with the web so far before providing your employment history and other educational details. Highlight any experience that translates across industries, but otherwise keep the non-web details short.


I hope the above helps you create an awesome resume. Remember, your resume (supported with at least one awesome URL) helps get you in the door for an interview, so take some time to craft one that truly reflects you!

If you have questions I haven't addressed above, I'm happy to accept them in the comments below.

Kimberly Blessing

Celebrating Ada Lovelace Day 2010

8 min read

My Ada Lovelace Day post is a two-parter: the first part, recognizing two women who inspired me in math and computing; the second, recognizing Milly Koss, an inspirational and accomplished female computer scientist.

Ada Lovelace Day is an international day of blogging to celebrate the achievements of women in technology and science. Learn more

Mrs. Smarkola, Miss Herrick, and the Dawn Patrol

Article about The Dawn Patrol From the Grace Park Mini News, an article about Dawn Patrol by yours truly, circa 1985.

I am so fortunate to have been raised in the 80s, during the emergence of the personal computer. My school, Grace Park Elementary, and my teachers were excited about the TRS-80s and Apple IIes in the classroom, and many kids had Commodore 64s at home. Our teachers saw us get excited about learning; we were having fun playing with new toys our parents never had.

Our librarian, Mrs. Smarkola, was one of my most favorite people at school. When I think of her, I always imagine her with a large book in hand, head down, adjusting her glasses, focused on her reading. But I also remember her running the classroom full of typewriters and computers which was across the hall from the library. She'd walk from computer to computer, typing commands, turning them on or off, inserting tapes or disks, making sure each computer had an instruction sheet or book for the next activity. Around the time of fourth grade, a few of those computers moved into the library itself, and the whole school used them to check out and return books -- under Mrs. Smarkola's watchful eye, of course.

My fourth grade teacher, Miss Herrick, was one of those teachers that all of the kids in school were afraid of. Kids talked about her being "hard" and "mean" -- but when I got in to her classroom, I was in heaven. You see, Miss Herrick loved math. I loved math. We were a perfect match! She frequently gave us math quizzes with long division problems, which I always aimed to complete first -- because the first to finish got to "play" on the computer we had in the classroom. I'd guess that I spent more time on that computer than anyone else, and I think I was also the classroom "computer aide," to help other students with it. (BTW, to this day, I love doing long division in my head when I'm bored.)

So many of us kids at Grace Park were interested in computers and learning, that our awesome principal, Dr. Joseph Fleischut, authorized a program called "Dawn Patrol" which was run by Mrs. Smarkola and Miss Herrick. For kids who signed up and got to school about 30 minutes before the opening bell, it was a time to use the computers, typewriters, and library. As you may have guessed, I signed up nearly every day. It may have been during Dawn Patrol that I programmed a TRS-80 CoCo 2 to play the harmony to "Yesterday" by The Beatles, so that it could accompany me as I played the melody on the flute. (When I got to perform at the district concert with the computer, it choked under the hot lights of the stage, sadly.) It also may have been there that I first attempted to program a Joshua-like AI from WarGames. I definitely spent time playing the Oregon Trail and Carmen Sandiego games there, as well as being questioned by Eliza. But what I remember with the greatest certainty (and the utmost thanks!) were the ways in which Mrs. Smarkola and Miss Herrick (and Dr. Fly, too) encouraged me, nurtured my passion for math, computers, reading, and learning, and always praised me for my accomplishments -- key factors which recent studies say are crucial to getting more women in to STEM.

Adele Mildred (Milly) Koss

Milly Koss and Me I was introduced to Milly Koss in September 2006 when a historical marker was placed at the site of the Eckert-Mauchly Computer Corporation.

Milly Koss "had a distinguished career of more than 47 years in all phases of computer technology, implementation and management, including applications design and development, software/hardware selection, database technologies and computer security." Her name is known to some -- but not enough, in my opinion.

Milly was raised in Philadelphia and attended the selective Philadelphia High School for Girls. She earned a scholarship to attend the University of Pennsylvania in 1946, at a time when schools were primarily giving spots to veterans. She graduated in 1950 with a degree in mathematics. In the early days of computing, women were seen as ideal computer programmers due to their "patience, persistence, and a capacity for detail." Of course, in order for a woman to get one of these jobs, she had to have a degree in math and not be married. Milly Koss qualified on the first point, but not on the second: she was engaged. The first company she interviewed with rejected her for this reason.

Fortunately, she was in the right place -- Philadelphia was home to the Eckert-Mauchly Computer Corporation and, from the way Milly describes it, I imagine it to be a workplace much like any modern internet company -- except that 40% of their programmers were women. Milly interviewed with Dr. John Mauchly, who she described as being very nice, flexible, and open. He gave her a wonderful, exciting, creative job -- working with the UNIVAC.

Milly worked with Grace Hopper and was responsible for developing Editing Generator, a problem-oriented language for computer-generated reports, in 1952. Milly was interested in what "computers could do for programmers... how it could help programmers program." She also worked on sort routines for years, which she calls "the quintessential program for machines." She reminds us that today we should be grateful for that early work in automated programming, interpreters, assemblers, and compilers.

By the way, much of this she did while working part-time and remotely! According to Milly, when informed about her pregnancy, Grace Hopper told her to "take it home" -- meaning, the work. Milly would go in to the office one or two days a week, otherwise working from her dining room table. In an interview with Kathy Kleiman (who is the driving force behind the ENIAC Programmers Project), Milly said:

"What’s funny about that period, I’m not sure who my boss was. This was such an unstructured environment… Once I had a child they let me continue to work the way I wanted to. I inferred from that I was of value to them. Nobody lets you work that way unless they are getting value. I got increases. I got paid fairly well. Eckert & Mauchly was pretty good that way… There were no models, they didn’t care how you worked. There were no preconceived notions as to the way you could contribute. You did not have to be in the office…. We did not have huge management teams. We did incredibly new and exciting things and nobody had a problem.”

Milly later went to work for Burroughs Corporation, Philco, and Control Data Corporation, and Raytheon. At Burroughs and Philco she continued her flexible work schedule and would send her work in by mail! At CDC, she worked with early graphics algorithms and interfaces including light pens. Then Milly moved to Harvard University, where says she finally started feeling the hierarchy and loss of flexibility. She spent 27 years at Harvard, in multiple roles. She applied data management expertise to applications for the school and led an R&D effort to develop one of the first data warehouses, the Information Utility. She served as Associate Director of the Office for Information Technology and as the Information Security Officer for the university.

Milly retired in 1994. In 1997, she received a Pioneer Award at the Grace Hopper Celebration of Women in Computing. In 2000, she received the Ada August Lovelace Award from the Association for Women in Computing. With her many years of contributions to the field, I'm sure she also inspired many people -- women and men alike.

Additional Resources

Kimberly Blessing

Review of HTML & CSS: The Good Parts

3 min read

HTML & CSS: The Good Parts

O'Reilly's HTML & CSS: The Good Parts by Ben Henick is a new book to educate and aid web professionals in building quality web experiences. A quick disclaimer about this review: I worked on this book as a technical reviewer and the author is a colleague and friend.

This book is primarily for those who have some experience with HTML and CSS and want to refine their skills -- but even front-end code ninjas will find some valuable reference material in this book. While the title implies a focus on HTML and CSS, Ben takes the time to touch on a number of related topics, such as the client-server model, creating usable interfaces, image optimization, and web typography -- thus giving the reader greater insight on the wider range of knowledge and skills it takes to build a quality web site.

One of my favorite sections of the book is chapter 4, "Developing a Healthy Relationship with Standards." Ben gives an excellent explanation of the history and benefits of standards adoption and then wraps it up with 10 rules for "standards-friendly" development. If you're still trying to make the case for adopting standards where you work, definitely check out this chapter.

If you've read any of the "Good Parts" books then you know that these books also highlight the "bad parts" and "awful parts" of the subject matter. While Ben gives a good overview of the browser wars as context, he spends a number of pages calling out the various issues with Internet Explorer. (I like to think that I helped tone down some of the harsh criticism he originally wrote by reminding him of how advanced IE6 was at the time of its release.) He goes on to explain the concept of graded browser support (something near and dear to my heart) and hits on a number of seemingly nit-picky but important concepts which standardistas care about.

It's really amazing how much information Ben packed into this 352-page book -- far too much for me to address here. Besides touching on HTML5, there's a helpful glossary and numerous reference tables. As I'm writing this review, in fact, I'm sticky-noting the book so I can easily find reference information that will help me in my day-to-day work. That said, you can also sit down and read the book cover-to-cover. (Ben's an incredible writer.)

If you're looking to enhance your skills, improve the quality of your work, find a better job, or even if you just want to have a backup brain handy, I recommend HTML & CSS: The Good Parts.

HTML & CSS: The Good Parts
  • HTML & CSS: The Good Parts
  • by Ben Henick
  • Published by O'Reilly Media, ISBN-13: 978-0596157609
  • Companion web site
  • Buy it from Amazon