Richard Feynman, the famous physicist, had mentioned that he had lost the inspiration to find new and useful ideas in physics. He also apparently was in a rut for it, where upon he just gave up on thinking hard about it and decided to let his mind meander to do whatever it felt like. The ends result was that he ended up winning a Nobel prize for his mind meandering when he came across a student in the Cornell cafeteria spinning plates and noticed that the plate had a 2:1 wobble to spin ratio. After performing the physical calculations and being chided by one of his colleagues that the analysis he was doing was "useless," Feynman would go on to win a Nobel Prize for a derivative work from the calculations he did from the wobbling place as it was related to electron spins in quantum electro-dynamics. For those that are interested, a small part of the story can be found here, and if you do have a chance, I highly recommend Feynman's book, "Surely You're Joking, Mr. Feynman!" as a great read.
I too would run into a similar problem these last few weeks after being thrown into the flame of writing simulation scripts using a terrible scripting language. The syntax is strict, variable names are strange and the compiler doesn't accept lowercase letters in the code. The code looks like Perl on bad crack and it's surprising how people can get work done in this language.
I have a colleague working on the simulation project and he's build up a code base over the last 2 years, he's resigned to bashing through this programming language to run simulations. I've tried to read the code and fell asleep multiple times and got several headaches as a result of trying to follow a convoluted path of variables. split across several files to figure out what it going on.
Traumatized, I gave up trying to write code in this language. After 2 days of trying to understand the code, I was pretty much in a rut with this terrible code and resigned myself to clearing my head by working on other projects and taking really long breaks. Nearly a week later, after getting a handle on the fundamentals, I was struck with an idea-- basically, I would write a program to writes the simulation script and I would by pass all the terrible variable handling by natively managing variables in a different language. I managed to clean up the interface considerably, write a main processing loop where I just throw cleanly designed data sets to generate complicated physical structures with simple commands.
What my colleague would need nearly a week to testing and debugging, I could do the same thing in an afternoon. After joining my colleague in the simulation team, we're going to throw out all the old code and redesign everything using my framework.
Perhaps it is an inherent trait in me, that I hate using an inelegant system to do something and my natural instinct is to run away from the problem until I find an elegant way of dealing with the problem. Sure, I may have been goofing off for the past week, but I've figured out to nearly multiply my productivity by a factor of 4~5 over my colleague and will be bringing him up to my speed after I teach him how to my code. Increasing the productivity of 2 people by a factor of 4~5 is huge when it comes to the amount of cost savings the company yields. I will be writing about this in my winter evaluation report no doubt.
Though this story may sound like that it serves a didactic anecdote, that running away from hard problems is a good idea, I assure you that it doesn't and there are times when it is necessary to roll up the sleeves and to the heavy duty grunt work. The question is knowing when to run and look for better solutions vs getting on with it is key. Maybe I'm just lazy, but I generally like attacking problems when I have an idea to make it easy to solve, otherwise, I'll be doing other things.
No comments:
Post a Comment