During the Industrial Age, information was property — held by few, information required money and brought power. With the rise of the Information Age, information became water. We all need it, sometimes it falls from the sky, but there are complex rights. Like water, there were information sources and streams. Information was produced and consumed.

A new era is emerging, where information is oxygen. We can’t survive for 3 minutes without it. In fact, if we need to wait for more than 200ms for information, we get restless. We have cloud computing.  Linked Data defies boundaries and does not conform the the bounds of its container.  Increasingly our data is unstructured, expanding or contracting to fit the shape of its emerging purpose. Open Data is creating an increased transparency, where we can see our government at work or observe trends taking place in the real world through weather, agricultural or census data, to name just a few open data sets.

I found the Scholarly Kitchen questioning the metaphor of information as property in 2009, and then suggesting information as streams in 2011.  Our language adapts to the changing world around us.

Like ripples in the water as an unseen fish comes up for air, we can see change in our culture through metaphors that move through our written and spoken language.

Working in a new situation, closely with a new colleague this summer, I found myself often saying “I have a policy…” and I realized that over time I’ve create quite a few silly and some serious rules that help me navigate the day-to-day work of software development or simply working with people.  These echo in my head or I say them aloud when I find myself in a specific situation.  I do break these rules, but they make me think through those exceptions very carefully.

• I never take a job where I don’t know at least one team member very well. The most important indicator of success for any group is the quality of the people. VCs invest in the team, rather than the idea, since it is easier for a great team to change their idea, but impossible for a great idea to find a new team. Where you choose to work is an investment.
• Do a quick web search before you meet with or hire someone. It takes ten minutes.  You should know if they are in the news or what they just blogged about.  You spend your time more effectively, often develop a closer relationship more quickly, or learn that they are crazy so you can make yourself scarce.
• Sometimes, fun trumps other priorities. I try to spend some time every week doing a task which is prioritized based purely on the joy of doing it.  It keeps me happy, and sometimes, there’s a part of me that understands what’s important better than my prefrontal cortex.
• Never do anything just because a VP told you to. I learned this at Macromedia where there was a new VP every year or so.  I had to live with the consequences of my decisions and explain them to the new guy.  It’s pretty lame to have to say, “because someone told me to.”  Of course, you can’t just say “no” either.  You need to understand why you are being asked to do something and make sure the right thing happens, which may be just a little different from what you are being asked to do.
• Working code is 9/10s of the law.  I first heard this from my friend Eric Bloch. Sometimes it is faster to demonstrate than discuss.  Sometimes spending a little time on one practical solution is better than spending the extra time to discuss options and then implement something marginally better.
• People are more important than software.

Communication

• Write stuff down. I take meeting notes and send them out afterwards. I don’t work without a contract. It’s not an issue of trust. There are a thousand small decisions about the work that go unsaid in a meeting. This applies to any collaborative work. Anytime I need to say to you “I will do this” or “I expect you to do that,” a follow-up email will solidify alignment or catch misunderstandings — saving time and forging stronger relationships.
• Think through the desired outcome, before hitting send. Sometimes just a little more information or one additional “cc” will be the difference between action and yet another email in the thread.  Sometimes, this causes me to delete, rather than send.
• “Why” is more important than “what.” Know why you are building software or writing an email or having a meeting.  Remember why a decision was made, not just what the decision was.
• Before giving a speech, stand at the back of the room. Just for a minute, feel what it is like in the worst seat in the house.  Once I did this and overheard someone tell me what a stupid waste of time this class was going to be.  I had the opportunity to find out why and then address his concerns in the class.  Even if the room is empty when I do this, I feel more connected to the audience.
• Never blog more than once a day, save it for tomorrow.  I’d make up a different rule if I blogged more often.  Sometimes I’ll go for weeks, or even months without blogging.  Then I’ll get back in the swing of it and have so much to say.  I just keep drafts and release them later.  I write for myself, but it’s good to think about audience also.

Celebration

• Iterate. Celebrate. Iterate. Celebrate. I wish I knew where I read this. Celebrate the little things.  You can’t really control the big win.  It’s the small series of little wins that we can make happen.  We need to celebrate these.
• For parties, always buy a good lager, not Michelob or Bud, and something non-alcoholic too. Even though I prefer Pale Ale, there are some folk who like a lighter beer.  I try remember that there are divergent tastes. Someone can still like good beer, even if they don’t like ale. And sometimes there’s that guy who really loves Michelob lite. Know your team and cater to their whims, when you can, but keep the Jack Daniels off the list for the holiday party.

Know the org chart

• Tell someone’s boss, in writing, when they do a great job, especially if they are far away in an organization.
• Always take the meeting with the big boss. Having relationships at all levels of an organization is helpful.  It’s important to see the bigger picture, understand how your work fits into broader goals.

Expectations

• Don’t apologize. If I know I screwed up in a way that I know affects someone else, I should, of course, apologize.  However, I used to apologize when I would send an email a week late.  Then I noticed that I would get an email apologizing about lateness and I hadn’t even realized that it was overdue.
• Don’t make promises we don’t need to make. It’s sometimes important to set expectations.  If I avoid habitually making promises that I don’t actually need to make, then it easier to remember the important ones.
• Never say that solving a software problem will be fast, say it is “straightforward.” Even if I think it’ll take ten seconds, it might take longer to deploy it.  It might need to be scheduled later.

Time

• Plan to be early, arrive on time. A good friend once told me “to be early is to be on time, to be on time is to be late, to be late is to be fucked.”  So true, though sometimes, you can make people feel awkward if you are waiting for them so don’t make it too early. You can always have a coffee nearby or take short walk around the neighborhood.  Remember, there might be security or sign-in procedures.  Just because you know where the building is, doesn’t mean you know where the meeting is.
• Date commitments as time ranges when possible.  If I think it’ll happen on Monday, I say “early next week.”  Instead of July 10th, consider “this summer.”
• Nothing happens between Thanksgiving and Jan 2. When scheduling I have date ranges that I skip over and pretend they don’t exist, unless I have specific commitments from every individual who is needed to deliver or review whatever.  Every group, every culture has dates where less work gets done for good reason.  We all need these down-times.  Know them and simply work around them like water in a stream flows around a rock.  In San Francisco, I usually black out the week of Burning Man and a few days after Pride.  In the northeast at my first company, it was Rosh Hashanah.
• Never ship on a Friday. Monday is usually soon enough. Think about whether the release really merits having the team on deck over the weekend. If it does, plan for it ahead of time.

As a Manager

• The #1 job of a good manager is hiring and retaining great people. When I’m in a management role and things get crazy, as they often do, I tell this to myself every morning and twice during the day.  It takes discipline to spend time writing an excellent job description or having individual meetings with staff when there are urgent, pressing, seemingly more important issues to deal with.
• Never hire until you’ve interviewed at least three great candidates. Hiring should be a tough decision.  We should have to ask ourselves what is really important so we can decide between these amazing people.  We should have cause to wonder if we should stretch our budget to hire more than one.
• Move fast on a great candidate. This can conflict with the previous rule, but only when I’ve failed in prioritizing recruiting.  When I have a job opening, I spread the word far and wide as quickly as possible, then if I have a great candidate, I’ll already be talking to other candidates and have context for a quick decision.
• If all of your candidates look the same, you have a recruiting problem. Know the demographics of your industry and of the region where your office is.  If you are only interviewing white guys or Stanford grads, you are missing some of the talent pool.  Since I work in a male dominated field, I’ll sometimes tell a new recruiter, don’t send me any resumes until you have at least one women among them.  With 20% women in our industry, 20% of my candidates should be women.  There’s should be a few qualified, talented people of color in the mix. I can then hire the best person for the job.
• Always be recruiting. Imagine your dream team.  Your people should be on their way to becoming your dream team, if they aren’t there already.  Just getting to know people who you will want to work with, will make you more able to create that team.  Sometimes you can’t hire them, but maybe they’ll come give a talk to your team or serve as a mentor or informal advisor.  Maybe you want to work for them in your next job.

When I graduated from college people would ask me, “How does it feel to be a pioneer in your field?” There are so few women in this profession that just by entering it you’re doing groundbreaking work. For a moment I was proud of myself and then I thought, “Should I be proud of this? That some accident of my birth made me female and I’m interested in the power of these new machines?”

I went on to develop software and I loved the work. Every once in a while I would hear a story of a woman who came before me who had really done groundbreaking work. Though sometimes stories of everyday women who loved the work were even more inspiring. I will share stories from three eras of computing. I’ll start before the modern digital computer was invented.

Did you know the first computers were human? Indeed. One colleague told me about his mother-in-law who had studied math in college. She was hired directly out of school without even an interview to be a computer. This was actually a common practice in the early mid-20th century. Scientific labs would recruit women math majors to operate first slide rules and then later mechanical calculators to compute. They called it “pink collar” work.

The next age of computing starts with some of these women. During the second world war it was a time of great technical advancement. We were constantly seeking to improve the new machines of war that we invented and sent overseas. In the Ballistics Research Lab right near here in Maryland they recruited women math majors to help them with the war effort. Every time they developed new artillery they would need to calculate these ballistic tables to figure out how you have to angle the gun in order to hit a specific target. Before every new type of artillery would need to be deployed they would have these women with their slide rules calculate immense ballistic tables so that for every distance they would record a different angle that would be written up in these great big books for the soldiers at war. This was quite time consuming.

There were these two fellows who had this idea for a machine that could do this much quicker. They called their machine the ENIAC, the Electronic Numerical Integrator and Calculator. It was actually much more than a calculator. It was the first electronic general purpose computer and they needed someone to program this general purpose computer to generate these ballistic tables. They picked six women who were the best “computers” of the group for this important assignment.
The project was very top secret. These women weren’t allowed to even see the machine. They were giving wiring diagrams and then they were asked to figure out how they would connect the wires in order to have this machine do the calculations. Using this initially purely paper-thought experiment they were successful in programming the computer. They eventually had access to the machine and they lay the groundwork for this entirely new industry.

Around that same time perhaps the most famous woman in computing, Admiral Grace Hopper, was just starting her career in the military. Long before she was an admiral she developed the first compiler. “Nobody believe that,” she said. “They told me computers could only do arithmetic.” I first knew of her as the engineer who had coined the term “debugging” when she isolated a computer glitch to an actual bug hidden amongst the vacuum tubes that was creating a problem in the software.

Now, I’m going to fast-forward to the modern era even though there were many remarkable women in between. A few years ago I learned about Barbara Liskov. In 1968, the year I was born, she was one of the first women to get a PhD in computer science. Even though women had really created this field it as a long time before they were getting degrees in the university for this, it was a long time before anyone could even get a degree for this. She pioneered one of the core principles of object-oriented programming. It was only a few years ago that I learned the name of this principle, the Liskov Substitution Principle and it was quite a long time after that, I learned that Liskov was a woman.

I want to ask you today, as you reflect on your daily work, do you know the names and stories of the people who created the techniques that you apply everyday? If all of those names are of one gender or one heritage you are likely missing more than half the picture. I don’t expect you to remember the names of these women. I do hope that if anyone ever remarks to you how few women there are in tech, you might mention to them that there was a time when 100% of software developers were women.

There was a time when software development was actually considered women’s work. In every field there are people with incredible talent who make significant contributions and are then forgotten from history through an accident of their birth. Sometimes we can find these stories and retell them.

Transcript of my second talk at Smithsonian Toastmasters.