Today’s post is a competition: I have code running, the results of which I need to see to proceed. When the program terminates I will wrap up this post; thus the briefer this update, the faster (and better) my program must be!

Thrice I’ve attempted to write up comprehensive summaries of what I do, both at school and at work. Thrice I failed; I think that the topics are too involved to summarize succinctly. I always find it difficult to choose a “stopping point” in any explanation: ask me a technical question and I may open with “In the beginning…”

At school I am writing code to prove a particular statement. Originally my goal was to prove error bounds on an existing program that used an approximate technique; I would have shown that no amount of rounding error that could have occurred was great enough to cause the program to say “no” when it meant “yes”. At some point I determined that the program could be written to answer the question exactly, without approximation, and so started work on a new version.

Tap on the hourglass and it’s several weeks (months? I don’t have a good grasp of time estimation.) later. As of today, all of the functionality is in the program and theoretically it is a complete “first run”. (My boss likes to say that a program is only “done” when you can’t stand to look at it anymore, so this code is far from finished!). The new program answers the question without approximating and also runs significantly faster than the old program.

The next step is to write a paper on the purpose, methodology and results of the program. I have yet to establish the exact scope of this paper; I am very new to this work and most of what I do involves ten steps of gathering background information before taking one step forward.

Today, then, is a bit of a milestone as I have a somewhat complete suite of programs that produce some actual results. Granted, I’ll probably look back in 6 months and think “gee, that took me how long?”, but there it is.

Things are progressing slower at work. One of the the company’s main products relies on a component for which production has ceased (but will remain available for a while); my job right now is to design the next version of the product, replacing the component in question, and supporting an additional feature (a faster speed). I have been working on this since January and reached my second functional prototype a few weeks ago.

I should stop and say something about school-versus-work: my main priority is school and my research. I work part-time, which accounts for some of the slow progress. Research is more intellectually stimulating and interesting, while work is more physically rewarding. I can prove a theorem at school and then go home and see my device function – the combination keeps both subjects fresh. I find that when I’m just getting tired of looking at my code run at school I’m ready to go home and start work, and when I’m just starting to grow weary of paging through the USB spec at work I’m ready to head to school and get back to math.

Back to the subject of work. I finished my second prototype and began the next stage of design. Unfortunately I am being bogged down by intermittent bugs that are dependent on external behavior. For the past few days I have been fighting with this problem and have yet to make any headway.

I find that my progress at work comes in short bursts of enormous productivity which are then halted by difficult-to-detect mistakes. I will likely spend the next few days working on the current problem, but then complete the rest of the third iteration of the code in a series of marathon sessions over the weekend. Knowing this doesn’t make the bugs any less frustrating, however.

So while work moves slowly I have reached an important point in my research. With any luck I’ll find a breakthrough at work in the next few days and make progress on writing the paper for school.

My code has terminated, telling me I am finished with this post. The program yielded the expected answer: 12. Gee, all that work for 12? I could have told you that!