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.

It’s true, I really am.

Also, I love this time of year, and I’m back.

The first column lists things I want to accomplish by the end of the current month. (I rewrite the chart every month.)

The second column lists things I want to accomplish by the end of the current year.

The third column lists things I want to accomplish by Dec. 31, 2012 (roughly three years from now).

The rows going across are money, talk, code, and learning.

Money is mainly my plan for how much I need to save each month to get to a place where I can support myself for a year without working. (I may not actually not-work for a year, but I’d like to have the option to just go travel around the world if I choose to.) There’s also a secondary goal there around getting a new car, which I need to do this year.

Talk is everything I try to do to “make a name for myself” – blogging, writing articles, and eventually conference speaking. One of these items is always a specific goal for how many blog posts I want to make that month. I’ve been at 6; this month I went down to 4 because I’m feeling unwordly. This is how I make myself blog.

Code is obvious, it’s about things that I want to make and do. Longer-term, it’s about building up both my portfolio and my freelance network.

Learning tends to be shorter-term, and usually includes things that I want to read or watch that aren’t just “for me”. Mostly this is technical stuff, although this month I have a work-related book up there as well.

I picked these four categories because they seem like the main areas that I need to work on in order to advance my career.

The hardest part was getting that 3-year column down. This past fall I went away for a long weekend and hiked part of the Appalachian Trail (for real, not Mark Sanford-style) and did a lot of thinking and writing, and that’s when I came up with a better idea of where I wanted to be in three years. Once I knew that, figuring out what I needed to do to get there was relatively easy.

I think I learned a lot this year about what I’m interested in, and what I want to do — I won’t say with my life, but I’ll say with the next 5 years or so. I don’t think I’m able to look further ahead than that.

In chronological order:

1. Whatti — This was the first web app that I ever designed and built from scratch. And you can tell, because it honestly kind of sucks. (I hesitate to even link to it, honestly.)

However, in the course of making it I got to learn jQuery, which is just about the best thing EVAR, and the CodeIgniter framework, which means that I could now more easily move into Rails or any other Rails-type MVC framework. I also learned a lot about password security and building a logon system, and about how not to design a homepage. And I have forgotten more about the date/time functions in PHP now than I ever really wanted to know.

This project is basically abandoned now, but I am still interested in the idea of this site, which is providing personal analytical information about your habits and progress toward goals. At some point I would like to throw everything here away and do a complete redesign: visually, functionally, architecturally, and of the code. I would like to make it simpler, more focused, and more visually appealing; and I would also like to switch over to the Kohana framework. This will be a project for sometime next year when I am bored.

2. EventHitch — This was my first site with co-conspirators Dennis Becton and Mike Nagle, who had been working on the site about a year before they asked me to join them as a designer and front-end developer. The site hasn’t gotten a lot of attention lately, because we decided that it was too broadly-focused and decided to pursue more of a niche strategy. But I got to play with Google Maps and work on my design skills some more.

3. BandHitch — This was our first niche site, focusing on local music. It is basically a re-skinned version of EventHitch. I want to change the header because I think it looks bad, and a few things need to be fixed CSS-wise. I like how the background effect came out, though.

4. This blog — which sort of counts, I guess? I didn’t build the theme from scratch, but I took a plain one and customized it a lot.

5. The Truth About Costs interactive graphic
The Truth About Risk interactive graphic
(both from the excellent Investing Truths series)

Finally some things from my day job! Exciting!

I did not design either of these graphics, but I built the Costs one and about half of the Risk one (the table and line chart views, and the sliders). They were both done using Flex 3. I hope to do a lot more work in this realm in the upcoming year, moving into the information design side of things as well as more Flex development. (More about that in my next post.)

6. Towniverse — This is the second of our 2 sites that are under active development, along with BandHitch. This one I pretty much got to design and build from scratch, which was a lot of fun. There was some semi-intricate javascript involved, which was nice to play with, especially getting it to work in IE. I’m actually fairly proud of the interaction design on this one; I think it’s fairly smooth and intuitive. (I hope!)

The current plan is to add more features (ability to invite friends out to a restaurant, integrating our events feed and placing weekly events on the map) and then to expand to other locations, focusing on smallish towns in the Philadelphia area. We are also moving to a faster server (possibly Amazon) since the current guys are painfully slow.

Well, that’s pretty much what I did this year. In part II, I’ll talk a little bit about what I learned, and what my plans are for 2010.

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.

The trick is in maintaining a healthy balance between cynicism and idealism. You need cynicism for protection, and idealism for an energy source.

Too much cynicism will crush your idealism, and then you’ll become dead inside.

Too much idealism will make you too fragile, and then you fall apart.

Keep balancing.

Bermuda is an island full of rich people, with a strange mix of British/Caribbean culture. But I really enjoyed visiting there, got to swim and snorkel, and I didn’t even get sunburnt that badly.

This usually passes by mid-November, and I go back to being a more balanced, sociable introvert in time for the holidays. But this week I find myself taking it slow, feeling sleepy a lot, and not getting as much done overall. (Unfortunately that’s a problem, because next week I’ve got a conference presentation to prepare, a website to release, and a vacation to plan.)

It’s got me thinking, though, about how our society in general is designed to completely ignore the seasons. Most people work in buildings that are climate-controlled and artificially lit; it’s possible for many people to get from home to the garage to the car to work without once having to set foot on the actual ground.

There are good reasons for this, of course; being cold and wet sucks, and office cultures demand a style of dress that doesn’t really work for spending time outside. But I wonder if we aren’t losing something important at the same time.

The seasons determine every single thing that happens in the ‘natural world’. They used to determine pretty much every single thing about human life as well, but in the past 100 years we’ve gotten to the point where outwardly they don’t make much difference at all in people’s day-to-day routines.

On the one hand this totally rocks for us, because being warm and well-fed beats being cold and hungry any day. On the other hand, just because we’ve conquered the seasons outwardly, doesn’t mean that we’ve conquered them inwardly as well. Could the year-round, unchanging demands of modern life actually be detrimental to us, when they conflict with some deeper, inherited rhythms and needs that do cause us to change with the seasons? Could people actually be worse off because we are expected to have the same range of moods, same levels of energy and creativity, year round? Or because we expect ourselves to be so?

I wonder if we could somehow arrive at a happy medium, a way to design our buildings and cities and schedules and lives such that they gracefully acknowledge the changing seasons, while continuing to modulate the worst extremes?

At this point, I’ve come to the conclusion that it is completely possible to do both — just not at the same time.

Differences

Design mind and developer mind are like two different lenses or frames. They hold different concerns, have different sets of tools, and can be very different ways of seeing the world.

Design tends to be holistic, looking at all facets and angles of a thing and trying to make them harmonize. Development tends to be analytical, breaking down a problem into smaller and smaller steps that can be individually tackled and solved.

Many types of design are quite spatial, concerned with relationships between objects within a field of view. Development is often more temporal; it is concerned with changing relationships between objects over time, and with passing information through a series of transformational steps.

Design is always about ‘what’: what is the right thing to build, what does the client want, what is the pleasing solution to the problem at hand. Development is more about ‘how’: how to create a capability, and make it flexible and fast and robust and concise.

Both are important, and both are quite difficult, and both can be so rewarding when you get something right.

(Of course, these are all generalizations, with plenty of counterexamples to be found.)

Doing Both

I think the key to successfully doing both is building up your ability to switch between the two. To look at a problem as a designer, as a developer, and as a designer again. To know how to switch perspectives, and when.

Doing this can be jarring. Things that design mind really really wants might prove frustrating or impossible to actually build. Developer mind might want to do things in a logical way that compromises design mind’s vision. In fact, all of the conflicts that occur between designers and developers come up, inside of your own head! But the trick is just to keep doing it, and to focus on creating something beautiful.

When I’m working on a project where I’m doing both roles, I keep separate to-do lists for development and design. I’ll tend to work through one list at a time, perhaps design in the morning and develop after lunch. I might need to match my surroundings to my task, get away from my computer and my desk, and go someplace where design mind can make itself heard. (There are some great suggestions about how to do this in the book Pragmatic Thinking and Learning.)

It’s definitely not for everyone. You do trade away some depth for breadth, and maintaining the different skillsets can take up a lot of time. Employers may not ‘get’ you; it can be hard to find a role that exercises both minds, in a heavily specialized world. And your job title is guaranteed to always be wrong.

On the other hand, you get to have a foot in two fascinating worlds; you get to translate between two important domains; and you get to have conversations with two completely different sets of awesome folks. And sometimes, if it all works out, you might find that there’s a huge strength in being in-between, and that it lets you really impact your world.

“Designevelopers” of the world, unite!

(Here’s an example from the world of automobile design.)