So I passed my proposal last week, and sometime in the next week I should officially advance to candidacy. I now have a plan for my dissertation, finally, and it’s time to get to work. I took it relatively easy last week after the proposal cleaning my offices and investigating new robot simulators and software — more on that in another posting. Now it’s time to get back to work. Both on Topographica, and on rebuilding my dissertation research infrastructure and getting new experiments going.
The funny thing about research code is that the usual coder’s advice,
Plan to throw one away, becomes plan to throw them all away. I.e. you never really know ahead of time which ideas will work and which won’t, and you can’t waste time building code to last until you’re really sure it will work. I learned this the hard way, spending a lot of time in the last couple years writing code that is now totally useless, and my dissertation work will grow out of a tiny kernel inside what I wrote.
This leads to a different idea about building software that what you might learn as an engineer. It’s the auxiliary parts of the code that need to be built to last, modular, easy to use — code for setting up experiments, tracking their progress, collecting data, and visualizing results needs to be well-built, modular, and bulletproof; this code forms your workbench, your virtual laboratory. A good infrastructure like this will allow you to quickly and easily evaluate new computational hypotheses. On the other hand, the actual algorithms under study need to be written and evaluated quickly, with the idea that any one may be thrown away tomorrow, and you shouldn’t invest too much in a particular idea or piece of code until you’re sure it’s going to be successful.
Now I think I’m on track, though