Programmer at Large: Can we speed that up?

This is the latest chapter in my web serial, Programmer at Large. The first chapter is here and you can read the whole archives here or on the Archive of Our Own mirror. This chapter is also mirrored at Archive of Our Own.

Note: This is more of a chapter fragment than a full chapter. Sorry.


The report only took about a ksec to compose – it’s not like there was a great deal to say. “Look, some legacy code that we should raise the rewrite priority on” is practically routine. I had weak evidence that it was a root cause for a problem, but more importantly it had raised its head and got in the way, and for something with this many red flags on it that was a sign that we should look into replacing it. Step one of that was simulation.

I thought for a bit. Of course, there was no reason we couldn’t do step two in parallel, and it would make the eventual simulation much easier and higher impact.

“Ide, can we synthesise a replacement program?”

“We lack a sufficient formal model of Go# to do so formally, but the program interface is sufficiently constrained and the typical program lifetime is short enough that it is likely that an empirical sampling method would suffice to guarantee a replacement within no more than five megaseconds.”

“Hmm. Can we speed that up?”

“Given sufficient simulation resources a trial candidate for phased roll-out could be synthesized in approximately 500 kiloseconds.”

Ugh, right. Simulation time which we didn’t have.

“OK. Start synthesizing a replacement in real time then.”

“Scheduling now.”

That was probably about as much as I could do with this particular program in isolation for now.

“Is there anything downstream of this?”

“Program influence terminates in physical control of plumbing temperature regulation with no additional software control.”

So, effectively, everything was downstream of this. The problem with working on plumbing is that the main communication channel was the physical environment. It makes for some… interesting interactions.

I checked for Kimiko’s availability and got that they were still busy. A quick check of my social modelling software confirmed a hunch: Around 60% chance they were stalling me.

Oh well. That was their prerogative, and I could certainly understand wanting to put off a difficult conversation.

I wasn’t exactly sure how they would know that this was going to be a difficult conversation, but other people were weirdly good at spotting that kind of thing.

I decided to to continue working to distract myself.

“Ide, give me another interesting issue in the area.”


Next chapter when it happens. Nominally in two weeks time, but the schedule has become very erratic. Hopefully the next one will be longer.

Like this? Why not support me on Patreon! It’s good for the soul, and will result in you seeing chapters as they’re written (which is currently not very much earlier than they’re published, but hopefully I’ll get back on track soon).

This entry was posted in Fiction, Programmer at Large on by .