Women in Technology

Warning: rant forthcoming.

I don’t get the women in technology problem. Oh, I understand and see the problem. I also understand and see the problem is primarily with men. I just don’t get why there is a problem. 

Maybe the reason I don’t get the problem with women being our peers goes all the way back to first grade. In my first grade class, there were four of us always competing for top marks: Barbara, Olivia, Sasha, and me. It didn’t matter what the subject was, we fought hard for the best grades. Based on that small sample size one could wonder why men were qualified to be in technology. Thankfully, no one thinks this way. 

Fast forward to high school. My junior and senior years were spent at the SC Governor’s School for Science and Mathematics (SCGSSM). At that school, roughly half of the students are male. The other half are female. And let me tell you that intellectually, male or female, they are flat out awesome. I have two bachelor’s degrees: physics and mathematics. Some people treat degrees, especially technical degrees as a sign of intelligence. If that were the case, then I’m among the dumbest kids to graduate from my high school. So many of my classmates have doctorates. Note I didn’t specify “male” classmates. It’s not the proper adjective. 

After high school I went off to what was then an all-male military college, The Citadel. It wasn’t because I wanted to get away from women or thought they were less capable. I wanted a military college because I was seriously considering a 20-year career as an officer. I wanted a multi-service military college because I knew that was the direction the military was going. And I wanted to be close to home because my mom was having some serious health issues. At The Citadel I interacted with some outstanding female professors like Dr. Jane Bishop (history) and Dr. Mei Chen (mathematics). With regards to IT specifically, I was blown away by Dr. Margaret Francel (computer science). I’ve met very few males who can keep up with her intellect.

I also spent a lot of my college time havening. On the havens I met very knowledgeable peers who were female. Folks like Eliste, pooh, and Tenelia, to name a few among many, knew their way around *nix and NeXT systems.   After college, Eliste went into IT and she was good at it but she has moved on to other challenges. Tenelia knows her geology and tracks earthquakes. And the one that I still talk to nearly everyday (when she isn’t trying to trounce me in Words With Friends), pooh, is still one of my go to people if I have a development question. That’s why my experience at The Citadel reinforced my view from SCGSSM: it isn’t about gender.

Therefore, I don’t get why some males have an issue with females being their peers. If a woman can code, she’s an asset to my team. If she can troubleshoot a routing issue, she’s one more competent coworker to share the load. If she can figure out why the database server suddenly starts choking on some bad queries, that means I can focus on something else. A slow day in IT is like that mythical unicorn – it doesn’t exist. There’s more work than there are workers. If you don’t see more work than you can possibly accomplish, then I don’t question her skills, I question yours. 

Advertisements

Why You Shouldn’t Skip the Infrastructure/Security Architecture Review

It’s not usual for development projects to undergo an architecture review, but too many times these reviews consist only of developers. There are no server or network folks, much less any DBAs or security personnel. When I’ve brought this up to some of my developer friends, they wonder what the issue is. After all, developers have a good grasp of how things work, right?

If you’re an infrastructure type, you’re probably chuckling right now (or shaking your head sadly). If you’re a developer, let me ask you a very basic question, “Do you think the admins who support you understand everything about the code you write?” The obvious answer is, “No,” they don’t. They are very smart people but you’ve spent years learning to code, working through design patterns, finding and solving bugs, and a whole lot more about writing code that infrastructure folks don’t even think about. 

Infrastructure folks also spend years specializing in what they know. A lot of what we know don’t even enter into the realm of the developer. Most developers just don’t encounter the problems and issues we do because we solve them before they do. For instance, a recent install comes to mind where the installation was having an issue because of a hardened configuration with respect to the NICs. 

If you just thought, “What do you mean, hardened NIC configuration?” you just proved my point. If you do know what I mean but you don’t deal with that sort of thing regularly, you’ve also proved my point. If you do think about those things regularly but are quite aware that most developers don’t, you probably see my point. Infrastructure folks have specialized knowledge to bring to an architecture discussion that is not in the wheelhouse of most developers. This knowledge, if the infrastructure people are absent, is also absent. 

Infrastructure folks aren’t looking to throw roadblocks up on projects out of malevolence. Okay, MOST infrastructure folks aren’t looking to do that. What we are looking to do is doing our best to ensure that systems going in or being updated are as secure as possible and perform as well as we can make them. We want to minimize risk for the organization. We want to help the organization make the most out of every IT investment. Sometimes that means we challenge back. We see an issue or an area for improvement. Of course we are going to bring it up. 

The later in the project where we get a look at what’s going in, the harder and more costly it will be to the organization to try and make things better. If it’s a showstopper, there may not be time to avoid everything coming to a screeching halt. That’s why it’s important to get the infrastructure folks involved early and keep them involved throughout the whole project. It’s harder, yes, but it’s also what is best for the organization.