Archive for developers

Google Should Not Have Fired Their Engineer over Sexist Memo

A pig.

Anyone who knows me personally knows my politics are generally liberal sprinkled with a strong respect for tradition. I also am willing to label myself a feminist in the traditional sense of the word – an advocate for the equality of women in all aspects of society. The reason I mention this is to provide context for my contention that Google was wrong to fire an employee for his wrongheaded remarks about women in tech. And also, to head off arguments that I am some right-wing, women bashing, pig.

Like many in the tech community, I have been following the story of Google engineer James Damore’s internal memo entitled “Google’s Ideological Echo Chamber”. I was taken aback by two aspects of the memo: how well written it is and how weak the data is. In most cases, Mr. Damore does rely on stereotypes and not real data. That makes his arguments less than defensible. Firing him for those arguments though, is draconian. Google action also helps to prove Mr. Damore’s point about the intolerance of views that don’t meet with, what he perceives, as a left leaning bias. Let me put this another way – you don’t fire someone because you find their views odious. That’s not liberal. Liberals revel in freedom of thought and respectful public discourse. Mr. Damore sought out a dialog and, in this case, is more “liberal” than Google management.

Unfortunately, Google also missed a rare opportunity to discuss gender stereotypes and the biases they drive. That would have been a great service to Google, the tech industry, and society at large. It may have been a teachable moment not just for Mr. Damore but for everyone in tech who believe we are untouched by the hidden biases of the greater society. Here’s where the scientific literature may have helped. Mr. Damore’s fellow Googlers (Googlites? Googles? Whatever…) could have used reason to dispel his notions about gender, citing real scientific fact and respected data. He does not come across as an unreasonable person, just lacking in appropriate facts. Politely pointing out where the research doesn’t support his ascertains may have swayed him and any other readers who hold the same views.

Change almost never happens by silencing critics who act in a respectful manner and ask for dialog. It only provides a bigger soapbox from which to pronounce distorted views. Change happens when we learn from each other, something that Mr. Damore says he is open to. Removing him doesn’t remove his point of view. Googlers who share his views won’t suddenly abandon them. Instead they will see evidence that he is right and Google is biased against dissenting viewpoints.

Ultimately, Mr. Damore asked for a discussion. Wouldn’t that have been better approach? Legalities aside, removing someone from their livelihood is harsh. It is especially so when he was encouraged to share his views openly. By firing Mr. Damore, Google seems to prove his point that the company may be authoritarian, biased, and intolerant. It’s just too bad that Google missed an opportunity to prove him wrong – wrong about Google and wrong about women in tech.

I certainly don’t agree with Mr. Damore. My 33 years in the tech industry (which are likely a few more than his) have taught me that women engineers are every bit as capable as men. That more women are not in tech has more to do with a company culture that is not family friendly and managers with views such as Mr. Damore’s, than the ability of women to do the job. That doesn’t mean that he should be fired for having these views, even if they are antediluvian. Instead, respectful discourse would have accomplished so much more.


I admit, I sometimes have weird vacations. I’ve had a few weeks off from work while awaiting the start of my new job. There was a trip to New Orleans (in the summer!) but also time spent watching the livestreams of two tech conferences. A little while back I watched and commented on Apple’s WWDC and, before heading off to NOLA, I tuned into DockerCon. I’m truly a geek. DockerCon is the conference for Docker users. In case you are unaware, Docker is arguably the most used (or at least well known) container technology. Containers are a type of virtualization. There’s plenty of places to look up containers so go do that now if you are ill informed about them.

DockerCon, unlike most conferences I have attended or viewed, is entirely oriented toward technology professionals. Even Microsoft Build and WWDC have more business influence than DockerCon. That’s not unexpected given that Docker’s whole business is centered around developers and sysadmins, It does, however, does add a certain flavor to the proceedings. For instance, the speakers seemed to spend an inordinate amount of time talking about why one would use a container. I would have thought that anyone who was at DockerCon was there to understand the “how” and had already figured out the “why”. It was whipped cream on ice cream – generally unnecessary and in the way of the good stuff.

The most interesting part of DockerCon was seeing how far the technology has come in such a short period of time. It’s not just the growth numbers – though there has been phenomenal uptake in Docker container usage – but the rate of evolution of the product itself that is so startling. In two years, Docker has gone from having only the basic container engine to networking and security upgrades along with the addition of plugins and orchestration. The platform choices have also expanded, though much of it is still in BETA. Whereas Docker, like most containers, has been based on LXC and limited to 64-bit Linux, they are now expanding into Windows and MacOS as well as various cloud platforms such as Amazon AWS and Microsoft Azure.

The upshot is that Docker is making itself more attractive for large scale production environments. Docker 1.12 adds features that are important to deploying containers in production, as opposed to developer, environments. For example, orchestration will be part of the 1.12 release. Called Swarm, this feature allows large numbers of containers to be instantiated easily and then managed effectively. Manual tools are fine for individual developers but not for production environments. Swarm, which is similar to Google Kubernates, does all this. The upgrades to security are also important to expanding the use of containers into more robust environments. The addition of key management, while mundane, is very important to maintaining secure environments and Docker 1.12 has it.

Docker is also introducing a new container format. Typically, containers have encapsulated one piece of processing. What the Distributed Application Bundle or (terribly nicknamed) DAB does is package many containers together so that a sysadmin can deploy the entire application at once. Not only does this make it easier to deploy a new application but makes it much easier to migrate or move whole applications. Coupled with Swarm, this is a big time saver for the OPS crowd. DAB is still experimental so it isn’t certain if it will become a feature but it shows that Docker is thinking the right way.

The big takeaway from DockerCon is that Docker containers are now ready for the big time. The ecosystem is growing and the product itself has evolved into something that is useful to production environments. Our little container tech has grown up and is ready to wear big boy pants.