So I’ve mentioned before that I’m currently working at the Rutherford Appleton Laboratories on image sensing devices (“camera chips”, for any laymen who may have wondered in this evening). I’m mostly working on experiments for a new technology called Single Photon Avalanche Diodes (SPADs, as they are affectionately known) which can detect the smallest amount of light possible – a single photon (hence the name).
Now the SPAD project at RAL has been going on for some years and so has accrued a lot of different variations – we have several different kinds of designs and multiple different circuits to run them. Of course, that means that when a deadline comes up for something important and I have a new batch of chips to test, it can get rather busy! I must spend as much time swapping out pieces of equipment, debugging the software, compiling results and figuring out why they don’t give us what’s expected (seriously – that’s how science is).
The result of all this peripheral messing about is that lots of things can go wrong in some way – be it a wire in the wrong place, or a SPAD exploding mid-test or my own clumsiness shearing off the extremely delicate bond wires with a screwdriver (this really happened). Things go wrong, and they do so with surprising regularity. That means that any deadlines I get I have to work extremely hard to meet! Not only that, but a serious problem could make me miss the deadline.
Because of this, I usually end up starting work on anything remotely like a deadline so far in advance that it seems ridiculous – because experience has shown me that I must in order to avoid failure. This has hit home particularly hard recently, where a deadline I started working on well over a month in advance (and which seemed easy at the time) became a bottomless pit of problems, frustration and sheared bond wires. In the end, I managed to get it done on time – but only through an extremely stressful week or two culminating in one very long day of panicked rush to get things ready.
It’s made me realise one of the unstated advantages of work experience such as the MPhys placement I’m undertaking here at RAL. Namely, that you gain a real appreciation of how hard you have to work to get a real experiment planned, set up, debugged, and working on time. It’s not something that one usually learns in the sheltered environs of the University campus, and I think it’s an important edge to have over other graduates in the competitive world of PhD hunting. It’s a lesson that you know your future employer/supervisor won’t have to teach you and you can tell them so, which is far more interesting and useful than graduating quickly.
And once you’ve learned that lesson, it impacts your day-to-day thinking, too. I’m finding myself starting to think more in advance of big things than I’d have done if I hadn’t had the stress of last-minute deadlines here at RAL. I’ve learned something about how to win at life, and despite the horrible workdays I’ve had it’s been completely worth it.
If there was ever a better reason to do a placement than “because you get to win at life”, I can’t think of it! ^_^
One of the very specific things I’ve learned recently is that in order to plan a proper experiment, you have to start by understanding exactly what the problem is. By that measure, some of the more involved experiments I’ve started working on recently are being planned months in advance. Some of the preparation for a particular favourite of mine started way back in May and won’t come to setting up equipment for several weeks still! So, perhaps I can pass on some of my experience to other people early in their science careers with my favourite device; a list!
- Planning starts with understanding what the problem you’re addressing is. That means understanding the theory behind the problem to a good degree, which in itself can be a significant project. For me, this usually takes up to two weeks of moderate thinking (which isn’t equal to actual work done) but can be more if I actually have to derive something myself. Your mileage will vary depending on your thought processes, etc.
- One you’ve understood the problem, you have to look at potential solutions. By this, I mean you need to understand what you need to measure and invent (or adapt) a way of measuring it. Depending on your funding/experience/department/extra workload, this can take anything from a few days to a month or more. A good extension to this bit is to check if anyone else has done a similar experiment (start with Google, move towards textbooks and the scientific literature) – if someone else has a procedure you can use or has shown potential missteps, this is the time you want to know about them!
- Setting up is what many people might consider the “start” of the experiment. Here’s where you gather up all the things you planned and put them together for the first time, and run some basic preliminary tests (on references) to check you’ve got a working system. If all goes well, this could take a day or two – more likely you’ll be at this a week if you have to debug things. Again, mileage varies – hope this goes well, but don’t plan on it!
- Execution of the experiment takes a varying degree of time, but invariably this is the time in the experiment where you will work the hardest; you often have to sort out yet more problems as they arise, and on top of that you have to make sure the data you’re taking makes some semblance of sense. Don’t underestimate the importance of that last sentence; it may cost you a week’s worth of work!
- Finally, the analysis of the experiment is the “easy” bit assuming that you understood the theory and made sure your data is sensible. A good experiment takes reasonable precautions in the setup stage to ensure that the data will come out in the right format (with as few bugs as possible) and runs continual preliminary tests to check that the system is working as expected. Once you have your data, you can analyse it (hopefully) in peace. Congratulations on a completed experiment – you should now have yet more questions you want to answer! Go to “start”, collect £200 from the bank.
I think overall it’s also a very good idea to keep an overall perspective of how your experiment is developing and working, the previous iterations and failed attempts – this is, of course, where good use of a logbook comes in (thankfully, this is one thing one is taught excellently at University).
If you found this helpful or interesting, please share it to people who might find it useful. On the other hand, if you have any criticism or feedback, please leave it in the comments and I’ll do my best to respond appropriately and update the post.