Category: programming

Posted on

On expressing intent

In programming, one of the hallmarks of well-written code is the fact the code communicates intent. For example, a piece of code could be taking a list of integers, summing them up and dividing the sum by the number of integers involved, but it makes it far easier when the piece of code is actually labelled getAverageValue.

That is intent.

Being able to communicate intent when coding is especially important when working in the context of a development team. Chances are, somewhere down the track, another programmer will need to interact with, or make changes to code that you’ve written. When that time comes, one of the first questions he/she’ll be asking is “what was the author trying to do?”.

getAverageValue
Success!

“Loop over a list, sum up all the elements in the list, count the number of elements in the list, divide the sum by the count”
Fail.

Coming clean with intent isn’t always easy though. In the limited example above, explicitly stating that one’s intention to derive an average value quickly opens oneself up to criticisms on technique, algorithms used, coding style, etc. So vulnerable is such a position that one would often prefer NOT to state intent, opting instead to just step through the instructions one at a time.

But here’s the nice thing about communicating intent – it opens up a space for individuals to share and collaborate over a piece of work.

You see, to put forward intent is a posture of respect toward the other party. It is an invitation to collectively deliberate over a matter. Correspondingly, to ask “why” is a request to participate in one such engagement.

For example, instead of just saying

“Please do this because I told you so”

one might instead say

“Please do this so that the world will not come to an end”.

No prizes for imagining the effect the former statement might have on a conversation. The latter, on the other hand, opens up far more opportunities for discussion, i.e. –

“I don’t want the world to end either, but here’s possibly a better way to achieve it”

or

“I don’t think the world will end. Let’s talk about why you think the world will end.”

Lots of room to parley and a far better chance of arriving at a progressive and agreeable outcome.

Posted on

System Overhaul

It’s become a bit of a routine over the last two weeks or so. Come in to work in the morning, look at the numbers, find that they have gone off, spend the morning investigating why they’d gone off. Spend the afternoon implementing a patch in response of the findings of the investigation. Leave the system to run for the rest of the day, come in the next morning, check the numbers, find that they have drifted again…

On and on and on, like a never-ending puzzle. Every time, we hose out a category of bugs, only to find another emerge, either from increased clarity, or as a result of the previous fixes.

Everyone was getting frustrated. Not the least, yours truly.

“If you can’t fit the whole picture in your head, something is very wrong”
– Wise words of colleague

It was exactly what I was struggling with. Every morning, I’d come in, look at the numbers going off, and spend a good amount of time just loading up the entire platform in my tiny brain to play out the scenarios, and form a logical explanation for why they were off.

Every patch we added was an added complexity that could very likely come back and bite us further down the track. Some of the actually did.

We needed to take a different approach.

It turned out, we’d made a few design decisions earlier on that didn’t account for one of the “heavier” components coming online more recently. Between the complexities of developing that new component and helping it play well with the rest of the platform, we didn’t have much left behind to even consider revisiting the design of some of the other components.

So we’re going to take some time to reengage the broader design issues and come up with a more permanent solution. Sure it’s weeks of sunk cost down the drain, but it is also potentially months of future debugging that we won’t need to do.

Glad we’ve come this far. No one could have seen this coming, and it’s unlikely that we’d get here by any other way.

So here’s to a new week, a deep overhaul that settles it once and for all, and moving on to productive work.

Posted on

Explain it to someone

Last friday, we had a retro, marking the end of another sprint at work.

One of the points I contributed to the board under the “keep doing” column was to explain what you’re working on to someone.

It’s something that I’ve observed especially in the fortnight that has just passed. A colleague would pull me aside to get some help with a nasty bug, an algorithm or just to get a pair of fresh eyes on a chunk of code.

Colleague would start drawing out the context for the specimen in question, then proceed to explain the problem and the almost-working solutions attempted so far. More often than not, colleague would have an epiphany – “Hey, I could have just achieved it by swapping that doodad with a widget and putting it through an infinite loop!”.

I get my 7 seconds of adulation and gratitude as the bringer-of-all-answers. “You’re welcome, glad I could help”, I respond, too embarrassed to admit I lost him 2 minutes into context.

Love my job.

Somehow, the brain seems to piece things together differently when one tries to explain and vocalize the problem. Solutions simply emerge out of the woodwork, that wouldn’t otherwise come up if one were to merely playing it out mentally, or scribbling on paper.

So the next time you hit a doozie, grab someone and try to explain the problem to him/her. That person doesn’t necessarily need to be across the domain of your problem. In fact, sometimes it’s even beneficial for someone to not be clued in because it forces you to explain harder.

All the person needs to do is pretend to listen, ask open-ended questions like “why didn’t that work?”, nod affirmingly at random intervals, and be okay with accepting unearned gratitude and credit.

Posted on

It will work till infinity

It was friday evening. I was on the train back from work. My phone rang – colleague.

“Dude, is your migration script supposed to run?”

“Er, yes…”

“What were you trying to.. mumble mumble.. cryptic.. mumble.. infinite loop.. mumble.. never going to stop running”

“Erm, okay…”

“I’m putting this on thedailywtf.com“

…

In programming, loops are used to make a computer perform a tasks over and over again. Usually it is something straightforward like:

“Perform this series of instructions 5 times”

Sometimes it has slightly more dynamic conditionals such as:

“As long as there are words in the list, pop a word off and email it to John”

In the second example, if someone or something else is constantly adding words onto the list, or if for some erroneous reason the program puts the word back into the list after emailling it to John, the program will never stop running. That’s an infinite loop.

Infinite loops have their uses, but it’s more commonly the case where an infinite loop shows up as a result of a mediocre programmer’s incompetance, or a competant programmer’s attempting to code while fatigued, intoxicated or stoned.

I was in neither category at the time of coding – perhaps I was seeped a concoction of hurry and a mild lack of sleep. I even tested it on my machine and it ran just  fine.

Still on the train, I pulled up the code from our code repository and started going through each line – just to make sure – before I responded. I wasn’t offended that he’d called me out on my work. If you’ve done bad, you’ve done bad – everyone has a good laugh at how ridiculous it is, and we move on – lesson learned. I was more concerned that something like that had slipped through.

The code looked fine. The only thing that looked remotely alarming was the fact that I was terminating the script early – a typical diagnostic step that I had forgotten to remove before checking the code in. So, thinking that I’d picked the issue, I texted back:

“shit, it looks stupid. but does it work?”

“it will work till infinity”

“but the doodads will run out and the loop will terminate, no?”

“no because the count does not run out”

“nah there is more wtf there. show you monday. have a good weekend”

Good weekend my bleep.

Late that evening, I pulled up the code on my phone to check it before going to bed.

Saturday morning, I checked.

Sunday, I couldn’t help pulling up the code once more just to see if I could figure out how an infinite loop could possibly materialize.

Monday, I rocked up at the office, fully prepared for a public ridicule.

Nothing. It wasn’t there.

The code was cryptic, I give them that, but there was no infinite loop. They were wading deep through stinking warm shit trying to get a live data migration going so fatigue ensued. The fact that my script terminated early without doing anything coupled with my less than palatable coding style set off a cascade of misjudgements that prevented them from actually running the script.

Not their fault. Migrating live data is a high-risk, time consuming and it saps every ounce of attention out of you for an extended period of time. The last thing you’d want to do is to risk running a cryptic infinite-loop-esque function that may cause the system to blow up.

So there. No thedailywtf.com for me this time, but all fun and games all around.

Posted on

Throwing one out pt. 2

Serendipitously enough, the first Throwing one out was written the morning before the following incident.

We’d reached a point on the project at work where it felt like we were wading through thick mud and our architecture choice in SOA was biting us in the behind in every way possible. We were on the brink of implementing some serious monkey-patching to the system which smelled like a very significant design compromise.

Just after lunch, Dev Lead had an eureka moment – we were doing it all wrong. Data and computation were place much further apart than they needed to be! Which basically implicated a “throwing one out” event, and a complete rewrite.

Sure, it’s a lot of effort flushed down the drain, but one can’t overlook the fact that a rewrite with the benefit of a first implementation makes for a far more robust and well-designed end product. At least I’m feeling a lot more confident building it the second time round.

Cycling buddy of mine offered some sage words of advise with regards to bicycle ownership when I was first getting into cycling.

“Start with a cheap bike. Make every mistake possible on it, then upgrade.”

It’s nice, because of the emphasis on learning rather than getting it right the very first time. And it probably is relevant to far more than just bicycling.