The Undergraduate Research Commandments
by Stephanie Schmidt
1. Thou shalt do a lot of work.
2. Thou shalt have nothing to show for it more often than not.
3. Everyone in research shall pass through this phase.
4. Lie to thyself. Call it a phase even though thou shall know it will happen again.
5. And again.
6. And again.
When in the course of research, your allotment of tasks become disjointed from one another, remaining organized is crucial. Otherwise you won’t be able to avoid the problem of tasks falling through the cracks. This applies to groups of any size. As often as people stress this point, it’ll continually get blown off by fellow undergraduates as just one of those things seasoned professionals say to scare you. Er yeah...the folks brow beating this point, same ones who cry over bad documentation, once again have a valid point.
I promise for most schemes it’s not just busy work. Having the time to get through all the tasks per week is a different story entirely. Understanding the blog platform you are using is another good idea too, especially if posts go missing. Excuse this attempt to recapture the essence last week’s post covered. Debugging scripts, tweaking BIOS settings and learning the fun of redundant work sounds like an awesome week with so much progress made, eh? Quite.
Debugging should have its own class somehow in undergraduate requirements. I don’t care that people have their own method. Every debugging method boils down to the same handful of steps; what differs is the artistic way the steps are executed. Debugging a big file you didn’t write is scary. Especially when you’re a total n00b at the language. Just those ten lines I used to expanded a function brought with it a whole heap of warnings and bugs thrown up on the formerly working-ish program. Good documentation and cout statements were pretty much all that saved my sanity. Google is a great tool until you don’t know how to properly phase the bug in general terms.
The frustration iceberg was trying to find a compromise between perl variable syntax and command line expressions. Working around that one turned into hours of creative reworking to avoid any need for awk. Changing $1 to /$1 may be great for telling perl to not touch that variable. The command line, however, looking at that fix will act five year old being asked what is the square root of negative three. Failing silently is the worst problem a debugging entails. Wait, spending hours elbow deep in Google trying to figure out why an entire command line isn’t being grabbed only to learn oh...it’s not actually the code you wrote. Someone else’s piece is acting weird. Good documentation folks: not just a lame requirement but a means to cutting that debug phase in half if you can rule out bugs coming from pre-existing code.
A result of all this real world style programming has been a major change to my debugging method. I’ve started documenting outside of my code what steps I take to debug. It helps me revert on the fly back to old settings without bulk commenting out changes. Just because sometimes it won’t be your lines code that is causing the barf of bugs. Oh and updates? Don’t necessarily trust them, they can mess things up too. I’m looking at you Apple: ios4 has been a mistake to older generation devices.
Step back from the programming side of things. Appreciate how simplistically elegant the BIOS interface is for navigating. Getting into the BIOS itself can be an hour of frustrated restarts, mistimed keys & not hitting the correct key. Hint: it’s always delete. Except when its escape. Or when it’s F11. At least the restart button is universal. I give mad props to the BIOS interface though, because by enabling SpeedStep my data collecting life became easier. cpufreq actually started sending legit verbose data! cpufreq happens to be directly linked to a component within our benchmark software, which in turn is used when examining the collected data. Nothing important to hurry and get working you can imagine.
My tasks this week often had nothing, or very little, to show for themselves given how long they took to execute. Patience was key for jumping to the next task. Patience to integrate new information debugging brought and sucking up the pain of opening yet another instance of google or terminal. Patience is the hidden side to research. And lies. Lying to yourself that all that hard work gone unseen this weekend did something will be easier to accept under the lies of sprinkles & cherries on top.
No comments:
Post a Comment