Weird Teaching

Teaching with a mask on to students wearing masks is just downright weird. I can't hear students through their masks; I can't pronounce some words through my mask; and sometimes I look out at the class and see students with masks, sunglasses, and hats, and I have no idea who they are!

In my long (some would say overly long) career, I've had some challenging environments to teach in, though, so I think I can handle this new one!

Visa Training

Back in the 90s, I was once asked to teach a network troubleshooting class to the night shift at Visa (the credit card company). They wanted me to teach the IT help desk every night from midnight to 3 am. I asked them if this was really a good idea. They assured me it was. The first night went pretty well. The second night, at about 1 am, I looked out at the class, and every single student was sound asleep.

IBM Training

And then there was the time IBM asked me to teach a one-week Token Ring and Ethernet troubleshooting class. I asked them, "are you sure this is a good idea? Didn't you guys invent Token Ring?" They assured me it was a good idea. 

Sure enough, I arrived in lovely Fishkill, New York and went over the schedule with them (again), and they said "oh, we don't need the Token Ring day. Why don't you take Tuesday off and go sight-seeing." So I got paid to sight-see in lovely Fishkill. Granted, I did see some cool things. I visited FDR's home in Hyde Park, the Culinary Institute of America, Vassar College, etc.

"Main Street in Fishkill." Photo by Daniel Case, CC BY-SA 3.0, via Wikimedia Commons

US House of Representatives Training

Once I taught a class to the network engineers for the US House of Representatives. They forgot to book a training room. Your government at work, I guess. :-) They said, "no problem, we'll do it in the lab." They failed to tell me, however, that the lab was also where the line printers were. I taught the entire class as these huge, loud line printers printed multiple copies of some 500-page bill that the Representatives were working on.

Macintosh Software Development Training

And one more story: Early in my career, I taught a one-week Macintosh software development class at a resort in Mexico with a colleague. We said the class would start at 8:30 am. Not a single student showed up at 8:30 am. Finally, about 9:15 am the students started wandering in, looking bleary, drinking their coffee and smoking cigarettes. Around 1 pm they said it was siesta time and that we should start up again at 4 pm. 

I looked at my fellow instructor and saw that he was worried too. There was no way we could cover all the material with this schedule. But then the students assured us that they would work till 8 pm. And sure enough, they worked really hard from 4 pm till 8 pm. After that the evening was dedicated to eating, drinking "rum y cokes" and other adult beverages, and playing cards till 1 am. We instructors adapted quickly to this new fun schedule!

I Love You, IT Departments

Oops, one more story. I can't forget the time I was teaching a county IT department on May 5th, 2000, when the ILOVEYOUVIRUS broke out. One by one my students' beepers started going off and they left the room, looking panicked. Soon there was nobody left! 

Then one student came back in and said, "We better cancel class." Luckily it was the last day of class, a Friday afternoon of a 5-day class. The student added, "Would you like to help us troubleshoot? We've been hit by a massive virus!" The ILOVEYOU virus remains one of the farthest reaching ever. Tens of millions of computers around the world were affected. CNN had a good article about it 20 years after it struck. 

I Don't Love You, Covid!

So anyway, the show must go on, of course. But teaching with a mask? That is just weird. In fact, it's one of the weirdest experiences I've had in my long teaching career. Here's what I have to say to Covid: 

20 Years of Network Design

Cover of Top-Down Network Design, 1st edition, 1999

Computer network design sure has changed in twenty years! Or has it? Although network technologies and applications have certainly changed, at least some of the classic principles of top-down design can still be applied today, whether your network is a set of virtual machines in the cloud or a set of Internet of Things devices. 

Twenty years ago this month, I published Top-Down Network Design with Cisco Press. Macmillan Technical Publishing actually held the 1999 copyright. I mention this because the book is not specific to Cisco-based designs. As I recall, Cisco was just starting Cisco Press in the late 90s, working with Macmillan (which became Pearson) and Cisco documentation gurus such as Kim Lew and others. Some of the books are not specific to Cisco technology, though. Good architecture is vendor-neutral and timeless.

Cisco Press was a terrific partner in the development of all three editions of the book. They did a great job with editing, marketing, distribution, and beautiful covers. They found and worked well with some terrific technical reviewers, including, but not limited to, Dr. Alex Cannara, Dave Jansson, Hank Mauldin, and Dr. Peter Welcher. In addition, Brett Bartow, John Kane, and Mary Beth Ray at Cisco Press deserve much credit for making my book and countless other Cisco Press books such a big success. 

Top-Down Network Design describes a top-down approach to network design that emphasizes the importance of analyzing business and technical goals before selecting hardware and software to build a network. The book presents a network design methodology that I developed based on my software development experience. "Don't start coding until you understand the problem you are trying to solve!" My professors and colleagues had drilled this axiom into me. I changed it to, "Don't start building a network until you have planned it out first."

Photo by J. Kelly Brito on Unsplash

Regardless of the type of network that you are working on, planning the design and configuration of the network benefits from the steps I developed for Top-Down Network Design:

1. Analyze business goals
2. Analyze technical goals
3. Characterize the existing network
4. Characterize network traffic
5. Design a logical topology
6. Design addressing and naming schemes
7. Select bridging, switching, and routing protocols
8. Develop plans for securing the network
9. Develop plans for managing the network
10. Test your design
11. Optimize your design
12. Document your design

Reading over the first edition (which I later updated to a 2nd and 3rd edition), I'm happy to see that a lot of the concepts remain important. I seem to have really enjoyed helping my readers learn network design terminology, such as scalability, availability, manageability, usability, adaptability, affordability, and other "abilities." All three editions also have good content about analyzing network performance goals and distinguishing requirements such as:

• Capacity (bandwidth): The data-carrying capability of a circuit or network, measured in bits per second (bps)
• Utilization: The percent of total available capacity in use
• Optimum utilization: Maximum average utilization before the network is considered saturated
• Throughput: Quantity of error-free data successfully transferred between nodes per unit of time, usually seconds
• Offered load: Sum of all the data all network nodes have ready to send at a particular time
• Accuracy: The amount of useful traffic that is correctly transmitted, relative to total traffic
• Efficiency: How much effort is required to produce a certain amount of data throughput 
• Delay (latency): Time between a frame being ready for transmission from a node and delivery of the frame elsewhere in the network
• Delay variation: The amount of time average delay varies
• Response time: The amount of time between a request for some network service and a response to the request 

Where the book hasn't aged well is when it recommends or discusses specific technologies. The first edition actually discusses ATM, Novell NetWare, and AppleTalk. :-) 

The book also probably has too much focus on carefully provisioning the right amount of bandwidth and using the bandwidth sparingly to avoid performance problems. These days, with the exception of wireless networks, we don't seem to worry about bandwidth. Perhaps we should, but with wired networks especially, it's very hard to use all the bandwidth we have, and with 802.11ac and 5G networks coming online, even wireless networks will often have sufficient bandwidth.

Also, with current network planning, we don't tend to characterize network traffic as much as we used to. Perhaps we should pay more attention to the distinctions between network traffic that requires low delay and jitter, for example, and network traffic that demands huge amounts of bandwidth. On the other hand, maybe throwing lots of bandwidth at the problem and spreading it across the globe results in less worry about network traffic characteristics.

Despite these caveats, the book has aged pretty well. The importance of planning is still as relevant as it was in 1999. Yes, we live in an agile world today where there's less focus on requirements analysis. Also, it's possible to simply start building a virtual network and to tinker with it till it works. Nonetheless, I think even virtual networks can benefit from less tinkering and more design. Don't forget the concepts in Top-Down Network Design. They can still help. 

And if you've been wondering, here's what I looked like in approximately 1999. I'm the one in red. I'm with my sister, nieces, and husband. I couldn't find any pictures where I'm not with family. That's a good thing.

Take an Ethics Class

Let's say you are a hot-shot programmer and you're excelling in your computer science classes at your university. Or maybe you're an up-and-coming network administrator and you're taking industry classes. Or maybe you're both, or all of the above! You're taking programming and networking classes in college and at work. Should you also take a class in ethics? YES! 

First, let's address the benefits you will gain from taking an ethics class. Thinking about ethics uses a different part of your brain than coding. Learning about ethical theories, ranging from Kantianism to Utilitarianism to Virtue Ethics, develops your conscience, not just your intellect. In ethics classes, you learn to slow down, to analyze scenarios where ethics play a role, and to apply ethical theories. You learn to contemplate, research, read philosophical treatises, and to discuss philosophy with other students. You are given an opportunity to develop your own ethical framework. 

An ethics class will make you a more rounded human being. Your brain will thank you. Your friends and colleagues will be glad that you took this class also. You are now more likable, able to communicate with people not like you, and more thoughtful. 

Second, let's talk about the benefits to society if you learn ethics. With a groundwork in ethics, you will be able to develop and deploy technology that benefits humans. Your work will not just bring you a high salary and make money for your corporation. Your work will help solve problems facing humans, animals, the planet, and the universe (if your technology is used for space travel).

I've encountered too many programmers and CS students who compartmentalize. They love coding and are good at it, but they assume that ethics is somebody else's job. No, you can't leave ethics to other people. Understanding and applying ethics is as much your job as coding is. 

• What will you do when your boss asks you to deploy robots that will put hundreds of working-class wage-earners out of a job? 
• What will you do when your fancy database is used to keep track of immigrant children who were taken away from their parents at the border? 
• Have you thought about how your facial-recognition software can be used to breach people's privacy or to report to law enforcement the identity of protesters engaged in moral civil disobedience? 
• Is the technology that you are developing making it easier for bullied students to feel isolated?
• Could you develop technology that would help reduce gun violence? 
• What are the ethics of companies using unbreakable encryption that can be used by both bad and good people? What is the balance between safety and privacy in these cases?
• What are the ethics of hiring low-paid Chinese workers to manufacture digital products? 
• Is the technology you are developing going to result in a net increase in the total good of affected parties? 
• When artificial intelligence is as common as natural intelligence, will you be able to protect the rights of humans who haven't been able to afford to upgrade their brains?
• In your day-to-day work, are you behaving ethically? Can you say that you "act only according to that maxim whereby you can at the same time will that it should become a universal law," as Kant would require? If everyone acted like you, would the workplace and society be a better or worse place? Is your behavior consistent with the actions of a virtuous person? 

It's really easy to get caught up solving technical problems. There's nothing better than writing elegant code that works and is finally debugged. But don't let that feeling be your only goal. Remember that humans will use your code and it could do harm or be used in harmful ways. Develop and apply your ethics at every point of your career. 

All students, regardless of their major, should think about how they will interact with others online, and they should learn their rights with regards to companies that deploy information technology, sometimes in unethical ways. For CS students, the thinking needs to go even deeper. 

If you are a Computer Science or Management Information Science student, thinking about the ethics associated with the mainstream use of robots, data mining, algorithms, artificial intelligence, website advertising, surveillance, online voting, etc., is actually more important than learning how to develop and deploy these technologies. Our future depends on you getting this right. 

I Persisted!

I recently had a conversation with someone who didn't seem to understand why "She Persisted" rings so true for many of us. It's not really about Elizabeth Warren for us. It resonates with us because we think "I persisted" when we hear it.

In my case:

• I persisted in the computer field even after it became mostly men.
• I persisted despite being told that women shouldn't take jobs from men because women don’t need to support a family.
• I persisted after being told I couldn't climb a crane to install software because someone might look up my dress. 
• I persisted despite being told that women weren't good hires because they would get pregnant and leave.
• I persisted after being told I didn’t need a job because my husband worked.  
• I persisted despite watching men with fewer achievements get promoted instead of me. 
• I persisted when I was told that the required qualifications for a job were qualifications that the recently-hired men for the same job did not have.
• I persisted despite there being no women's bathroom where I worked! 
• I persisted when male co-workers stole my source code and took credit for it.
• I persisted when male co-workers broke my source code and didn’t take credit for it.
• I persisted when my pay was less than men in the same job. 
• I persisted as popular culture spread the myth that a computer expert has to look like Mark Zuckerberg. 
• I persisted when I looked around the room at meetings or conferences and was unable to find another female face.
• I persisted when my ideas at a meeting were rejected when the same ideas posed later by a man in the same meeting were accepted.
• I persisted despite incessant comments about my clothes, hair, and jewelry. 
• I persisted despite having my ass pinched at work.  
• I persisted. :-) 

Network Disruption

Network Disruption. This sounds like a bad thing. We hear network disruption and we think service outage. At Cisco Live, I learned that disruption is a good thing! 

My two favorite sessions were: 

1. Network Transformation and Essential Skills for Next Generation Network Engineers [BRKSPG-1000], presented by Zahoor Khan and Imran Shahid, CCIE #11894 and #11893. (Yes they are just one number apart!) 

The speakers told us that everything about the network is changing -- its connectivity, service delivery, business model, architecture, etc. The speakers gently told senior-level engineers that they need to get off their bottoms and learn a huge amount of new stuff. (They said it much more eloquently.) This appealed to the Technical Instructor in me. 

2. Disrupt Yourself: Driving Corporate Innovation Through Personal Disruption [DEVNET-1219], presented by Whitney Johnson, @johnsonwhitney. 

One of the best parts of this presentation was that Whitney quoted Leo Tolstoy. She had a slide that included the quote above. This appealed to the English major in me.

The networking field is in the middle of a disruption that even Tolstoy would recognize for its revolutionary magnitude. Transformations include:

• A change from Command Line Interface (CLI) to Application Programming Interface (API) 
• Waterfall to agile methods
• Purpose-built network devices to Network Function Virtualization
• Closed systems to open systems
• Manual to automated service chaining

Network engineers need to understand Software-Defined Networking and virtualization. They need to learn some programming and be fluent in Linux. They can no longer limit their skill set to one vendor's products. The speakers in BRKSPG-1000 gave us a laundry list of new technologies to learn that included these topics and many more. We should learn about OpenFlow, NETCONF, YANG, REST, Git, GitHub, DDPK, containers, Docker, Jenkins, Ansible, Puppet, etc., etc., etc. 

The speakers did a good job of making the learning sound exciting and not scary, at least not too scary. Learning is fun, they said. Also, they provided good advice on segmenting your learning and keeping your end goals in mind. 

Whitney Johnson's presentation was a perfect complement to the BRKSPG-1000 presentation about all the new technologies we need to learn. She recommended taking risks, but taking the right risks for you. She said to play to your distinctive strengths and to think about what makes you feel strong. Think about what skills have helped you survive in the past. Battle entitlement and step back to grow. 

Those of us who have been in the networking field a long time need to step back and learn an enormous amount of new information. We can't sit back and let the revolution wash over us. The disruption must come from within, as Tolstoy said. 

Cisco Live 2016!

I'm attending Cisco Live this year! This will be my first Cisco Live in five years, so I'm a little nervous. I have memories of being run down by hordes of young men swinging large backpacks. :-) But I also have memories of learning amazing new technologies, getting to know fellow networking nerds, and cool hats!

My first Cisco Live (Networkers) was in Palo Alto in 1995. I think that was the best hat year.*

The Session Catalog - Cisco Live US 2016 this year holds great promise!

I'm most looking forward to:

• A new hat
• Maroon 5
• 13 Smart Ways to Program Your Cisco Network [BRKCRS-3114]
• Containers on Routers and Switches: Run Your Apps and Tools Natively on Cisco Boxes [BRKSDN-2116]
• OpenStack Deployment in the Enterprise and Service Provider [BRKDCT-2367]
• Techniques of a Network Detective [BRKARC-2002]
• Software Defined Network Automation Architectures [BRKDCT-2027]
• Network Transformation and Essential Skills for Next Generation Network Engineers [BRKSPG-1000]

And of course this panel discussion (I'm on the panel): Build Your Personal Brand with Social Media. [CISSOL-1113]

*For a history of Cisco Live hats, see this article by Fryguy: http://www.fryguy.net/2014/03/25/cisco-live-hats-over-the-years. 

Thought Diversity Necessary for Formation of the Internet

Most of us in the computer field know that having a diverse workplace is important for making decisions on what products to develop and how to market them. But is diversity important for solving computer science and engineering problems? I say YES. Diversity helped form the modern networking field. Without diversity we would not have the Internet. 

The following parable is from a US point of view. Lots of work was done in Europe too, but that is for another post when I have more time. :-) 

In the early days of networking, most of the data communications experts were on the East Coast. So we had the mainframe which polled the slave terminals. We had RS-232 where terminals had to Request to Send (RTS) and get a Clear to Send (CTS) to communicate. 

We had error correction, network control, and time division multiplexing, where nodes waited their turn to talk. The algorithms were orderly, hierarchical, predictable, and unwieldy. 

With the culture changes of the 1970s and 1980s, ideas for algorithms were infused with more creativity, and Token Ring was invented. A ring sounds like something from The Hobbit, with liberal connotations, where all the nodes in a circle sing Kumbaya and use a token to determine who gets to speak. However, the algorithms were still mechanistic and militaristic. A network node seized the token in order to talk, and when the node was talking, every other node was required to be silent. An active and standby monitor were needed to oversee the operations. In bridged networks, nodes used source routing to dictate which path the data frames should take. 

The engineering was still being developed by the New Yorkers in suits and white shirts with pocket protectors. Token Ring was expensive and hard to troubleshoot, and it mimicked human communications found in hierarchical, autocratic, traditional societies.

Out on the West Coast and in Hawaii, on the other hand, we had the surfers and the hippies working on networking! In the 1970s, Bob Metcalfe flew to Hawaii and all hell broke loose. :-) 

Metcalfe's research on ALOHAnet, a wireless packet network that was developed by the University of Hawaii, led to the development of CSMA and Ethernet. With CSMA, nodes listen before they send, but if they don’t hear anything, they just send anyway. If multiple nodes sense that there’s quiet, they just go ahead and send, so there could be multiple nodes all talking at once. The nodes also listen while sending, and back off if necessary. It’s like a big party! Aloha! 

Ethernet was inexpensive, easy to set up, easy to troubleshoot (at least compared to Token Ring), and scalable. We still use it today with speeds up to 40 Gbps and 100 Gbps. The work of Radia Perlman on the Spanning Tree Protocol allowed robust bridged networks to dynamically form a spanning tree. Routing across Ethernet networks became possible with the invention of the Internet.

The Internet was developed by men and women, working on the West and East coast, and parts in-between. In the West, UCLA, UCSB, Stanford Research Institute, and the University of Utah first worked on ARPANET and then the Internet. On the East Coast, universities, the US federal government, and various companies helped develop protocols and algorithms. The developers decided to break up data into packets and to forgo traditional point-to-point telecomm links and circuits that needed to be set up in advance. This led to the NSFNET and then to the commercial Internet.

The Internet’s infrastructure was designed by engineers seeped in human communications styles very different from the hierarchical, autocratic, traditional styles mentioned earlier. 

If the development of network algorithms had been left only to the stuffy East Coasters with their crew cuts and slide rules, we wouldn’t be having this conversation today, on a public, gigantic Internet that is built on top of Ethernet and wireless technologies. 

Kitty Joyner, electrical engineer, at Langley in 1952.

It was the diversity of thinking that made modern networks possible. This isn't just some politically-correct maxim that applies only to product design and marketing. Diversity helped solve the engineering and computer science problems that made the Internet possible.

Top Ten Reasons Not to Publish Top Ten Women Lists

Sophie Germain by Auguste Eugene Leray

I'm guilty of making my own list of women who do great work in tech, but nonetheless there are at least 10 reasons we should stop publishing these "Top X Number of Women in Some STEM or Leadership Role" articles. And that is 10 decimal, not binary. :-)

1. These lists are really getting old. Get creative. Stop copying everyone else.
2. Lists of women in tech call attention to the shortage of women, and can be discouraging. 
3. If we must make lists, let's make lists about top reasons to be a computer professional. Be encouraging! 
4. An in-depth article about an ordinary woman and her work is more inspirational than a list of sound-bites about "top women."
5. Lists are often not well-researched. A CEO with no engineering experience doesn't belong on a list of women engineers, for example. 
6. Sometimes a woman in a "top 10 women" list was actually a man previously.
7. It's 2015. Maybe it's time to talk about top performers in tech, regardless of gender.
8. The actual work is being done by the thousands of women and men you left off your list. 
9. Too often the list includes Ada Lovelace, Grace Hopper, or Hedy Lamarr, whom we all love, but there are lots of living women in computing too. 
10. When the tech workforce becomes more gender diverse, what are you going to do then? Top Sophie Germain prime number of women in tech? :-) 

p.s. To see my list of women in tech, go here. 

A Mini-Review of Ex Machina from a Feminist Point of View

One of my main takeaways from the Ex Machina movie was that if men design robots, the robots will be beautiful young females who are so dumb they wear 7-inch stiletto heels in the woods! Despite this idiocy, the robots will be cunning and able to use their female wiles to seduce human men and make the men act dumb.

Seriously, if we don't get more women in tech, the robots that could replace humans some day will be a male fantasy of everything immature men love and hate about women. This is a scary thought.

Spoiler alert: The naked female robots in the closets are creepy and unsettling.

Entrepreneur Elon Musk recently tweeted: “Hope we’re not just the biological boot loader for digital superintelligence. Unfortunately, that is increasingly probable.” 

If the movie Ex Machina is a good prediction of the future, then we are in fact the evolutionary ancestors of the digital robots that we will create and that will one day take over the world. 

As Nathan, the brilliant Google-like engineer who created the Artificial Intelligence in the movie, says, "One day the AIs are going to look back on us the same way we look at fossil skeletons on the plains of Africa. An upright ape living in dust with crude language and tools, all set for extinction."

I can't think of a better reason for why we need more women in tech! If we are truly creating our descendants, then we need the creators of these descendants to be a diverse group with varied decision-making styles and a maturity that comes from overcoming challenges. Without help from people not like them, the young white and Asian men who make up 80-90% of tech today simply won't make all the right decisions about what our digital descendants should be capable of doing. 

Even if we're just creating robots that will do chores for us, or intelligent agents that can perceive their environment and act in some rational way to benefit us humans, the robots will be more functional, less buggy, and more benevolent if they are designed by a diverse group. 

I actually did love the movie for its thought-provoking elucidation of the philosophical underpinnings of artificial intelligence research, but I found the overuse of gender norms disheartening. What if the programmer selected to run the Turing test had been female? What if some of the robots were handsome young males? Or even old, chubby males or females? 

What if some of the robots were androgynous? I think that would have made a better movie. And in the real world, I think a diverse group of technology creators will make a better future, both for humans and robots. 

Thank the Women

Do You Use the Internet? Thank These 10 Women!

If you are using the Internet right now, you have a woman to thank. We've all heard of the men who created the Internet as we know it, Al Gore, Vint Cerf, Tim Berners-Lee, and so on, but women made huge contributions to the field too. Let's give them a huge thank you. 

1) Elizabeth Feinler
Before GoDaddy became the best-known (and most controversial) Internet naming registrar, there was Elizabeth Feinler. Feinler developed the first directory of Internet names and addresses. She also co-invented the domain-naming scheme we still use today to identify organizations as .com, .edu, .gov, or .org.

http://www.internethalloffame.org/inductees/elizabeth-feinler

2) Anne-Marie Eklund Löwinder
The Domain Name System is a helpful technology that lets Internet users enter names instead of addresses, but there are security problems with the system. Anne-Marie Eklund Löwinder is working on a fix. Löwinder works on DNS security extensions that help Internet users be sure they are visiting the website they think they are visiting. 

http://internethalloffame.org/inductees/anne-marie-eklund-löwinder

3) Latanya Sweeney
Speaking of security, you probably have concerns about privacy on the Internet as well as security. Well, so does Dr. Latanya Sweeney, and she is working on your behalf to improve Internet privacy as the Chief Technologist of the U.S. Federal Trade Commission. Sweeney has a PhD in Computer Science from MIT and is on leave from her work as Director of the Data Privacy Lab at Harvard while she works at the FTC. 

http://en.wikipedia.org/wiki/Latanya_Arvette_Sweeney

4) Radia Perlman
Without the work of Dr. Radia Perlman, you could not be reading this Internet blog post. Dr. Perlman develops routing and switching protocols that form the underpinning of the Internet. Ask any network engineer if they have heard of Perlman, and the answer will be a resounding yes. Many engineers learned networking from her influential book, "Interconnections: Bridges, Routers, Switches, and Internetworking Protocols." 

http://www.internethalloffame.org/inductees/radia-perlman

5) Sally Floyd
Have you ever called tech support to complain that the network is slow? You have a woman to thank for the technology that can fix the problem! Dr. Sally Floyd invented Random Early Detection and other networking technology that can automatically recognize when a network link is congested and redirect traffic around the problem.

http://en.wikipedia.org/wiki/Sally_Floyd

6) Barbara van Schewick
Speaking of network congestion, should Internet service providers be allowed to charge extra for handling huge video streams from companies such as Netflix? Net neutrality experts, including Dr. Barbara van Schewick, might say no, arguing that innovation arises from a more hands-off approach where all network traffic is handled equally. Van Schewick knows both the law and the engineering behind net neutrality. She is a Professor of Law at Stanford, holds a PhD in Computer Science, and is the author of the book "Internet Architecture and Innovation."

https://www.law.stanford.edu/profile/barbara-van-schewick

7) Kim Polese
One of the most common programming languages in use on the Internet is Java. Kim Polese was responsible for bringing Java to market in 1995 when she was the Java product manager for Sun Microsystems. Java revolutionized the way that software is written for the Internet, allowing programmers to write one app that can run on multiple platforms. 

http://en.wikipedia.org/wiki/Kim_Polese

8) Sandy Lerner
Cisco Systems manufactures the equipment that controls much of the Internet. Founded in a garage in 1984 by Sandy Lerner and her then-husband, Len Bosack, Cisco grew to become a multinational corporation. Lerner went on to found the cosmetics company Urban Decay and to write a sequel to Jane Austen's "Pride and Prejudice." She is a Renaissance woman, and without her, the Internet may never have grown to what it is today. 

http://en.wikipedia.org/wiki/Sandra_Lerner 

9) Diane Greene
Another huge networking company was also founded by a husband and wife team, with the help of others. VMware was founded by Diane Greene, her husband Mendel Rosenblum, and colleagues. You've heard of "the cloud," right? Well, you have Diane and her colleagues to thank for the cloud and other virtualization services that run the Internet as we know it. 

http://en.wikipedia.org/wiki/Diane_Greene

10) Joyce Reynolds
Finally, let's end with an early Internet pioneer. Joyce Reynolds was one of the most prolific authors and editors of the earliest Request for Comments (RFCs). RFCs specify the protocols that run the Internet. RFCs are still being written today. 

http://icannwiki.com/Joyce_Reynolds 

Summary
In summary, if you read a history of the Internet and no women are mentioned, don't believe it! Yes, many more men than women worked on the protocols and infrastructure, but it wasn't only men. Far from it! Then and now, women work to enhance, secure, and document the Internet, and they deserve our thanks. 

Frequency-Hopping Inventor, Hedy Lamarr

In honor of International Ada Lovelace Day, I am writing about the actress and inventor, Hedy Lamarr. I like this photo of Lamarr because I like to think she's reacting to the Internet idiots who post comments claiming women don't belong in technology. 

"Really," she would say, in her smoky, low voice. "You should have been there when I invented frequency-hopping, a technology still used today on wireless networks. I invented it to prevent Hitler from jamming the Allies' radio-controlled torpedoes. How about you, dude? What have you invented lately?" 

Lamarr was a Hollywood film star in the 1930s and 1940s. She was born Hedwig Eva Maria Kiesler in 1913 in Vienna, Austria. She married young and was unhappy in her marriage. She wrote in her autobiography that her husband, Fritz Mandl, a munitions manufacturer, was extremely controlling. 

In the 1930s, Lamarr accompanied her husband to dinners and meetings with arms developers and learned about control systems for aircraft. The marriage broke up in 1937, and Lamarr, an anti-Nazi of Jewish descent, escaped to Paris, then London, then Hollywood. She took her knowledge of control systems with her.  

Lamarr met her co-inventor, the avant-garde musician George Antheil, at a party in 1940. At the party, Lamarr proposed the idea of frequency-hopping as a method for radio remote control of torpedoes. Frequency-hopping could reduce the danger of detection or jamming of radio-controlled torpedoes. 

Although the idea of radio control for torpedoes was not new, the concept of frequency-hopping was. Broadcasting over a seemingly random series of radio frequencies, switching from frequency to frequency at split-second intervals, prevents radio signals from being jammed. The receiver can be synchronized to the transmitter to allow the two to jump frequencies together. If both the sender and receiver hop in sync, they understand the message, but anyone trying to eavesdrop hears random noise. 

Lamarr and Antheil obtained a patent for their "Secret Communication System" on August 11, 1942. The US Navy was unfortunately not interested in this early version of frequency-hopping. However, the idea was finally implemented in 1962, when it was used by US military ships during a blockade of Cuba, after the patent had expired. 

Subsequent patents in frequency-changing have referred to the Lamarr-Antheil patent as the basis of the field, and the concept lies behind anti-jamming devices used today. In modified form, frequency-hopping is used to send secure wireless transmissions in many modern communications systems.

The Electronic Frontier Foundation honored Lamarr with a belated award in 1997. Lamarr died in Casselberry, Florida on 19 January 2000. She was 85. 

Advertising Matters

Today at the Grace Hopper Celebration of Women in Computing, the CEO of GoDaddy, Blake Irving, is on a panel for male allies. This worries me.  

From 1984 to 2013, the number of women graduating with a degree in CS sank from 37% of the graduates to 14%. GoDaddy may be singlehandedly responsible for a large portion of that decline. 

For years GoDaddy advertised their domain name services with disgusting ads that showed nerdy IT guys and female sex objects. The message was clear: IT is for men. Displaying sexy body parts is for women. The 2013 GoDaddy Super Bowl commercial was the most tasteless ad ever made, not to mention one of the most sexist. 

I like to compare this to the ads that I grew up with. The print ads from IBM and other mainframe companies showed glamorous women, solving interesting problems using computers! I wanted to be that woman! Well, maybe not the woman in the following photo, because she's a blonde, but the ad is intriguing because it shows a woman working on an IBM System/360. 

Check out this brunette, in an ad for the Control Data CDC Cyber 70 Series mainframe. I could be her! I'm a brunette. She's not in the ad to sell to men. She's there to convince women to join the rank of programmers, especially if they use CDC computers. (We had an Amdahl mainframe at the University of Michigan where I went to grad school, but close enough!) 

Like Control Data and Amdahl, International Computers Limited (ICL) created machines to compete with IBM. As was typical for the times, ICL showed women working on their computers in their ads.

Check out this picture of a woman working at NSA on an IBM 360. I want to be her! :-) 

I got this photo from a 1970s timeline at NSA. I suspect the photo might be an ad, not because the woman in the picture couldn't do the work, but because the screen doesn't appear to be on? :-)

I also like this photo from NSA showing a Cray supercomputer. Note that the women are discreetly dressed, working on the computers, and not kissing the nerdy IT guy (as the GoDaddy 2013 Super Bowl ad showed.)

The GoDaddy 2013 Super Bowl ad was so disgusting that customers fled from the brand, both women and men. The company managed to insult both women and men. 

After the 2013 ad, I moved all my domain names but one from GoDaddy. Ironically, TheMakersOfThings.com is the one record I still have at GoDaddy but that was because I was planning to give up on the blog. Why write about women in tech if the industry is dominated by pigs like GoDaddy? Why encourage young women to go into a field where the women don't solve technical problems? They just show off their boobs. Why go into a field where your male coworkers will be pimply, out-of-shape geeks? 

Well, hopefully things will get better. Anita Borg Institute and the Grace Hopper conference will hopefully set GoDaddy on a track that supports the equitable treatment of women in tech. The male allies panel is actually a good idea, but the CEO of GoDaddy better start by deeply apologizing to women in tech.

In the meantime, I'm glad to see positive articles like this one from Glamour magazine about women in tech. Maybe soon we will start to see ads that show gorgeous women working on computers again.