05.20.09
Posted in Hacking, programmer productivity, robobait, Technology trends at 11:44 am by ducky
I had a very brief but very interesting talk with Prof. Margaret Burnett. She does research on gender and programming. at Oregon State University, but was in town for the International Conference on Software Engineering. She said that many studies have shown that women are — in general — more risk averse than men are. (I’ve also commented on this.) She said that her research found that risk-averse people (most women and some men) are less likely to tinker, to explore, to try out novel features in both tools and languages when programming.
I extrapolate that this means that risk-seeking people (most men and some women) were more likely to have better command of tools, and this ties into something that I’ve been voicing frustration with for some time — there is no instruction on how to use tools in the CS curriculum — but I had never seen it as a gender-bias issue before. I can see how a male universe would think there was no need to explain how to use tools because the figured that the guys would just figure it out on their own. And the most guys might — but most of the women and some of the men might not figure out how to use tools on their own.
In particular, there is no instruction on how to use the debugger: not on what features are available, not on when you should use a debugger vs. not, and none on good debugging strategy. (I’ve commented on that here.) Some of using the debugger is art, true, but there are teachable strategies – practically algorithms — for how to use the debugger to achieve specific ends. (For example, I wrote up how to use the debugger to localize the causes of hangs.)
Full of excitement from Prof. Burnett’s revelations, I went to dinner with a bunch of people connected to the research lab I did my MS research in. All men, of course. I related how Prof. Burnett said that women didn’t tinker, and how this obviously implied to me that CS departments should give some instruction on how to use tools. The guys had a different response: “The departments should teach the women how to tinker.”
That was an unsatisfying response to me, but it took me a while to figure out why. It suggests that the risk-averse pool doesn’t know how to tinker, while in my risk-averse model, it is not appropriate to tinker: one shouldn’t goof off fiddling with stuff that has a risk of not being useful when there is work to do!
(As a concrete example, it has been emotionally very difficult for me to write this blog post today. I think it is important and worthwhile, but I have a little risk-averse agent in my head screaming, screaming at me that I shouldn’t be wasting my time on this: I should be applying for jobs, looking for an immigration lawyer, doing laundry, or working on improving the performance of my maps code. In other words, writing this post is risky behaviour: it takes time for no immediate payoff, and only a low chance of a future payoff. It might also be controversial enough that it upsets people. Doing laundry, however, is a low-risk behaviour: I am guaranteed that it will make my life fractionally better.)
To change the risk-averse population’s behaviour, you would have to change their entire model of risk-reward. I’m not sure that’s possible, but I also think that you shouldn’t want to change the attitude. You want some people to be risk-seeking, as they are the ones who will get you the big wins. However, they will also get you the big losses. The risk-averse people are the ones who provide stability.
Also note that because there is such asymmetry in task completion time between above-median and below-median, you might expect that a bunch of median programmers are, in the aggregate, more productive than a group at both extremes. (There are limits to how much faster you can get at completing a task, but there are no limits to how much slower you can get.) It might be that risk aversion is a good thing!
There was a study I heard of second-hand (I wish I had a citation — anybody know?) that found that startups with a lot of women (I’m remembering 40%) had much MUCH higher survival rates than ones with lower proportions of women. This makes perfect sense to me; a risk-averse population would rein in the potentially destructive tendencies of a risk-seeking population.
Thus I think it does make sense to provide academic training in how to use tools. This should perhaps be coupled with some propaganda about how it is important to set aside some time in the future to get comfortable with tools. (Perhaps it should be presented as risky to not spend time tinkering with tools!)
UPDATE: There’s an interesting (though all-too-brief!) article that mentions differences in the biochemical responses to risk that men and women produce. It says that men produce adrenaline, which is fun. Women produce acetylcholine, which the article says pretty much makes them want to vomit. That could certainly change one’s reaction to risk..
Permalink
04.17.08
Posted in Eclipse, robobait at 1:43 pm by ducky
Eclipse has incremental find!
Control-J will let you start typing to find the next occurrence of what you’re looking for; Shift-Control-J will do incremental find backwards. See Erik’s nice writeup on incremental find…
Permalink
03.17.08
Posted in Eclipse, robobait at 2:34 pm by ducky
I’ve got two cool tricks for you today. Control-O opens up a “quick” view of the Outline View. Instead of looking in a separate pane, you can do it right inline. Furthermore, it has incremental search built in, so you can type a few letters to find methods that start with those letters. If you type in the normal Outline View, it will find the first method that starts with those letters but will continue to show you all the methods.
In the Quick Outline View, it will show only the methods that start with what you typed, so if you type “set”, the quick outline view will only show you setFoo(), setBar(), etc.
But wait, it gets cooler: you can use wildcards in the Quick Outline View and you can’t in the Outline View. For example, in the Quick Outline View, you can type “*Foo” to find getFoo(), setFoo(), etc.
But wait! It gets even cooler! If you have the Quick Outline View up and type control-O again, then it will show you the inherited methods as well as the ones in this class. Totally sweet.
Permalink
03.14.08
Posted in Eclipse, robobait at 9:35 pm by ducky
Several of the users in my study have complained about “tab spam” in Eclipse — having so many files open (at one tab per file) that they can’t keep track of them all.
If you want to limit the number of tabs in Eclipse that you have open at any one time, you can do this:
- go to Window->Preferences->General->Editors,
- put a check in the Close Editors automatically
- and select the number of editors (tabs) that you want open at once.
If you don’t want a tab to be reused, you can “pin” it. (On my toolbar, the “pin this” icon is at the far right, just to the right of the forward arrow, and has a little white-window-with-blue-taskbar underneath a green pushpin.)
This still cycles through editors, eliminating the least-recently-used, but at least you won’t get tab spam.
If you reuse editors, it is handy to use the Auto-Pin Editor Tabs Tweaklet. With that tweaklet installed, Eclipse will not reuse an editor (i.e. a tab) if the file within is dirty. (This will save you a bunch of annoying messages about needing to save files.) If all of the tabs are pinned, it will open a new one.
Permalink
03.13.08
Posted in Eclipse, robobait at 4:27 pm by ducky
One of my user study subjects pulled out a keyboard shortcut that I had never seen before: control-shift-u.
I didn’t get to talk to him about it much, but it pops up a menu with Identifier, Implementing Methods, and Throwing Exception options.
The Identifier seems to find occurrences of that Java element in this file. I guess you could do almost the same thing if you do a FileSearch for a element’s name in one particular file, but that would be a lot more work.
For the Implementing Methods selection, it appears to tell you which methods in this file override/implement methods in the type you had selected. (Note that the type needs to be something right after the keywords “extends” or “implements”. If not, you will get an error message “Cannot search for current selection. Please select a type behind ‘implements’ or ‘extends’.”
You can select an exception (e.g. IOException), press control-shift-u, and select Throwing Exception in order to see which lines of source cause that exception to be thrown. Maybe you knew that read() threw an IOException, but if you didn’t realize that skip() also throws an IOException; this would show you not just that skip() was what was throwing the exception, but the exact line where it was doing so.
Permalink
03.12.08
Posted in Eclipse, programmer productivity, robobait at 10:38 pm by ducky
Cool!
I am doing a observational study of people using Eclipse, and I saw one of the users doing something that looked really useful.
If you hover over a Java element (type, method, or field), then you see the Javadocs for that element. Yeah, old news. You do that seventy times per day already.
If you shift-hover over a Java element, then it shows you the method’s source intead of the Javadocs!
This is a great way to get a peek down a navigation path before commiting to it.
Permalink
03.11.08
Posted in Hacking, robobait at 9:24 am by ducky
To turn off the sound on a ThinkPad running Windows XP:
Start->
Control Panel->
Adjust the system volume ->
In the Device volume area in the middle of the Volume tab, click on Advanced. I know, I know, it looks like you are adjusting speaker volume, but go ahead and do it.
If the microphone doesn’t show up as one of the devices, select the menu item Options->Properties and put a check in the Microphone box.
In the microphone sub-panel, put a check in the Mute box.
(I am soooo not a Windows person…)
Permalink
02.24.08
Posted in robobait at 11:28 am by ducky
I always forget how to do this, and it is incredibly handy…
I frequently want to munge a bunch of files up, and afterwards, change its extension. So for example, I want to do something like
cat a.xml | ./xml2html > a.html
cat b.xml | ./xml2html > b.html
(etc)
It is really easy to just tack something onto the end in bash:
for x in *.xml; do echo $x; cat $x | ./xml2html > $x.html; done
but that will give me ugly files like a.xml.html, b.xml.html, etc.
The basename command to the rescue!
for x in *.xml; do echo $x; cat $x | ./xml2html > `basename $x .xml`.html; done
(Note1: I like to always to an echo $x as the only part of the for loop to make sure I’m only getting files I mean to.)
(Note2: Yes, yes, xargs is apossibility, but I don’t know off the top of my head how to keep the pipe in the command executed by xargs, and not have the pipe get the output of the xargs. Maybe someday I’ll figure out how to do that and post a robobait on that as well.)
Permalink
02.08.08
Posted in programmer productivity, robobait at 12:34 pm by ducky
Frequently, I use the robobait tag to say, “this is something that I know right now that I want to be able to find again in the future”. This robobait tag, by contrast means, “This is something that I think more people should know about. Yo, search engines! Give this page a higher ranking!”
Evan Robinson wrote an article about output as a function of hours per week that draws upon historical research. It says that working a lot is a bad idea.
Permalink
01.27.08
Posted in robobait at 1:32 pm by ducky
About once every six months, I ask myself, “What process has this file open?” (Usually it’s related to “why isn’t my sound playing?)
There is a Linux command-line utility that will tell me which processes have which files open, but it always takes me a little while to find it again. How do I find its name? What do I search for? “process file open”? “which program is using which file”?
So. The utility is named “lsof” (list open files). Now maybe next time it won’t take so long to find it.
Permalink
« Previous entries Next Page » Next Page »
