Skip to main content

Kimberly Blessing

The Web (Browser) We Forgot

1 min read

Earlier this month I spoke at the O'Reilly Fluent Conference about the browser that truly popularized the Web in its infancy -- the line mode browser. The video of my keynote is online, as well as an interview where I talk about everything from the line mode browser to the problems of modern-day developers.

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

What Development Teams Can Learn From Experience Designers

1 min read

I'm speaking at Philadelphia's Emerging Technologies in the Enterprise conference on April 22, 2014 -- Philadelphia's "Day of the Developer"! In this talk, I share what I've learned from the Experience Designers at Think Brownstone for the technical audience that's interested in making things awesome. (abstract, slides)

Kimberly Blessing

Q&A with Technically Philly

1 min read

Some insights on how I built a 10-person tech team at Think Brownstone that's nearly half women, and other thoughts on diversity in the web/tech field. Read the interview.

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

Managing, Mentoring, and Hiring: Why is it so damn hard?

4 min read

Think sticker

The super-cool Think Brownstone stickers I gave away at BarCamp!

I had the privilege of leading a problem solving discussion at BarCamp Philly this past Saturday. The session was proposed at the last moment (while the first sessions were going on) in response to a few conversations I had over morning coffee -- I was amazed to end up in a packed room full of very vocal people! It's clear our community has a lot to discuss on the topics of management, mentoring, and hiring. Thanks to everyone for participating and making this such an engaging session!

Here are photos of the blackboard notes/mind-map -- they're a bit blurry, but you still make out most of the text and the lines connecting ideas.

  1. Define the Problem "Screen Shots": 1, 2, 3, 4, 5
  2. Mentoring focus "Screen Shots": 1, 2, 3, 4, 5, 6

A transcription of all the blackboard notes follows -- but I think the big takeaway of the session were the mentoring action steps we identified:

  1. Define mentoring: what are you trying to achieve?
  2. Carve out the time: make it important, protect it, make it part of everyone's job
  3. Ask: not for mentoring but for information, for input, "how can I help?"
  4. Do things together and make it visible
  5. Express thanks

Before you go through the full notes: I'm serious about getting together again to continue the conversation! Please leave a comment on this blog post, email me, or @/DM me on Twitter so I can be sure you get an invite to the meetup!


Define the problem

    • No mentoring at many places
    • Hard to mentor if you're not being mentored
      • No managerial/organizational support
        • Do you set aside time for mentoring activities?
    • No one gives a shit when trying to mentor
    • Bidirectional mentoring: [other party] not always interested
    • Finding people / the right people
      • People with potential
      • Headhunters [=] Noise
      • [Many] unqualified candidates
      • Depends on company: hiring for culture, skills, experience?
        • Do we even know what we're hiring for?
          • Speedy growth
          • Same job title (not description) means different things at different companies
            • Different responsibilities, different expectations (on both sides)
          • As person being hired:
            • Why am I being hired?
            • What am I doing?
            • Is it OK to ask questions?
      • Dilution of credentials
        • PhD [in CS] but can't code
        • As jobseeker, educationally over-qualified, less job experience
          • Resume format hasn't changed, how do you present yourself?
            • Cover letter still important!
          • For developers, where is the code portfolio?
      • What is the qualification to get through?
        • Puzzles
        • Quizzes
        • Essays
      • Can someone meet our expectations?
        • [Example: job posting asking for] 10 years of jQuery experience
    • Hiring
      • Tools are shitty and inhibit process
        • Broad job posting not effective
      • Expensive! Job portal posting and lots of asshats apply
      • [Managing/researching applicants]
        • Resumator + LinkedIn
        • Stack Overflow
        • Ranking candidates
          • Bullet Analytics
      • Where to post jobs locally?
        • Technically Philly job board - will have job fair in 2014
        • Local network and community
          • Be an active participant in community so people want to work with/for you
          • Most groups are for senior/advanced people
          • How to go from email to action?
        • How to find junior talent?
          • Campus Philly
          • Drexel Co-Ops (people love them)
    • At this point, we were 15 minutes into our time, so we voted on one area to focus on; the group chose mentoring.

Focus on Mentoring

  • This is a skill in and of itself!
  • Big difference between mentoring and training
    • What is the hidden curriculum in your organization?
  • Finding time
    • Carve it out
  • Care more!
    • How to make those NOT in this room care more?
      • How do we encourage more soft mentors?
        • Make it a requirement
  • Coaching
    • Helping people express themselves makes them better at what they do
  • Apprenticeship
    • Formal programs
  • Context/structure
    • "Soft" mentoring instead of formal
      • Team collaboration and valuing others' opinions?
      • Recognition is important
      • How to find a mentor as a junior person?
        • Look for someone who is passionate about what they do
        • Look for someone who is open
        • Show them what you're working on
        • Ask
          • We aren't taught to ask good questions
            • Are we hiring people who won't ask by looking for purple squirrels (super ninja rockstars are self confident)
            • [Nor are we taught] to recognize others, e.g. acknowledge someone in code comments
          • Conversation starters:
            • What's wrong with this?
            • What am I missing?
            • What have you tried?
    • Some organizations separate mentoring from management
      • [Why?] This introduces BIAS in management process
  • Why is this a corporate expectation? Why don't kids go out and find [their] own mentors?
  • Manager != Leader, Leader != Manager
    • Being a mentor is a differentiator

Mentoring Action Steps

  1. Define mentoring: what are you trying to achieve?
  2. Carve out the time: make it important, protect it, make it part of everyone's job
  3. Ask: not for mentoring but for information, for input, "how can I help?"
  4. Do things together and make it visible
  5. Express thanks

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

Shop Talk Show #85

1 min read

Chris Coyier and Dave Rupert invited me to join them on Shop Talk Show to -- what else? -- talk shop. We chatted about my trip to CERN, employer size, portfolios, and code-related stuff. Check it out!