It's interesting to hear that the old IBM study results -- programmers average 10 LOC daily, regardless of programming language -- still stands. I think that study was discounting lines of code that were eventually removed from version control in a certain timeframe, thus trying to measure "lines of correct code". The lesson is that programming productivity is directly correlated with how expressive and concise the language.
I like the evil pair exercise. I remember at Georgia Tech when coding homework close to the deadline (always), sometimes I could fake success when the class used automated graders and allowed multiple submissions. The graders would randomly apply a number of test cases, so if the space of possible outputs was small enough... About the Java paradigm of first writing a flow chart, I think that comes from Java's rise during a time when many corporations were trying to commoditize programming. If you were a software engineer between 1996-2006, you were worried your job would be outsourced. The management hypothesis was that if one simply created enough documentation, one could use "dumb programmers" to implement. The "Agile" movement was a backlash, and I think this hypothesis has generally been found inconsistent with the evidence. Unfortunately, the behaviors encouraged by this management philosophy have become the dominant culture of Java. Worse, this pattern is often what is taught in school, especially at institutions that cater to large corporations. On Sun, Jul 12, 2015 at 2:42 PM, Terri Yu <[email protected]> wrote: > Hi, > > I was recently at a scholarship retreat run by Google and I wanted to share > some interesting things I learned there. > > We spent almost a day doing pair programming. The teacher leading the > programming exercises was a senior software engineering from Google. The > task was the same for all the exercises -- programming Conway's Game of Life > [1]. The first exercise was to simply pair program the game of life and > then we did 4 more exercises that were variations on this, with different > constraints. I think we were allotted about 45 minutes for each exercise, > and we switched pairs for each exercise. After each exercise, we went > around the room and debriefed people's thoughts on the exercise. People > could program in any language as long as that language supported unit tests, > and each pair needed to program in a common language that they both knew. > > 1) Program the Game of Life (with unit tests) > > 2) Same as (1) but can't use if/else statements, only allowed 3 lines of > code per function, can't pass primitives to functions or interfaces > > 3) Ping pong pairing: Person A writes tests, Person B writes code to pass > tests, then Person B writes tests, Person A writes code to pass the tests, > etc. > > 4) Evil mute A/B pairing: pairs are not allowed to talk. One person writes > tests. The other person is a "lazy evil" programmer who writes the minimal > code to pass the tests (but the code doesn't need to actually implement the > specification). > > 5) "Baby steps": Program in 5 minute rounds, alternating partners. > Initialize an empty Git repository. Then the coder has 5 minutes to write a > test and write code to pass the test. If the coder finishes, the work done > during that round is committed to the repository. If the coder doesn't > finish, the coder has to do a hard git reset to delete their work. (We were > told that when this exercise is done with Google employees, they use 2.5 > minute rounds -- I'm not sure how I could have managed with that time limit; > I could barely finish in 5 minutes.) > > At the end of the day, we wrote down our observations as answers to the > following questions: > > Closing questions: > On a piece of paper, write the answer to one of the following (to be shared > with the group): > - What, if anything, have you learned today? > - What, if anything, surprised you today? > - What, if anything, will you do differently? > > (During the discussions, we learned that Google software engineers write an > average of 10-20 lines of code per day.) > > I thought the exercises were pretty interesting and sometimes entertaining > (especially exercises 4 and 5). I had never done anything like that before > (it could be that these are common software engineering exercises?). I > learned about software engineering in the presence of constraints. (Like > the crazy constraints in Exercise 2 forced me to do a lot of hacking.) For > Exercise 3, it was made clear that you can easily pass tests without the > code actually implementing the featured tested. I was forced to write a lot > of tests quickly, which is something I'm normally pretty lazy about. It was > also my first experience with pair programming. One of my first partners > was a Java guy and it was interesting how differently he thought about > programming. He wanted to write out a flow chart to design the program and > do a lot of OOP stuff, whereas I just wanted to quickly prototype in Python. > > Most of the students (about 40 of us) knew either Python or Java or both. I > ended up programming in Python for all the exercises and using nose for my > unit testing framework (nose was easier to use than unittest for quick dirty > testing). > > I'm not sure how these exercises would fit into the Software Carpentry > curriculum, but they might be an interesting addition for an advanced > workshop or maybe even a hacking day in a highly computational lab group. > The barrier is that to get something out of these exercises, the students > need to have written basic unit tests before (maybe that could be done in a > pre-workshop prerequisite) and know a common programming language. Exercise > 5 requires knowledge of Git. > > Terri > > [1] https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
