Body heat

When explaining the mechanics of a blanket, one needs to at least be wary of the difference between “keeping the cold out” and “keeping the heat in”.

One alludes to the body as a heat source, the other victimises us as captives to our environment.

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.

An equation for creating awesome

We were bantering in a post-dinner conversation about what sort of ventures would be worth getting into – one of a narrow set topics where you’d find me readily available to engage in and ernestly contribute to.

The discussion took a turn to a well trodden topic of “If you had xxx, what would you do with it?”. N had much insight to offer to the effect of constraints playing a crucial role in driving good design, and how it’s next to impossible for good design to come out a blank check.

We got talking about what kind of awesome we could conjure up with the skills that were at the table; what creations we thought were excellent in that they were highly considered and truly added value to their respective contexts, and shortly after, arriving at an echelon of products whose sole purpose laid squarely in sheer opulence; created for no other reason than for Mr. Ritchie Rich to outspend his peers.

It was then, something became clear to me: what thrilled me most in my pursuit of creating awesomeness is somewhat captured in the following equation:

Fa (awesome factor) = outcome produced / resources committed

Where Fis greater than 1, we’re winning. Where Fa is less than 1, not so winsome.

You could start by sticking some values in. Say 4 coins were spent creating a doodad that was then sold on for 5 coins.

5 / 4 = 1.2 Fa ⇒ winning

If 5 coins were spent creating a doodad that couldn’t be onsold for any more than 4 coins,

4 / 5 = 0.8 Fa ⇒ not so winning

A second example: 5 hours were spent creating a widget that saved 1 hour a day. It’s a little more interesting, because on day 1, it’s looking like

1 / 5 = 0.2 Fa ⇒ not winning

But as the days carry on, things start looking better

Day 5:
5 / 5 = 1 Fa ⇒ tie

Day 50:
50 / 5 = 10 Fa ⇒ awesome winning

And if 50 people had access to it for 50 days:

50 × 50 / 5 = 50 Fa ⇒ mmmmmmonster win

On the flip side, we encountered the provervial “money is not an issue”, things start looking bleak for our little equation.

For example, a thousand coins spent to produce the world’s most exquisite disposable luxury toothpick.

value of a disposable luxury toothpick / 1000 coins ⇒ difficult to win

£3bil for a gold encrusted yacht:

gold encrusted floating device / £3bil ⇒ even more difficult to win

compared to

medium-sized aircraft carrier / £3bil ⇒ a little easier to win

compared to

2 × 360-bed metropolitan paediatric hospitals / £3bil

You get the idea.

Where things really start to fall apart and kill the party is when the resources available approaches infinity, which is one extreme that many a naïve idealist operates with:

(most awesome-st idea ever) / ∞  = very near to 0 Fa ⇒ no fun

The other extreme is the magical unexecuted idea:

(an idea) / 0 = ∞ Fa ⇒ delusional

Conclusion, awesomeness is a function of two values, the resources required and the final outcome. This means that awesome can be sought after in two places: first, incremental outcome improvements over predecessors, and secondly, exponentially doing more with less.

Enjoyed this post? Show us some upvote love on Hacker News

My TDD addiction

After over two months of deliberately attempting to adhere to the practice of Test-driven development (TDD), I started working on a sizable chunk of untested code. Here are some of my reflections on the contrast between tested and untested code.

TDD is an arduous process. When you’re coding up a solution, not only do you need to figure out what code needs to do, you are also forced to componentize the solution in a way that is unit testable, if only to make the test writing easier. This is especially annoying when you’re working on procedural functionality that doesn’t decompose naturally. This forced decomposition has its benefits, though, as it “encourages” one to produce simpler and more understandable code.

One of the other luxuries afforded by having tests is how easy it is to hand over code from one developer to the next. The test suite provides a very quick and comprehensive way to verify that existing functionality is not broken without the new developer having to be across the board with the codebase. Speaking of verifying functionality, the scaffolding provided by our test suite has allowed us to execute and complete major code refactorings in very little time.

But back to my experience with the untested piece of code. I couldn’t help feeling a sense of trepidation as I worked my way through. Maybe it was because it was unfamiliar territory for me. Perhaps it was because there was no way of me verifying that I hadn’t stuffed anything up without first fully understanding what it does.

But one thing is for sure, the last two odd months have made me very dependent on tests. Addicted even; which makes me wonder if that is a good thing.

The shifting concept of permanence

Over the past week, my latest geeky little project has been to take a look at all the IT infrastructure that I operate and rearrange things around a little to match its current utility. Nothing drastic, just tweaks here and there, consolidating a few VPS‘s, swapping out email services and setting up a more robust DNS solution.

Which has brought me to today’s reflection on permanence and the irony of how such a concept survives in our hyper-transient digital world.

Permanence is typically associated with physical mass and tangibility, while transience, the lack thereof. A dead-tree bank statement bears far more permanence than a PDF. Molding a lump of clay with your bare hands, more than pushing polygons. Capturing light on photo-sensitive celluloid more than voltages on a CMOS chip.

But something dawned upon me as I was fixing up some mail forwarding settings for my primary email address: I’ve changed my physical real-world address at least 5 times since I last swapped email addresses. Going a little further, I must have gone through many more mobile phone devices since I signed up for my current mobile number.

Somehow, or some why, these very transient entities (email addresses, mobile number) seem to have lasted far longer than items that we traditionally deem “more permanent”. Don’t even get me started on how difficult it is to mop up an incriminating information leak, or an embarrassing photo on your social network.

This surely begs further and more thorough discourse, but here’s where my thought ends today. Maybe you’d like to chime in: how does such a shift affect the we live, and the way we value things?