Gender-bias in Software Dev?

I'd rather not post a link to our recently-zombified friend, the Wall Street Journal, but this blogpiece (found linked on Mostly Media) regarding gender-based effects in software development. The blogpiece itself looks like a combination of an appeal to Moore's Law, combined with some solid code maintenance practice, thinly wrapped with a gender-bias argument. It's also been pre-chewed for the readership. However, there are a few basics that you need to keep in mind: Code is, in essence, crystalline thought. This is particularly true for "higher-level" languages, which are translated into actual programs. As such, most code reflects the overlapping cultures that produced and maintained it. Gender-based code styles could well be valid, but it is only one of many cultural modifiers that affect a developer (or team of developers). These modifiers include national, geographic, economic, generational, and (multiple) organizational traits, that shape people's behavior over time. Obfuscation Code Obfuscation is definitely a test of skill, both for the writer and readers. The International Obfuscated C Code Contest is the earliest, organized Obf-contest I can remember, although similar contests exist for most modern languages (particularly those rooted in C). If I recall correctly, Obfuscation derives its roots in the quests for storage efficiency, runtime efficiency, and overall performance. These three traits are (usually) orthogonal to maintainability and legibility. Who can write the smallest program? Who can write the fastest program? Who can write the program which uses the least bytes or bandwidth? Answeres to these questions lead directly to the question of who can write the most unreadable program. Comments vs. Code That brings us to the danger of comments. Comments do not relate program function. Comments relate programmers' intent. Why? Here's an example, where all text to the right of '//' is a comment: char input_array = ['A','D']; // An array of characters char *result_ptr; // Pointer to a character or array result_ptr = Invert( input_array ) //Invert the order of this array ...what is the order of input_array? The comment says we have inverted input_array, but the code assigns something to result_ptr. Does result_ptr now reference an inverted input_array, or an entirely new array made of the inverted members of input_array? Nothing in this language prevents us from writing Invert() in either fashion. We have to look at Invert(), or establish an understanding through testing, to determine the function's behavior. My point here is: to the degree that comments and code actually match, you have "good" comments. It is far, far too easy for developers to substitute understanding of comment for understanding of the code which actually runs.

posted at: 16:39 | permanent link to this entry

Braves Make a Move

Amidst the history and the retrospection this week (more on that in a later post), the Braves replaced their Strength and Conditioning coach. I don't know what's going on here, but there have to be real problems, of one kind or another, for a team to make that kind of move, especially mid-season.

posted at: 15:21 | permanent link to this entry

Today's topic for discussion is:

Unagi.

posted at: 00:34 | permanent link to this entry

Critical Mass

I ran into a funny thing on the way to the volleyball tournament last Friday: about 500+ bicyclists! It was "Critical Mass", the quasi-promotion, quasi-protest, monthly group bicycle ride, from somewhere to somewhere else. It was highly cool to watch, as well as watching the looks on the faces of several Happy Hour denizens as this ginormous chain of bicicles rode by. And then, there's the matter of traffic, as flared-up in Shelbinator'sreview of the rally and local coverage. I still think these folks are missing a golden opportunity for advancing the ball, to cater to their own self-indulgence.

posted at: 00:33 | permanent link to this entry