Lots and lots of progress made this week, despite a weekend’s worth of development time lost to Stardew Valley. Oops! I suspect some of you are in the same boat.
Nevertheless, let’s get on to the good bits.
Tag: Coding
This is how I find bugs
I walked into the kitchen, and put the kettle on, and put the fixings for coffee into my mug. The cat was bugging me for milk, so I gave him some.
He wouldn’t touch it, but just stared at me.
I petted his head and rubbed his back. Then he got into the milk. He needs the full dining experience.
I went to the back door, started rolling a cigarette and half-way through a nagging something in my head tried to get my attention.
“Oh, bugger,” I said out loud.
I’d found a bug in my mouse-interaction code. It was code that I hadn’t touched, or even looked at since maybe August last-year, when I wrote it initially. A nine-line function that turned mouse-clicks into proper UI-widget interactions.
Suddenly, the shape of that code was floating in my head, and it was the wrong shape. It didn’t … fit.
The code had never misbehaved, or done anything wrong, but that wasn’t the point. I knew it was wrong, and I had a feel for how it would misbehave. Even if I couldn’t remember the exact lines of code.
My instinct was telling me that mouse-clicks might pass through non-reactive UI elements and trigger reactive elements underneath. That had never happened, to my knowledge, but I was suddenly certain that it would.
So, I aborted making coffee, and my cigarette and went and looked at the code.
I was right. It was wrong. It would behave in exactly the wrong way that I had envisioned, if the circumstances ever came to pass (and they would!).
So, I fixed it. New code. New shape. It settles in more comfortably now.
This, though, is how I find bugs. 90% of the bugs I find aren’t because something goes wrong. In fact, the game behaves perfectly. It does everything it should, exactly as it should. I’ve seen no sign that there’s an issue, and nothing’s been reported.
But I’m in the bathroom, or having a cigarette, or trying to sleep, and there it is. I suddenly know that a bit of the code isn’t right, and in what way it isn’t right. There’s a kind of synaesthesia at work – the codebase exists in my head as a collection of shapes that aren’t shapes, and colours that aren’t colours.
Whatever I’m doing, or wherever I am, some part of my brain is walking over that model, looking for anomalies. And finding them wherever they are.
Eventually.
It would, perhaps, be nice if it could announce them right away, while I am actually writing the code, for example, but no. It chugs away in its own good time doing a whole-program analysis, and then bugging me about it when my attention is on other things.
At four-thirty in the morning, some noise sets the dog barking, which wakes me up in turn, and then that synaesthestic model is hanging in my head, focused on a rendering function, or caching algorithm, that’s working but is invisibly buggy. And I know what’s wrong. I can fix it in five minutes. If I got up.
Getting back to sleep again – or maintaining any kind of task-focus on anything else – is pretty hard when you’ve got one of these things dangling in your forebrain, insisting on being fixed.
Finding bugs the way regular people do (when things just plain break or misbehave) seems like a lot less trouble.
Being great doesn’t mean you’ll always do great work
Last night, I tried to write a simple function. It should have taken me about a minute to write, and eight lines of code.
I got it wrong. Very wrong. Astonishingly wrong.
I got it wrong in every possible way you could get it wrong, and in a few entirely new impossible ways, apparently artisinally-crafted just for the occasion.
In short, I screwed it all sideways, and sixty seconds of code turned into somewhere North of two hours of swearing and debugging.
Today, it’s all genius again. Less than a dozen lines of code adds optional mouseover logic to my widgets, which gives them a delicious, customisable, tactile feedback. Great code. Elegant, concise, and correct.
I revisited last night’s code and fixing it was trivial and obvious.
Look, it doesn’t matter how good you are. You may be smart, skilled, and experienced. You can know your language inside-out. You can thrive on it like some cyborg supercomputer hybrid. You can be a genius among geniuses.
Sometimes you are just going to be unable to sit down and do the thing without completely bollixing the whole thing up, and bollixing it worse when you try to fix it.
You will have times like this. Fifteen minutes. An hour. Two hours. Maybe a whole day. It will happen.
Own it, because it’s going to get you now and again. Sometimes you will screw up the simplest arithmetic. Sometimes you can’t get something right even though you’ve done it a thousand times, like a champ.
If you can’t do the thing, do something else. Have coffee. Play a game. Help another team-member. Get lunch. Take a nap. Ask someone else to do it. Sit in the garden and sob inconsolably – whatever works for you. Just walk the hell away from what you’re screwing up and come back to it when your head is back in order.
An even more important lesson here is to help others deal with it when it happens to them, too. Because it will, and dissing them about it makes you an arse.
Screwing up is less important than properly dealing with it.
I should have closed my editor at least an hour sooner than I did, and done something else. Instead, I kept burning time in The Pit of Fail.
Don’t do that. Do something else. Do anything else.
Development Progress Report, week 23-24
I missed last week’s development blog post due to the pressure of other things, so I’ve got two weeks to cover.
On the narrative side, I’m nearing a long-awaited story milestone. The prologues are complete for each of the eleven protagonists, and all but two of them are written through to the end of the rather dense and complicated first day of the story proper. Once those last two characters are written through, that will represent a major milestone.
That brings us to (today), 88 scenes and 232,814 words. That’s more than Dune (the book), or Neverwinter Nights (the game) [This isn’t a competition!], but we’re not really into the full swing of things yet. That will be in the second Act, which is where the bulk of the narrative technology should start to shine (I hope!).
Development Progress Report, weeks 20 and 21
There wasn’t a status report last week, because I was without electricity and an Internet connection, as a result of several days worth of getting the house rewired. Even this update is posted a day later than I’d intended.
That is past, and a lot got done during the rest of the time!
Continue reading Development Progress Report, weeks 20 and 21
Development progress report, week 15
Development is picking up again, with some actual measurable progress towards the next milestone. Despite, again, not being able to spend much time on it.
The narrative is up to 213,734 words, which is 5,081 words up from last week. A number of narrative glitches got fixed, and there’s only a few more character narratives to complete to close in on the target point of the narrative, that comprises the development-milestone.
Development progress report, week 14
And we’re back after a gap of a couple of weeks. Melbourne International Games Week was a bust for me, thanks to some badly-timed medical problems, and a life-threatening illness in the family, which is no longer life-threatening, but still remains unidentified.
After a two-week gap, it has been a bit tricky to try to get back into things, but actually enough got accomplished to be well-satisfying.
Development progress report, week 12
So, it’s the start of development week 13, and I’m looking back on week 12, trying to figure out how it all went.
At first, I wasn’t exactly super-satisfied with it, but I’ve changed my mind.
Show me the code: cpuid and popcount
So, modern CPUs have built-in functions for a lot of things, these days, which can offer you blisteringly fast access to some otherwise rather awkward and slow algorithms.
In my case, I wanted to access the CPU’s popcount function (count how many set bits there are in a value). The trick is that either the CPU supports it or it doesn’t, and different systems have different ways of testing if it does, and accessing it if it does. Of course if the CPU doesn’t support it, you still have to do it in software anyway.
So, I thought I’d write something extensible, and I thought I’d share.
That’s what you get
What do you get when you rework, redesign, extend and simplify your conditional expression evaluators? You get bugs, that’s what you get.
Thankfully, nothing was terribly difficult to figure out, once I’d actually discovered that the bug was there at all. The problem was that I didn’t notice for about a day.