John Detlefs Programmer

My Summer of Code Experience

The summer is over and I am very proud to report that I have accomplished most of my goals I set before starting work with MDAnalysis.

A TL; DR of my github commits to MDAnalysis — — April (Before GSoC officially started) —

  • Fixed a bug in rmsd calculation code to give the right value when given weights.
  • Eliminated a dependency on the BioPython PDB reader and updated documentation. The ‘primitive’ PDB reader replaced BioPython
  • Added an array indexed at zero for the data returned by hydrogen bond analysis

May (Official work started on the 23rd.)

  • I refactored most of the code in MDAnalysis/analysis/ to fit our new analysis api. I improved documentation where I could and wrote a new class called AlignTraj that fits the new API.


  • I was reading and writing a lot about dimension reduction, and during this time I wrote the Diffusion Maps module MDAnalysis/analysis/


  • I finished diffusion maps, and significantly increased coverage for the RMSD class in the analysis package.
  • I went to SciPy!
  • Started work on PCA


  • I fixed some problems in the DCD reader which involved dealing with C code.
  • I finished the PCA module
  • I started (and am very close to finishing) work on a refactor for RMSD calculation to align with the new API.

Times like this call for reflection and honesty, I feel as though there were good moments, some bad moments, but for the most part I feel as though I did a perfectly satisfactory performance. If I were to give myself a grade I’d give myself a B. It may be one of those B’s where my raw grade was a B- but I clearly worked hard and know more at the end than when I started, so I feel as though I’ve earned the bump.

Why not an A, you ask?

There were some weeks over the summer where I really felt like I wasn’t reviewing and iterating on my own work in an incisive fashion. It is easy to write code, commit some changes, and then wait for your mentor to make comments on what you should fix. Around week five or six, I could have done a better job at imagining I was my mentor and predicting his suggestions.

In addition, there were some times in which I self-assigned bug fixes and projects that turned out to be far harder than I anticipated. (One of them was a reader rewind issue that required more understanding of the Reader API than I currently have.) Having respect for the complexity of code and the amount of time it takes to go in and dissect a problem in order to figure out how to fix it is something that I hope to keep improving.

What I did well

  • I worked hard on setting a realistic timeline at the beginning of the summer and achieved all but the last item on the list.
  • I communicated frequently and did not hesitate to ask questions that came up.
  • I helped discover and fix some bugs in old C code which required some self- teaching.
  • Read tech papers, taught myself some dimension reduction algorithms such that I could confidently justify code I wrote.

Historically I think I’ve overpromised and underdelivered on projects, but in this case I think I did a decent job of delivering on the work I promised and doing more when I could. I never got to go in and try to figure out parallel trajectory analysis, but I am still optimistic that I can find the time to work on this soon.

What have I learned?

  • It is often easier and more productive to write crappy code and iterate on it rather than trying to sit at your computer and come up with the perfect code on your first try.

  • Weekends are an important break to prevent long term mental fatigue.

  • Motivation can come and go in waves, ride the wave. Don’t get bummed out and hard on yourself when you find yourself in a lull.

  • IRC or Slack or Gitter is really great to have an informal avenue for questions. Mailing lists and email is overly formal for the kinds of questions I want to ask as a noobie programmer.

  • Don’t read into things, people get busy, if someone doesn’t respond to an email you probably haven’t done anything wrong.

  • The only way to solve hard problems is to break them down into discrete chunks. This is a skill that I have yet to master but am working on improving.

  • I approach health in a very rigorous and number oriented way, I have been thinking that I could treat reading and self-improvement as I do exercise I could do a better job at being productive.

  • A significant portion of working on large software projects is communicating technical ideas rather than purely writing code. Being able to write prose clearly for all audiences is a skill I am still working to improve.