Computer Science Teacher
Computer Science Teacher - Thoughts and Information from Alfred Thompson

  • Computer Science Teacher - Thoughts and Information from Alfred Thompson

    Programming is for Girls

    • 14 Comments

    Fair warning: Some gross generalizations and exaggeration for emphasis follow. But some valid points I think.

    I wrote my first computer program over 35 years ago. There were more women in the field back then. Not as many as their were earlier in the history of computers though. Programming was a woman’s job. The excitement, the glory, the theoretically “hard part” was in the hardware. So was the money. Computer hardware cost a lot more than computer software. Even in the 1970s when one of my professors told me that one day people would spend more money on software than hardware I was not so sure he was right. But of course he was. Good thing for me and my career. But as the money moved into software women were pushed out of the field. This was not a good thing on many levels.

    When I was a student I went to a really conservative university – girls had curfews but boys didn’t. It was a long time ago. The boys tended to spend a lot of time “after hours” in the computer center working on their projects. And during hours as well. The girls not so much. They spent less time in the lab and somehow seemed to always get their projects in on time and to get good grades. In fact they got as good grades as the boys who seemed to live in the computer lab. Weird no? Perhaps not. Also in my first job out of college, mid-1970s, there were a lot of women writing code. Not quite as many as there were men but close. And the women were older, mostly married with kids and at the end of the day they easily left their work behind. And they met all their deadlines with a seaming ease that I sat in wonderment of. What was up with that? I have a theory of course. We, in the west at least, socialize women to plan and men to, well, not plan as much. Think about a high school prom. Planning for the boy means remembering to buy a ticket, perhaps organizing a Tux and showing up on time. For a girl, a whole lot more. Just the day of the prom there is scheduling when the hair is done, the nails, perhaps the makeup, where in the mix does one actually get dressed. And oh by the way she probably made sure the boy got the tickets and his tux.

    This post was inspired in part by an article from Stanford (Researcher reveals how “Computer Geeks” replaced “Computer Girls”) and there is a quote from Grace Hopper that I find most interesting

    As computer scientist Dr. Grace Hopper told a reporter, programming was “just like planning a dinner. You have to plan ahead and schedule everything so that it’s ready when you need it…. Women are ‘naturals’ at computer programming.”

    Naturals? Maybe or maybe not. But we do force women at an early age to plan. The women I went to college with and the women I have worked with in programming jobs were all planners. My wife was a professional programmer for a number of years. Her programs pretty much always worked the first time. She was not interested in debugging. She was interested in getting things to work the first time. And so it goes. When I was teaching I saw a lot of boys (not all but a lot) programming by the “ready, fire, aim” method. Start throwing code together, check it, fix it, check it, check what the result should be and fix some more. Bug? Throw in some code and see if it fixes the problem. Girls did not follow this pattern as often. Think things out, understand the problem, plan a solution, code. test, hand in and go on with their lives.

    Some days when I listen to debates about computer science vs. computer engineering I wonder if the solution is just to get more women back in the field? We are seeing tools that are designed to teach and interest, interest perhaps being the more important thing, young women in programming. The man who got Kodu rolling has a daughter as do several of his team. It is no accident that the graphics are girl friendly (while not turning young boys off either). Alice has been used, especially story telling Alice, with good results with girls. Young girls seem to love building robots with Pico Crickets among other tools. I have heard about a lot of middle school girls getting into programming through FIRST Lego league as well. The thing may be to not scare them away later.

    Either way I think we need them. I do not think our male dominated ‘throw a lot of code against the wall” sort of design works. It may get us there eventually but it is wasteful of time. money and energy. Oh girls are not the whole answer. There are girls who “program like boys” and boys who “program like girls” but are we getting the right mix? I don’t think so. And besides we clearly don’t have enough top programmers (Computer science grads fielding 'multiple job offers')  and if as many girls as boys went into the field we’d be a lot closer to having what we need. Plus we know that mixed gender times are more creative, productive and (at least in my opinion) more fun to work in.



  • Computer Science Teacher - Thoughts and Information from Alfred Thompson

    How Many Sorting Algorithms Do Beginners Need To Learn

    • 13 Comments

    Do beginners even need to learn sorting algorithms? Let’s face it most modern programming environments have a sort function built in. In the so-called real world just about the only people who write sorting algorithms have PhDs in math or computer science and have likely published papers in peer reviewed journals on the sorting subject. So why take up time in a first programming course to talk about sorting? Because its good for them! Well sort of.

    I was looking through the first textbook I wrote some 11 years ago and finding that it include both the bubble and selections sorts. Now these are terribly performing sorts. No one uses these. Quick sort perhaps. Maybe Insertion sort. Bubble sort? What was I thinking! As best I can recall I was thinking about helping explain how arrays worked with loops. It was more about developing an algorithm and seeing how it worked with real (or realish) data. Oh and if I recall correctly, the publisher asked me to make sure I covered sorting and searching. But maybe that is me trying to blame someone else. In a more advanced course one would use different sorting algorithms to learn about algorithm complexity, performance and probably also discuss Big-O notation. That works as a good excuse to talk about different sorting algorithms for many.

    Students understand what sorting is all about. Well they don’t understand all of what it is about but at least if you ask students to sort data by hand they can usually do it. In fact asking students to sort data, perhaps on index cards, and asking them to think through the process they use can be very helpful. This helps them understand the complexity. The value though is really about understanding algorithm creation and translating that into code. Having to involved a number of important concepts like arrays, loops, and decision structures is also a good thing.

    I think today I would teach the Quick Sort. It has all the goodness of other sort PLUS it involves recursion. Recursion is still a bit of magic to me. What it has taken me a while to really appreciate recursion I do now. The typical recursion example is really looping – things like calculating the Fibonacci Sequence. That’s not a bad thing but an application that requires recursion is better, my opinion, for getting students to really appreciate its power.

    But I wonder if there are better algorithms to use as teaching tools? We, the teaching community, should probably be looking for some. Perhaps some that students are actually likely to have to implement some day. What do you think? Are sort algorithms essential? Why? What sort or sorts do you think students should learn? Or is there a better problem that solves the same issues in learning programming and algorithm development?

  • Computer Science Teacher - Thoughts and Information from Alfred Thompson

    One Compile A Day

    • 13 Comments

    A recent blog post by Ian Bogost (The Virtues of Long Compiles) has me thinking once again about the trouble with fast compiles. How would you program differently if you could only compile your project once an hour or perhaps once a day? Actually its more complicated than that. What would you do between compiles? Would you work on other programs or perhaps new modules for the compiling program? There are risks associated with working on modules that have to work with code that hasn’t actually been tested yet. Would you read the manual or textbook looking for new ideas? (That is one thing that comes up in Ian’s post BTW.) This is a hypothetical or theoretical question for most students today. For some of us old people it means trying to remember how did we do thing back in the day of card readers and line printers.

    The first thing I remember is that I put a lot more thought into the code before I hit the compile button. Well actually before I gave the operator my card deck. Smile I didn’t compile after each syntax error was corrected for example. Or even some few number of them. I tried pretty darn hard to identify and correct each syntax error that the last compile had reported. The trick here is that one really had to understand what the error was. There was no time to try random changes and see if they worked. One did some analysis and you were always looking for the one fix that would correct several (or many) errors. Forgetting to declare variables was a killer. Today good IDEs (well Visual Studio which is what I use for most everything) help with the syntax errors are you type. Once doesn’t always have to run a full compile to catch the missing variable declaration for example. That doesn’t mean that errors that are a combination of syntax and logic such as bad assignments with mismatches of type always get caught of course. But one doesn’t have to wait for a long compile to catch most syntax errors.

    With long wait times between compiles there was also an incentive of sorts to write as much code as possible before submitting to compile. This is not so much a good thing. It is much easier to debug a small piece of code than a large complex piece of code. On the other hand you really wanted to make sure your logic was sound, your interfaces clearly defined, and expectations well mapped out. This may be a win for the fast compile crowd in the long run but I’m open to opinions.

    Once one handed in their card deck to the operator there was time before you got the results. Depending on that facility or school that could range from under an hour (the small liberal arts university I attended) to the next day sometime (the larger NYC university my wife attended). So what to do? Sometimes that was time used to prepare test data for when you did get a clean compile. Sometimes it was spent going over the assignment and seeing if anything was missing. Sometimes designing yet another module. Often it was in discussion with others waiting for their run to return. Still other times it was on to some other project for some other subject entirely. In some ways that mental break was a good thing. All in all one did learn some patience. Patience is a noble and necessary virtue for software developers – and other people as well.

    The instant edit, compile and run cycle of modern high speed compilers has changed the way we develop code. In many ways for the better but in the process I sometimes fear we have lost something as well. Patience, careful consideration, attention to detail, and maybe solid planning. Back in the card punch days we saw more women in software development than we do today with the fast edit/compile/run system. Coincidence? I wonder. Does today’s way lend itself less to the way women work than the “old way?” I have no idea. I know of no study. But it is something I just happen to wonder about.

    [EDIT: See also Eugene Walligford's blog post at "I Love The Stuff You Never See"]

Page 5 of 618 (1,853 items) «34567»