Skip to main content

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

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 </LISTING> 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 <hp1> and <hp2> 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 <style> or <script> 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 <P> 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!

Kimberly Blessing

Interview during LMB Hack Days

1 min read

I am so fortunate to have had the opportunity to participate in the Line-Mode Browser Hack Days at CERN. In this interview, I speak about why I think experiencing the line-mode browser is important today.

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

'Change' Is Not a Four-Letter Word

1 min read

A repeat performance of my AccessU keynote, delivered at the end of the two-day, online Accessibility Summit. If you're not familiar with the Environments for Humans conferences, check them out! (Powerpoint slides with notes)

Kimberly Blessing

Unspoken expectations don’t work

1 min read

Unspoken expectations don’t work. Then again, some expectations, when communicated, may just go a bit too far.

If you don’t care about the French toast, then perhaps you don’t care about anything is my train of thought on the matter, and if you don’t care about anything, then working for me doesn’t seem feasible, as I have an insatiable desire to be surrounded by people who care as much as I do.

Stanley Kubrick, Some Instructions to the New Guy Concerning the Preparation and Presentation of My French Toast