8 min read
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.
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?"
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.
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.
4 min read
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.
A transcription of all the blackboard notes follows -- but I think the big takeaway of the session were the mentoring action steps we identified:
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!
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.
6 min read
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:
</LISTING>tag was left to render in the page (see picture).
<!-- -->) 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
<script>block would end up showing the user a whole lot of code!
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:
<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.
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.
1 min read
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.
My 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.
1 min read
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.