Today it’s the international women’s day (IWD). A day that should make us men in the software industry think about why so few women study CS and why so many of those who did, never establish a career in the industry. What do we men do wrong, when women don’t feel welcome?
I won’t even mention the obvious things as sexist jargon and inappropriate conference “entertainment”. I will focus on something far more important that keeps women from advancing in our industry: mediocre men.
Yes, you read it right. I think that the situation for women in our industry has very little to do with the women. They are mostly competent but yet humble and wants to learn more. Look at a star such as Kelly Sommers. While being one of the most brilliant developers on the net, she’s also a relentless learner that asks question when there’s something she doesn’t know.
Would a man do that? Yes; some men do, but many don’t. I’ve met so many men that can’t confess that they don’t know something. Instead they are spending hours or days researching. Or in many cases spending hours or days looking busy researching, just to prove how “hard” the problem is and then hope someone will decide that it’s too hard to be worth solving. Most women ask for help when they are stuck. That’s a strength. But it is often perceived in the male dominated industry as a weakness.
Technical skills is the core of any development project. In the end it is the skilled programmers that write the code that forms the product. Everything else is just support to ensure the coders develop the right features in the right order. But somehow management tend to look at the developers as the lowest level in the project hierarchy. How come that the respect for developers and their technical skills get lost?
Having been on a number of projects it’s evident that technical skills matters. They not only matters but are crucial. All processes (agile or whatever) are only there to support the technically skilled who write the code. In fact, the more skilled developers, the less need for tight processes. The then ground breaking Extreme Programming Explained: Embrace Change argued for tearing down most of the then dominant, heavy weight processes and instead trust the developers. It was of course a success, but not only because of the process. It was a success mostly because of the people.
With Kent Beck and Martin Fowler on the same team the process doesn’t matter. They would probably succeed in a heavily regulated waterfall process, coding on punch cards with needles by hand.
But to really unleash the power of such a team it’s best to give them freedom to do their magic and stay out of the way.
That’s exactly what eXtreme Programming is about: Connect the users/customers directly to the development team and keep management out of the way. It worked in the Chrysler C3 project because of the skilled people involved. It works in any project with a skilled team.
I was recently made aware that some unit tests for Kentor.AuthServices were failing on non-English computers. To handle that, I set up an Azure VM with Swedish installed and made a special unit test that would run all other tests with different UI cultures.
When I first understood that I had tests that were broken when run on non-English computers I of course felt that it should be fixed. The tests should not only run with other languages to enable developers from other countries. The tests should of course be possible to be run and used to find problems if someone reports errors on computers having a special language installed. There’s quite a few places in the code with string formatting and it can differ with different cultures, causing hard to find problems.
What I did was to write a special unit test that finds all other unit tests in the code and runs them with different UI culture. The unit tests are found using LINQ and Reflection (it’s an awesome combination that’s extremely powerful) and then they are run with reflection.
I was recently made aware that some unit tests for Kentor.AuthServices were failing on non-English computers. To be able to test a different setup I turned to Azure and set up a machine with VS2013 Pro and installed Swedish language support. Once I found the right way, it was very straight forward.
The problem was that I had set up a number of unit tests to check the actual contents of the exception message. Those are customized when running on a different UI culture (if the language is installed).
Just checking the type of the exception would not be enough as some methods throw ArgumentNullException for different parameters and I want to make sure that it is the right param that is detected and not a false positive. Following the TDD practices as strictly as possible on this project I had to get failing tests first, before making any changes.
I also wanted to make sure that it’s possible to develop and run all tests on VS Pro (I’m using Premium myself). It’s easy to accidentally use a tool that is not available in Pro and this was a perfect opportunity to check that.
Working with Bootstrap is totally awesome. For the first time when doing web page layout I didn’t have divs jumping around all over the place with a minor change in one place wreaking havoc to the entire layout.
I had no intentions to create any graphically exciting design. Actually I was quite happy with the clean simple layout I had before – until I opened it on a tablet or even worse on smartphone. So what I wanted was a simple, clean layout that set focus on the content and works fine for reading on all kinds of devices.