Excerpts from Coders At Work: Peter Deutsch Interview

I've been reading Peter Seibel's excellent book, Coders at Work, which is a transcription of interviews with a dozen or so very well known and impactful programmers. After the first two interviews, I found myself itching to highlight certain sections, and then I thought, heck, why not post some of the bits I found most interesting? This is a book everyone should be aware of, and it's surprisingly readable. Highly recommended.

This is the second of my blog posts. The first contained excerpts from Seibel's interview with Joe Armstrong.

The excerpts below come from Seibel's interview with Peter Deutsch, who is (among many other things) the creator and long-time maintainer of Ghostscript.

My comments are labeled 'CTB'.

Syndicated 2013-05-13 22:00:00 from Living in an Ivory Basement

Excerpts from Coders At Work: Joe Armstrong Interview

I've been reading Peter Seibel's excellent book, Coders at Work, which is a transcription of interviews with a dozen or so very well known and impactful programmers. After the first two interviews, I found myself itching to highlight certain sections, and then I thought, heck, why not post some of the bits I found most interesting? This is a book everyone should be aware of, and it's surprisingly readable. Highly recommended.

This is the first in what I expect to be a dozen or so blog posts, time permitting.

The excerpts below come from Seibel's interview with Joe Armstrong, the inventer of Erlang.

My comments are labeled 'CTB'.

Syndicated 2013-04-28 22:00:00 from Living in an Ivory Basement

PyCon 2013 and Codes of Conduct, more generally

The tech community is messed up in da head, yo.

Several times since Steve Holden's I'm Sorry post I've written long blog posts about my own views on codes of conduct and professional behavior, including the views informed by some of my own extraordinarily embarrassing transgressions. I never felt that the end result had much to add to the conversation so I never posted any of 'em. Plus, they were really embarrassing transgressions.

If you want to know, until last week, I was fairly publicly on the fence about the proposed Python Software Foundation code of conduct (which is not yet public, but is based on the Ubuntu CoC, I think) because I was worried about CoCs being used to whack people inappropriately, due to nonspecificity and other things.

Three things happened at PyCon 2013 that made me decide to (a) change my mind and (b) post this short note saying so.

First, I came to PyCon with two women colleagues, one of whom was harassed nearly constantly by men, albeit on a low level. Both of them are friendly people who are willing to engage at both a personal and a technical level with others, and apparently that signals to some that they can now feel free to comment on "hotness", proposition them, and otherwise act like 14 year old guys. As one friend said, (paraphrased) "I'd be more flattered that they seem to want to sleep with me, if they'd indicated any interest in me as a human being -- you know, asked me why I was at PyCon, what I did, what I worked on, what I thought about things. But they didn't." (Honestly, if I were to judge by that reported set of interactions, any genetic component to such behavior would be weeded out in approximately one generation, 'cause such guys would only be able to reproduce through anonymous donations to sperm banks.)

Second, at an event for a subcommunity that I help not run, bad shit happened. At the same event, derogatory and not-fun sexist remarks were made, publicly and loudly, about a presenter. This made the main organizer for that event feel horrible, and put a damper on the whole event.

Third, this happened. As with #2, I found PyCon's response perfectly appropriate, which makes me much happier about the way PyCon specifically and the PSF in general are likely to enforce any code of conduct in the future. As for the person who posted Twitter pics identifying the men she felt were being sexist, I am not very upset by her actions, because she is not an official representative of PyCon or the PSF, and she did not post anonymously, so she is taking responsibility for her actions -- unlike the people harassing Jesse Noller for doing his effin' job. I do reject the notion that Adria speaks for me in the particulars, and I would guess that her claim to speak for all future women is similarly rejected by many women. Again, PyCon is not responsible for her tweet or her picture, and they should not be held accountable in any way for it; that's her personal action. (I'm more upset by the company that took this to the extent of actually firing someone over it, and I'm really glad my employer (Michigan State University) has rules, procedures, and formal hearings -- if they fire me, it will be after a certain amount of due process and not due to what is presumably Internet hearsay.)

In the end, the latter two incidents are completely overshadowed by the first, though. I'm not the parent or guardian of either of my colleagues, and I suspect they would similarly reject the idea that I speak for either of them - they're both perfectly capable of telling people what they think, frankly (and I would love to be an audience for some of those conversations). But, as both a visible member of the Python community and as the father of two small girls, I am appalled at the second-hand reports of male behavior. I'm particularly appalled at the systemic low-level harassment that seems to be considered normal behavior by some. It's not cool, it's not fun, and it doesn't even have the dubious virtue of being effective.

In summary,

1. GOOD JOB, PYCON. The way the incidents were officially handled was really well done and speaks well of the people we have chosen to run PyCon.
2. We need codes of conduct because they provide some minimal guidelines for people that (apparently) need 'em, because they can't figure out how to tie their own shoelaces without such guidelines.
3. As a community, we need to change the way we treat women, because my daughters will TASER YOU ALL INTO OBLIVION in 10-20 years if we don't.

--titus

p.s. Sorry, no comments. Go blog 'em and I'll link to the blog posts, just send them to @ctitusbrown on Twitter.

Syndicated 2013-03-19 23:00:00 from Living in an Ivory Basement

My 2013 PyCon talk: Awesome Big Data Algorithms

Schedule link

Description

Random algorithms and probabilistic data structures are algorithmically efficient and can provide shockingly good practical results. I will give a practical introduction, with live demos and bad jokes, to this fascinating algorithmic niche. I will conclude with some discussions of how our group has applied this to large sequencing data sets (although this will not be the focus of the talk).

Abstract:

I propose to start with Python implementations of most of the DS & A mentioned in this excellent blog post:

http://highlyscalable.wordpress.com/2012/05/01/probabilistic-structures-web-analytics-data-mining/

and also discuss skip lists and any other random algorithms that catch my fancy. I'll put everything together in an IPython notebook and add visualizations as appropriate.

I'll finish with some discussion of how we've put these approaches to work in my lab's research, which focuses on compressive approaches to large data sets (and is regularly featured in my Python-ic blog, http://ivory.idyll.org/blog/).

Syndicated 2013-03-15 23:00:00 from Living in an Ivory Basement

Communicating programming practice with screencasts

One of the things that I have struggled with over the years is how to teach people how to actually program -- by this I mean the minute-to-minute process and techniques of generating code, more so than syntax and data structures and algorithms. This is generally not taught explicitly in college: most undergraduate students pick it up in the process of doing homeworks, by working with other people, observing TAs, and evolving their own practice. Most science graduate students never take a formal course in programming or software development, as far as I can tell, so they pick it up haphazardly from their colleagues. Open source hackers may get their practice from sprints, but usually by the time you get to a sprint you are already wedged fairly far into your own set of habits.

Despite this lack of explicit teaching, I think it's clear that programming practice is really important. I and the other Linux/UNIX geeks I know all have a fairly small set of basic approaches -- command-line driven, mostly emacs or vi, with lots of automation at the shell -- that we apply to all of our problems, and it is all pretty optimized for the tools and tasks we have. I would be hard pressed to imagine a significantly more efficient and effective set of practices (which just tells me that there is probably something much better, but it's far away from my current practices :).

Now that I'm a professional educator, I'd like to teach this, because what I see students doing is so darned inefficient by comparison. I regularly watch students struggle with the mouse to switch between windows, copy and paste by selecting or dragging, and otherwise completely fail to make use of keyboard shortcuts. I see a lot of code being built from scratch by guess-work, without lots of Google-fu or copy/pasting and editing. Version control isn't integrated into their minute-by-minute process. Testing? Hah. We don't even teach automated testing here at MSU. It's an understatement to say that using all of these techniques together is a conceptual leap that many students seem ill-prepared to make.

Last term I co-taught an intro graduate course in computation for evolutionary biologists using IPython Notebook running in the cloud, and I made extensive use of screencasts as a way to show the students how I worked and how I thought. It went pretty well -- several students told me that they really appreciated being able to see what I was doing and hear why I was doing it, and being able to pause and rewind was very helpful when they ran into trouble.

So this term, for my database-backed Web development course, I decided to post videos of the homework solutions for the second homework, which is part of a whole-term class project to build a distributed peer-to-peer liquor cabinet and party planning Web site. (Hey, you gotta teach 'em somehow, right?)

I posted the example solutions as a github branch as well as videos showing me solving each of the sub problems in real time, with discussion:

HW 2.1 -- http://www.youtube.com/watch?v=2img0wKdokA

HW 2.2 -- http://www.youtube.com/watch?v=eQU4qImY9VM

HW 2.3 -- http://www.youtube.com/watch?v=YqL18Ip2wws

HW 2.4 -- http://www.youtube.com/watch?v=7iOITFHrqmA

HW 2.5 -- http://www.youtube.com/watch?v=0Ea5yxRCKKw

HW 2.6 -- http://www.youtube.com/watch?v=6k8pnl2SgVI

I think the videos are decent screencasts, and by breaking them down this way I made it possible for students to look only at the section they had questions about. Each screencasts is 5-10 minutes total, and now I can use them for other classes, too.

So far so good, and I doubt many students have spent much time looking at them, but maybe some will. We'll have to see if my contentment in having produced them matches their actual utility in the class :).

But then something entertaining happened. Greg Wilson is always bugging us (where "us" means pretty much anyone whose e-mail inbox he has access to) about developing hands-on examples that we can use in Software Carpentry, so I sent these videos to the SWC 'tutors' mailing list with a note that I'd love help writing better homeworks. And within an hour or so, I got back two nice polite e-mails from other members of the list, offering better *solutions. One was about HW 2.1 --

It might be safer to .lstrip() the line before checking for comments (to allow indented comments). Also, not line[0].strip() doesn't test for lines with only white space. it tests for lines that have white space as the first character. 'not line.strip()[0]' would be all white space... That would also make 'not line' redundant.

I also got a more general offer from someone else to peer review my homework solutions, and chastising me for using

fp = open(filename)
try:
  ... do stuff ...
finally:
  fp.close()

instead of

with open(filename) as fp:
   ... do stuff

heh.

I find this little episode very entertaining. I love the notion that other people (at least one is another professor) had the spare time to watch the videos and then critique what I'd done and then send me the critique; I also like the point that the quest for perfect code is ongoing. I am particularly entertained by the fact that they are both right, and that my explanation of my code was in some cases facile, shallow, and somewhat wrong (although not significantly enough to make me redo the videos -- the perfect is the enemy of the good enough!)

And, finally, although no feedback spoke directly to this, I am in love with the notion that we can convey effective practice through video. I think this episode is a great indication that if we could get students to record themselves working through problems, we could learn how they are responding to our instruction and start to develop a deeper understanding of the traps for the novice that lie within our current programming processes.

--titus

Syndicated 2013-02-11 23:00:00 from Living in an Ivory Basement