bbrock

diversity

When we’re polite, we use the term “diversity” to say that the expected level of bigotry is absent. It’s a positive trait for an organization, right behind “does not induce psychosis”. It’s a selling point in software engineering, because it’s closer to the exception than the rule. It’s also good business, because mixed-gender businesses are more successful. The same trend shows up when looking at mixed-gender engineering teams.


Historically, gender inequality in software development has been due to a series of filters at every stage of education and career. It starts in childhood education, with a bias skewed in favor of men on SAT scores, regardless of ability. Fewer women take the advanced math courses in college that are required for a CS degree. Fewer of those major in CS, and then again fewer of that graduate with a computer science degree, and then fewer of the remainder continue on to careers in software development. Even with careers in software development, women are more frequently in supporting fields like documentation and tech support. Those positions typically pay less, as well.


In college, my CS classes typically had 20 students, and half were entirely men. About 5% of my class was female, at a university with more women than men (60%).


Most of my coworkers have looked like me. When I was a worker bee, my 2nd-level manager was a woman twice, as well as one direct manager. Out of roughly a dozen managers. Half of the engineering teams I’ve been on (typically 5-10 people) were entirely men. But the details varied, telling me that individual employers and managers can improve. I’ve heard HR reps brag that 10% of an engineering team was female, as if that showed diversity.


Fewer women work for many startups. That’s not surprising to me, as quite often startups have younger employees… who may be at child-bearing age when the required absences may not be tolerated as well by peers. They might already known each other, perhaps also have been classmates, and my experience says men band together and consider women a special minority who stick out. There’s a bias in venture capital firms, with success showing no gender difference when venture capitalists are women. Small businesses (startups) are also excused from the strictest employment and hiring laws. As a company grows, people hire others who are like themselves. This can be fixed partly by improving a startup’s environment. Staff adequately, allow time off, allow working from home, provide 12 weeks paid maternity and paternity leave.


Some guys think it’s ok to be a bit sexist on the job. I’ve asked why women generally avoid the field at past employers, and the women think those guys are the most obvious reason. Seriously, if someone’s a jerk in that regard, you should consider firing them for it. Quit excusing or defending their disruptive behavior.


The bias doesn’t exist everywhere. When I worked for NASA half my peers were women, more than at any other point in my career. That was also the highest-performing organization I’ve seen. As a tech writer, most of my coworkers were women. I attended meetings where I was the only guy. Even then, my management chain all the way to the top was entirely men. In development teams with colleagues in other parts of the world, the gender ratio was closer to 50/50.


The entire software development field can improve. When venture capital firms are run by women, there’s no gender gap in the performance of the startups they fund. However, the current trend is for fewer women in the field each year.

job searching on the internet

I’ve been in the job market a few times in my career, usually without my employer’s knowledge. Most of my employment after college resulted from knowing the right people. I had a neighbor who worked at the agency. Or had known an employee since high school and through college, who delivered the resume to HR.

I’ve taken a look at a couple of online job search tools, Monster and LinkedIn. So far neither has panned out as well as other methods.

Many people seem to use LinkedIn like a social media homepage, but aren’t hiring from there. I get a lot of spam. Most of the job postings I respond to are for jobs which the employer (or more likely, their recruiter) can’t actually remember posting. Typically when they call, they ask questions like what field I’m interested in, as if they’ve never seen my resume and don’t know why they called, after responding to specific job postings. Several have asked if I had extensive experience in fields unlike anything on my resume, such as sales or finance.

Monster has given me quite a few leads. But about half of the job offerings I apply to have already been closed. The recruiters I have spoken with as a result have not always been the most useful, even after they knew me. During one interview, I was quizzed about which technologies to use by a CTO who then said he wasn’t actually looking to hire anyone.

buzzwording

If you work in software development very long, you learn that people who sell technology not only use buzzwords, but invent them on the fly. Once they start to catch on, or are repeated by senior-enough management, everyone uses them in a sophomoric attempt to be one of the cool kids.

Here’s a partial list that I’ve gathered over the years, of the worst that really didn’t need to be used as shorthand for anything:

  • Out of the box
  • apples to apples (comparison)
  • the net net
  • change the paradigm / paradigm shift
  • basic blocking & tackling
  • The (Home Depots, Walmarts, McDonald’s), when referring to other companies of the same size.

Don’t use those. You need to maintain your buzzword capital, and that means not squandering it unneccessarily.

In addition to those random buzzwords and phrases, IT and Computer Science require extra words to describe complicated processes quickly. For instance, every job I’ve interview at in the past 6 months has assumed that I can define “sprint”, and correctly identify what happens well enough to explain how my own processes deviated from ideal. New programming methodologies (like scrum, which weirdly rejects its proper noun status like it’s e.e. cummings or k.d. lang) introduce their own vocabulary. That vocabulary provides and assumes a context. Those are the buzzwords you really need to know and learn how to use effectively. Use them correctly when communicating with others in the field, and you’ll look like someone who pays attention rather than someone who’s blindly grasping at trying to be cool.

Spectre and Meltdown

Unless you’ve been living under a rock, if you work in IT you’ve heard of Spectre and Meltdown. As you’ll see in a moment, Meltdown is a specific example and exploit of a class of weaknesses called Spectre that affects basically all computer hardware made in the past decade or more. On systems that are affected, the exploit allows an unpriveleged user to peek at anything in the system’s memory, regardless of permissions.

The suggested fix is to replace a systems CPU with new hardware… that hasn’t yet been created, or at least not released publicly. There are a few ways to shore up the operating system’s defenses and security, but it will definitely be available as a backdoor to anyone capable of misusing them.

One of my favorite youtube channels, Computerphile, posted a video several weeks ago that helps clarify what’s going on (comp:

I’m usually a bit annoyed with any company that has serious security flaws, and realize it’s not always justified. I tested software errata with security fixes long enough to have a fairly quick understanding of how a software project goes through the steps that lead to releasing specific fixes.

First of all, I don’t blame anyone in Quality Assurance for not finding the issue. It’s a design flaw, and in some environments the common reaction is to ignore QA when they point those out. I’ve been told several times that a flaw which I found in Quality Engineering was not serious, because it was in the last release and no customers have yet complained about it. Also, it’s not easy to find security flaws in software quickly, even for those trained in the dark arts. Quality Assurance and the tests they devise are designed to prove that software can work as intended without problem. Unfortunately, you can never test bugs out of existence, and the sheer volume of code required to try would dwarf the size of the software intended for release. The best you can do is say “it didn’t work like claimed” if the actual tests don’t pass.

By the way, in the vast majority of cases that I’ve seen, QA spends the most time working on regression testing, preferably automated. Meaning that the tests they devise passed for the previous release, and QA is checking to see if any relevant bugs occur again, after they’ve already been fixed once. Really, no one thinks QA is sexy.

Spectre is a cross-platform problem that is independent of operating system, and affects all of the major CPUs created to run more than one program. Basically everything except embedded systems like Arduino (I really need to check whether it’s affected). If it runs anything like a desktop or server or laptop, it’s vulnerable. So it’s not something that would easily be picked up by operating system creators.

The bug has been around for most of the careers of most hardware developers. It’s going to be a while before we really work out the best solution.