So these are a bunch of scattered thoughts, that together are my attempt to honestly describe my own experience.

1. A little story

I didn’t start programming until I was in high school. I was never even aware of programming until I took my first class, I think it was my sophomore year. (We wrote Hangman in Pascal.) Honestly, it just never crossed my mind.

At that point, I was already behind. Because real programmers start when they’re 8, don’t they? Real programmers get started seemingly at birth, and know what they’re meant to do right away – there aren’t really other options. (I’m speaking in stereotypes, of course, but they are stereotypes that the field itself promotes.)

When I started college I realized how far behind I was. I did well in my first couple of classes, but I wasn’t the best. And other things seemed so much easier – writing was easier, and art was, and all of these other things. So I didn’t stop programming, but I switched out of CS into InfoScience, and made up a Digital Art major, and did all of this other stuff. (Not sticking with CS is my biggest college regret.)

When I graduated I decided to become a designer. After all I wanted to work in the tech field, but I “wasn’t smart enough to be a programmer”, and with my love of art, design seemed like a good compromise. Besides, that’s what nerdy chicks do – they become designers. Right?

I was fortunate enough to explore the design and UX field at a company where I could easily switch back to programming. And I did, once I realized that design wasn’t for me.

I learned some valuable things from this experience. But how much better would I be at programming now if I hadn’t taken that 2-year detour? How much further ahead would I be if I had had the self-confidence to stick with CS, and the understanding that I could actually catch up, if I just worked really hard?

This has to do with gender because it has to do with stereotypes, and with how I measured myself against those stereotypes and found myself lacking. And you’d think I would have learned from it, but I still do the exact same thing.

2. Ambient sexism

I have never had anyone personally treat me rudely because of my gender. I’ve never been the target of serious disrespect, or been denied an opportunity as far as I know. (I’ve had dudes be really awkward or try to hit on me, but whatever. I can deal with that.)

This is a totally awesome thing! It’s a big change from when my mother was an engineer in the 70s. (She has some stories that you might not believe, about behavior that was just accepted back then.) Progress has happened, and we nerdy chicks owe that generation a lot.

It also makes this kind of difficult or confusing to talk about. Most of the programmer guys that I know are totally awesome people, and would never think of themselves as sexist. And yet there’s all of this general objectification and disrespect that floats around in programming culture and makes it really hard to be female in certain venues. Call it ambient sexism if you will.

A lot of that stuff comes from people who would probably be perfectly nice to me as an individual. How do these two things reconcile?

3. Yes, you are.

“Oh, we’re not talking about you” is never a valid excuse.

4. Get to know me, I dare you.

I find that as soon as I get the chance to actually work with someone, gender instantly becomes not an issue. As soon as I get the chance to show what I can do, to get into technical topics, to talk geek with someone, then all of the awkwardness and misbelonging disappears. They stop seeing me as a woman and start seeing me as a programmer, and then things are fine.

(The tricky thing is that I’m actually both.)

5. female X awkward = even more awkward!

I’m a great big introvert, as many programmers tend to be. I’m also shy – not cripplingly so, but it still takes a lot of energy and mental preparation to face a big group of people that I don’t know.

Gender is not the root of this problem, but it serves as a magnifying factor. When I’m the only woman in the room it makes it even harder to connect, harder to overcome my natural shyness, harder to find a point of entry to the conversation. It serves as an isolating factor, and makes the barriers that already exist that much higher.

6. I <3 nerds

Talking to smart programmers is one of my favorite things in the world. Talking to smart female programmers is even better, because they tend to be “my type of folks”. But I’ll geek out with anyone – as long as I don’t feel too intimidated by them.

7. Learning French

You learn how to get by, in this man’s world. You learn to make yourself bigger, to consciously take up more space, to pitch your voice lower and louder to be heard. You learn how to dress to minimize staring, and when to choose a t-shirt over a blouse. You learn what topics to steer away from in conversation, and which threads on websites to never ever click. You learn to fit in, to minimize the differences that would keep you separate, to adapt to the common culture. It’s like learning to speak French. You learn, or you leave.

People learn and live in other languages every day; but native speakers will always have the advantage.

(Sometimes two cultures collide and create a new language, a creole, that contains concepts from both of its parents. I want to know, how do we go there?)

8. Community

There aren’t too many place where I really fit in, so when I find one I tend to become attached. Because of this, I’m completely sympathetic to guys who have found a community and a home within programming culture, and who want to preserve and defend that culture.

I can understand how it might seem unfair and threatening when people talk about wanting to change that culture, like in that famous study about geeky environments and tech appeal. Because they value that culture the way it is right now; it’s brought good things to their lives and they don’t want that to be lost. That makes perfect sense to me.

But dammit, I’m here too, and I also want community!

There has to be a way to do both – to extend the culture, without replacing core functionality.

9. It’s not about the dick jokes.

I actually have a pretty coarse sense of humor. So I’m fine with the dick jokes, seriously. I’ll #twss with the best of them – just check my Twitter feed. I think my sense of humor is pretty standard for the field.

Except. Except it all changes when I’m already feeling unsafe and isolated. When I’m feeling in a hostile environment where I have to be on my guard. Then the joke that I might find hilarious under better circumstances suddenly starts to feel like a threat – just another reminder of how much I don’t fit in.

It’s not about the dick jokes, it’s about the overall atmosphere.

10. The relevant parameters

I love programming. It’s not just what I do, it’s What I Do. Nothing else gets me into a state of flow so easily and so quickly. I love it for itself: for the joy of unraveling a complex system and seeing it all take shape in your head; for the love of creating something that’s minimal and effective and Right, with nothing extra added and nothing left to take away; for the satisfaction of making something with my own hands that other people will use, that improve their lives in some minor little way. (The fact that it makes me money is a nice side effect.)

None of this has anything to do with gender. What does have to do with gender is all of the auxiliary stuff, all of those human and social things that turn out to be so important in careers.

So far the first thing has outweighed the second, and so I stay. But I can see how that calculation might be different for someone else.

I can see how easy it might seem to go and find someplace friendlier, where it’s less of a struggle just to be.

11. Hills

There are two runners. One is running on perfectly level ground, and the other is struggling up a big hill. They both might get to the same place eventually, but which one is going to have the easier and more pleasant time?

Being female in the tech industry is that hill.

(And yet. Runners run hills to get faster, don’t they?)

12. Hard words for a hard problem

So maybe you have to work twice as hard to be accepted. Guess what? Go out and work three times as hard.

Do you have to be twice as good to be heard? Be four times as good, and be impossible to ignore.

Feel like you have to know twice as much? Learn five times as much, and then teach others.

Be constantly learning. Work your ass off. Put in your 10000 hours, and then put in some more. Make your skin thicker, and just go on.

Yeah, it can seem unfair. Guess what? Life’s unfair. The only way forward is to suck it up and go make some awesome stuff.

You can let this make you miserable, or you can let it make you better.

(I’m talking to myself here.)

13. That’s what she said.

Yes. Yes, it is.

During discussions about accessibility, I always wonder whether accessibility goals should be different for different types of web projects. Are there cases where accessibility is less important? And if so, what are the relevant differences that make it that way?

“The web should be accessible” is an easy blanket statement, but the web is very diverse. Many sites and applications exist that aren’t accessible in various ways, but are still useful and popular. Are we to say that these sites should not exist at all, and everyone else misses out? On the other hand, people have a right to get the information they need and perform the tasks they need to perform. How do you balance these two things?

For websites, whose primary purpose is conveying information, it’s no question to me that the site should be accessible. First off, most sites that exist to convey information want it to be widely seen; accessibility is in their own best interest. These also tend to be the sites where accessibility is easiest and can be achieved by following simple best practices. There may be some flashy ajax stuff going on, but it tends to be window dressing. At the worst case you might have to provide textual alternatives to rich media like videos or Flash.

But there’s another category that I think is much more of a grey area, which I’ll call web apps. It’s tough to categorize web apps, so I’m going to take the lazy way out and say that they are the complement set of the above category, containing any site whose primary purpose is not to convey information. So if the app exists to let people create something, or to play a game, or to do something complicated with data, it may be reasonable for the app’s creators to set the bar higher in terms of what is required to use that app. This may mean requiring javascript or the use of a mouse, or the ability to view visual images, or even specific browser features. (You won’t be using Bespin in IE, for example.)

Another way to look at it: Importance and relevance

Anything that’s both important and relevant to a large number of people — such as job applications, reference information, and government agencies’ sites — should always be widely accessible in as many ways possible.

If it’s important but not widely relevant, consider your target population and gear support towards their specific needs.

If it’s widely relevant but not important to people’s lives, like for example many browser-based games, prioritize accessibility based on a cost-benefit analysis of how many people you’d like to reach.

If it’s neither important nor widely relevant, go nuts; knock yourself out with crazy features.

I feel like this could be somewhat controversial; what do you think? Should there be a difference in how accessibility is prioritized for different types of projects on the web?

Probably the most growth is going to come in the large-screen touch category (mainly because it’s starting from the lowest place overall). If anything, I would expect the small-screen mouse input category (i.e. Blackberries) to decrease — but not to disappear entirely, because businessmen sure do love their physical keyboards.

Making web apps that work with minimal adaptation across all four quadrants is the challenge. (And you thought dealing with different screen resolutions was hard?)

Server-side javascript has been a hot topic for awhile now, especially since node.js was announced. But after reading about it here and there, a big part that I felt I was missing was the “why”.

I mean, for those of us who really enjoy javascript (which I do), enough said. Javascript on the server? Hell yes!

I realize, though, that most of the world doesn’t share my love of this particular programming language. So, while at jsconf this past weekend, I tried to collect some reasons why everyone should consider javascript on the server.

1. It lets you write things once instead of twice.

The more logic that you’re running on the client-side, the more code you have to write twice: once in your server-side language of choice, and once again in javascript. The classic example here is validation code. You want to validate on the client-side for a good user experience, but you have to validate on the server for security reasons. As a result, you have two whole different sets of validation rules to be written, updated, and maintained over time.

Now wouldn’t it be great if that could be just one piece of code? You’d cut your codebase in half, and make maintenance a lot easier.

2. It could make progressive enhancement easier.

Server-side javascript has the potential to make progressive enhancement a lot easier, by requiring you to do less special planning for it. With a hijax-type approach, which seems to be the current best practice for supporting non-scriptie users, you have to create your site first without javascript, and only then add all of the dynamic stuff in.

In a world of limited budgets and tight deadlines, this may seem like a lot of extra work to support a very small number of users. But with server-side javascript, there’s the potential that for those users, you could just run the javascript on the server-side instead and return the page in its new state.

I’ll be honest, this would probably be a pretty slow experience with a lot of extra page reloads, but it may still be better than the unusable state of many current sites with javascript turned off. (There was a fab talk at jsconf by Philly’s own Jenn Lukas on the sad state of no-script support on major sites.) At least this way people could get what they to wanted, even if the experience was slow.

This isn’t a topic I’ve heard discussed very much yet, but if there was a way to make progressive enhancement basically automatic, that could turn out to be a big win.

3. It lets you stay in one headspace.

Ok, this could be considered a weaker reason, which is why I put it third. But it’s well-known that switching between tasks harms productivity, and it’s much better to focus on just one thing at once. Now consider that many developers are generalists who do some server-side and some client-side code, and as a result have to hold (at least) two different languages in their heads, with two different sets of APIs and quirks and syntaxes and styles, switching between them all of the time.

I know that I personally try to use console.log in Objective-C, trace in a javascript file, or echo in a Flex app at least once a week. And that doesn’t even get to the subtler traps of forcing one language into another’s paradigm.

Now imagine that you could take a large portion of that brainspace and devote it to just one thing. One language, one syntax, one set of patterns, one set of common bugs. Wouldn’t it make you more efficient? Wouldn’t you get so awesome and productive and ninja-esque at that language?

Because.

I’m sure using js on the server has its downsides as well, but I don’t really know enough yet to speak to what they are. But I’m convinced now that it’s more than just a toy, and is worth at least a look from people who care about the good things above.

Lets you draw in 6-way radial symmetry. I got the idea from those folded paper snowflakes that everyone used to make as a kid.

I’m liking canvas, it’s easy to do some fun stuff with. And I really like it not being the black box on the page that Flash tends to be.

More of these to come, probably.

This got me thinking about other transformations you could do over the same set of numbers. At the same time, I’ve been wanting to start playing with canvas, for possible future infographicky goodness. So I thought, what better way to get my feet wet with canvas than to visualize PI as a line chart! And just for fun, I put it on a circle too, since, y’know, PI. (I was going to make the lines nice and curvy, but it’s the weekend and bezier curve math was not being my brain’s friend, so straight lines for now.)

So, without further ado: the digits of PI visualized as a line chart, using canvas. (Also: I threw in excanvas, but didn’t actually bother to test it in IE, so if it doesn’t work, um… try a real browser, I guess? Cheers.)

(By “design”, I’m referring to visual/experience/industrial/graphic/architectural/service/fashion design — all of the fields that deal primarily with creating some sort of effect or experience for a human being. I am not referring to things like the design of circuits or of hardware. Those fields are different.)

The relevant difference that I see is that really great software is usually quite modular. Software engineering principles like encapsulation and loose coupling mean that lots of people can work on something, each one taking a part, and still come out with something that integrates quite well and does what it is meant to do. This is probably what makes open-source projects work as well as they do.

On the other hand, really great design is incredibly integrated. If you look at a great experience, one of the striking points is the way in which every single aspect, from building architecture to package design to software interfaces, makes an integrated and coherent contribution to the experience. It has a personality — one personality, not a schizophrenic array of different voices all talking at once.

I wonder, given its coherent and integrated nature, whether great design is fundamentally incompatible with the open-source model. After all, “designed by committee” is a common insult, but there isn’t really an equivalent phrase relating to programming.

On the one hand, specializing in one technology / programming language / skill allows you to gain a depth of knowledge and experience that you can’t really fake. Some have argued that it takes about 10,000 hours of practice to become an expert at something; if you practice a skill for 30 solid hours a week, that equates to about 7 years. After 7 years of working with a skill, I have to imagine that you know pretty much everything there is to know about it, and your intuition has got to be pretty solid on any question or problem that comes on.

On the other hand… technology and practices change so rapidly, and you have to flow with the river or you’ll be swept away. If being a generalist means that you have the ability to rapidly teach yourself new skills, and the willingness to learn as you go without hand-holding, then arguably generalists are better prepared to deal with the changes that inevitably happen. Also, like I discussed in my post on designing and developing, being able to cross between fields allows you to make connections that might not otherwise be made.

Perhaps it could be seen as a risk/reward tradeoff.

Specializing is like investing in stocks, with more risk and a potentially higher reward. Specialists have an easier time getting hired — their resumes fit the traditional ‘check the box’ model — and they quite possibly get paid more for their expertise. On the other hand, they run a high risk of their skills becoming obsolete, or at least less valuable over time.

Being a generalist is like investing in bonds, with a slower payoff but much less risk. Generalists have a harder time making people understand what they do, and may have a harder time demonstrating their worth to prospective employers. But they will always be able to adapt when the technology or the environment changes, and figure out how to make themselves useful in some way.

And perhaps there’s a happy medium of sorts, where it’s possible to keep learning and using one central skill, while always having a rotating cast of new things at the periphery. It may take longer to become an expert this way, but like a balanced portfolio, it seems to offer the best mix of reduced risk and potential reward.

For myself, the nature of my current job is very general. I have to be able to pick up whatever tool is best to convey the idea at hand, whether that be css/javascript or Flex or Flash or PHP or JSP, or whatever the next thing will be. (And I have to be able to adopt the design mindset as well, which has its own set of skills that aren’t as easily defined.)

I would say that css/javascript is really my core expertise, if anything is. I’ve been doing a lot with Flex the past few months, but it’s really all in the data visualization space; I don’t know anything about Flex app development outside of that. I dip into Flash when necessary, and usually get confused because it’s different from Flex. I know enough PHP to get things done, but I don’t really have a depth of experience, and I still have to refer to the docs a lot.

So this line of thinking implies that, no matter how much my job comes to involve other things, I should make sure that I am still keeping up with my css/javascript skills and following new developments with those technologies. Because at some point in my life, I’m going to have to label myself again, so I need to have at least one language where I can call myself an “x developer” and feel entitled to the phrase.

Just drag this link to your bookmarks bar, or right-click on it, or save it however you save a bookmark typically:
Guides Bookmarklet

When you click on the link, grey bars will appear across the top and left side of the page. From these bars, you may drag out as many guides as you need onto the page. Guides can be repositioned once they are on the page as well; just hover until you see the little arrow cursor. Finally, to remove a guide, just drag it off the side of the page. (That last part may not work in IE.)

This is version 0.1, meaning that I worked on it for about 3 hours overall. So tell me: as a web designer or developer, what would make this more wonderful to you? What other features would you totally use?

Also, please let me know about any bugs!

Contextual Applications:

Adobe’s Product Line: