EppsNet Archive: Software Engineering

To Young Women Considering a Career in Technology

30 Aug 2017 /

You’ve probably read a lot of articles about how sexist and awful the culture is for women in technology.

I think if anything deters young women from technology careers, it’s this glut of articles saying how sexist and awful the culture is.

Young female technologist

I’ve worked in software development for 30 years. In my experience — and feel free to discount this because I’m not a woman — the culture is not tough for women. If anything, men give women the benefit of the doubt because they’d like to have more women around.

As Holden Caulfield used to say, “I like to be somewhere at least where you can see a few girls around once in a while, even if they’re only scratching their arms or blowing their noses or even just giggling or something.”

Yes, I have seen bad things happen to women in tech, but I’ve seen bad things happen to men and I’ve had bad things happen to me. I’m also aware of bad things happening to women in other professions. We’ve all had our ups and downs.

How to explain this? Bad things happen to women because they’re women and bad things happen to men because — what? We deserve it?

You’ve probably also read a lot of articles about a “diversity chasm” in tech, usually written by women who work in tech and can’t understand why every young woman in America is not making the same career choices they themselves have made.

Women, like any group, are under-represented in some professions (like tech) and over-represented in other professions — education and health services, for example.

Is a software engineering career objectively better than being a nurse or a teacher or a therapist or any of the careers that women seem to prefer?

I’m happy to admit that I don’t know what the “right” male-female ratio is for any given profession and that I don’t know what other people should be doing with their lives.

Programming has been a pretty good career for me — I like to build things and I like to solve hard problems — but I’ve spent most of my life alone in a room or cubicle staring at a computer screen. It’s not for everyone. There are pros and cons like any other job.

I don’t have a daughter but my son never took an interest in programming and I never pushed him to do so. He graduated college with a degree in business. I have no reason to think his life will be less fulfilling because he’s not working in a technology job.

TL;DR:

  • Don’t pursue a technology career because someone else thinks you should.
  • Don’t pursue a technology career to make some point about gender roles in society.
  • Don’t be scared off by inaccurate (IMO) generalizations about anti-female culture.
  • Follow your heart.

Thus spoke The Programmer.


Growing a System

28 Oct 2011 /
Fred Brooks in Berlin

Image via Wikipedia

Some years ago, Harlan Mills proposed that any software system should be grown by incremental development. That is, the system first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it is fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below. . . .

Nothing in the past decade has so radically changed my own practice, and its effectiveness. . . .

One always has, at every stage, in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.


The Waterfall Approach Persists as an Urban Myth

7 May 2005 /

Much of present-day software acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy.

We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s Service Bureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural . . .

All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for “software development.”

— Gerald M. Weinberg

In his book, Agile and Iterative Development, [Craig] Larman has well documented the history of the many disasters introduced by accident when the Department of Defense standardized on a non-iterative method that was unproven on large projects. It was essentially a blunder by a consultant who had little experience with real software development.

The DOD has long since abandoned the waterfall method, and the consultant has recanted, but the waterfall approach persists as an urban myth in many software development organizations.

— Jeff Sutherland