Too Few Women in Tech – Am I Responsible?

Why are there so few women in tech? I was hiring quite some developers and other tech personal in the last years but hired very few women. I've pondered the querstion of women in tech for the last ten years and a Techcrunch post lately called Too Few Women In Tech? Stop Blaming The Men got me thinking again:

The problem isn’t that Silicon Valley is keeping women down, or not doing enough to encourage female entrepreneurs. The opposite is true. No, the problem is that not enough women want to become entrepreneurs.

When I was in elemental school, according to legend, I was the third best in my class and both better pupils were girls, as good or better in mathematics than me. When in college in Germany you choose two major subjects. I've chosen mathematics and physics. In the end there were no women in both courses. When studying computer science there were around 100 students, less than 10 I estimate of them were women.

The Difficulty of Hiring Women

I've been hiring tech personal since the mid 90s and very few hires were women. I would like to hire more women, but the number of job applications from women were well below 5 percent. For consistency and to make recruiting easier for me, I follow the same process in hiring with each applicant. This makes comparing applicants easier - though there are changes and optimizations over the years. When going through the same questions, coding tests and exercises the number of women from a statistically view is very small, I'd need to hire more than 20 tech personal to hire only one woman.

What is the reason there are so few women in tech? Am I part of the problem? I do not think so. Is it discrimination against women or the lack of role models? I would really like to know and what to do. Ciara Byrne says:

Research has shown that role models are important to the career choice of girls. The popular image of a programmer as a socially inept young man is not something which appeals to girls. It's important therefore to highlight women like Marissa Mayer (VP of search at Google) or Caterina Fake (cofounder of Flikr) as examples of high-profile women in the software business.

What do you think? Do you think there should be more women? Is there a problem?

Whom to hire: The best, the mediocre or the cheapest

There are many strategies whom to hire, especially when it comes to developers. I've hired many people, and always hired the best I could get. But there are other strategies. Problems do arise when the people you hire do not fit your hiring strategy. I mainly distinguish three stratgies:

  • Hire the best,
  • the mediocre
  • or the cheapest.

Each strategy has different prerequisites and different impacts on a company.

The Best

Prerequisites: Excellent working conditions, challenging work, above average pay. You cannot hire the best with sub-average pay. You can get the best for average pay if the other factors speak for themselves.
Impact: Costs will be high, at least on paper. Great developers are around 5-10x as productive as cheap ones, but they at most cost twice as much. So from an economical view, it's always better to hire the best.

Joel writes:

"The fastest students were finishing three or four times faster than the average students and as much as ten times faster than the slowest students. [...] It's not just a matter of "10 times more productive." It's that the "average productive" developer never hits the high notes that make great software."

Robert Glass writes in one of the best books about software development:

"The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field."

I've written in 7 Bad Signs not to Work for a Software Company or Startup about the reasons not to work for a company:

  1. No Source Control
  2. No top tools or only home brewed ones (IDE, Build System, …)
  3. They don’t let you talk to or see developers
  4. High turnover
  5. Hiring is mainly done by HR, not by developers/technical staff
  6. No decent hardware

If your company shows these signs it's higly likely you will not attract the best. After you're hired the best, be sure to keep them. Do not demotivate them as I've written in "Developer Motivation and Satisfaction". Your best hiring strategy does not help if you keep losing developers.

The Mediocre

I've interviewed many developers, and rejected most of them, but all of them got a job somewhere else (probably at a company who think they only hire the best) so I assume the most prevalent strategy is hiring mediocre developers.

Prerequisites: Essentially none, most of the developers are mediocre.
Impact: Development will take longer. It will be harder to stay competitve because of the lack of technical innovation which is driven by the best developers.

Why do managers hire mediocre developers? Phil Haack writes in "10 Developers For The Price Of One":

It’s because most managers don’t believe this productivity disparity despite repeated verification by multiple studies.

The Cheapest

Prerequisites: Your process and quality assumptions must be adapted. More micromanagement, more oversight.
Impact: Problems

A process where one member (architect) specifies everything and the cheap coders write the code. You need to forsee and anticipate the maintanence problems and deal with them. Often it's cheaper to outsource than to hire cheap coders. I would not recommend this, it only works if executed perfectly, and most managers are not that good.

Conclusion

I would go with the best, but if that's not possible for some reasons, know that you do not hire the best and act accordingly. Failure arises when you hire cheap or mediocre but think you've hired the best, a pattern I've seen over and over again.

What do you think? I'm interested in comments.

Better Configuration Files

Over the years I have seen many configuration files. Most of them were unusable. There are many reasons for unusable configuration files. What I've learned from looking at large configurations are those main points:

1. Values

Often configuration files use the wrong values. Developers tend to use true/false for switching options on and off.

track-users = true

The configuration is easier to understand when instead of true/false one uses on/off, it's more relevant to the domain

tracking-users = on

Sometimes there are double negations like

no-track-users = true

which leads easily to wrong configurations and is harder to understand. This also leads to inconsistencies like

track-users = on
no-paypal = off
creditcard = on

Do not use double negation, best stick with positive switches where possible.

2. Lists and Types

I'm a friend of typing data. This also goes for configuration values. Your configuration system should support simple types like Strings, Numbers and Lists.

backends = ['backend1', 'backend2', 'backend3']
port = 8080
name = "TestDB"

Then a configuration checker can check the values for typos, like

port = 808x0
backends = ['backend1' 'backend2', 'backend3']
// backends = backend1 backend2, backend3

Lists make configuration files easier to read and shorter. If you have no List support, configurations tend to look like this:

backend.1 = backend1
backend.2 = backend2
backend.3 = backend3
...
currency = dollar
currency = euro

Compare this to the clean List code above.

3. Descriptive

Configuration options should be descriptive. Often they tend to use lots of true/false configuration switches.

database = true
redis = false
cassandra = false

If possible, its better to replace true/false switches with possible options:

// DATABASE, REDIS, CASSANDRA
database = REDIS

4. Hierarchical configurations

Flat configurations are hard to read. To group configuration keys with flat configurations you need to repeat yourself with namespace values. I know many do not like mixing property style and XML style, but I've learned that this works really well for configurations (YAML is another hierarchical option).

<database>
    server = 127.0.0.1
    port = 8080
    name = "TestDB"
</database>

is more readable and clear than

database.server = 127.0.0.1
database.port = 8080
datbase.name = "TestDB"

or even

ordermanagement.database.server = 127.0.0.1
ordermanagement.database.port = 8080
ordermanagement.database.name = "TestDB"

5. Application configuration, server instances and environments

The configuration for one of your application instances is a combination of the environment the instance runs, the application configuration and the server instance.

// application code
database-url = jdbc://$DATABASE.server//$DB
callback-url = http://$HOST/callback

Both database-url and callback-url are application configuration values, $DB is depending on the environment (development, production, test) and $HOST is depending on the server instance. Environment solution can easily be done in different configuration files, e.g. put them into production, development and test directories. This enables you to put all configurations into your source control system.

6. Inversion of control and DRY

Your configuration framework should support inversion of control or dependency injection, I'm not sure what to call it. Do not define the database server IP in every client, define it in the database server configuration and inject/reference it into every client configuration.

// database server config
host = $HOST

and the client

// client config
database.server = $DATABASE.host

instead of

// client config
database.server = 127.0.0.1

Client does not declare the database server, the client determines at startup the runtime config by getting the values from the database server. This can most easily solved with a configuration service, it's harder to solve with configuration files.

7. Write a configuration checker

Of utmost importance is to write a configuration checker. Many production problems arise from wrong configurations. Apache supports a config test before you restart the application by running

apachectl configtest

The checker should check typos, not resolved dependecies, not resolved variables, type checks (String, Number, List, IP, ....) and mandatory values.

Conclusion

Writing configuration in the wrong way leads to maintenance and production problems. Do not neglect the configuration of your application, you need to put thought into it or it will turn to an unmanageable mess.