Category: developer

Posted on

Learning by reimplementing

I’ve been trying to pick up Clojure. My key motivating factor is the hope of one day being able to appreciate the gravity of the LISP family of languages, unveil the power behind S-expressions, dabble with the somewhat black art of concurrency and functional programming.

Thus far, it’s taken me the earlier half of 3 books on Clojure to get to this point where I’m relatively comfortable with the syntax and some of the idioms of the language. But because of its terseness, Clojure doesn’t afford a newbie very much “typing time” to digest and soak in the language. In Clojure, you start your first paren, and before you know it, you’ve executed the code in the REPL successfully – no mistakes to learn from, no cryptic error messages to keep in mind.

I’ve recently picked up a book called Programming Intelligence. It’s a book about data mining, machine learning and other meaty AI stuff with all its code samples in Python.

So what I’ve been doing as my latest stage in Clojure learning, is going through the book, digesting the Python code samples, and reimplementing them in Clojure.

Here’s an example of a snippet in Python:

And my version in Clojure:

I’ve only done about 3 snippets so far, but I feel like I’ve learned a lot because I haven’t simply copied code out of a book (which hasn’t really worked for reasons stated above), nor have I had to “come up” with things to implement. By reimplementing code from another language in Clojure, I get to practice the syntax while copying the algorithms.

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

A simple expense tracking app

Two friends, on two separate occasions, expressed the need for a simple mobile app to keep track of daily expenses. Apparently there are lots of apps out there that try to do it, but try to do too much and end up overcomplicating the simple task of recording where and what one has spent one’s money on.

It sounded like a nice little project that I could use to sink my teeth into mobile development, and maybe even bust a few moves with my design-fu that has laid dormant since I took up my current full-time role as a developer.

So, since the recent weekend, I’ve been working on little app to do just that – keeping track of daily expenses, and telling you where all your money went. Hopefully, it’s reason enough for why I haven’t been blogging as profusely as before – I’ve been coding on the train!

I’m still keen to continue posting here, hopefully there will be progress updates on the app.

But maybe you’d like to help me out by answering some simple questions using the comments box below.

  1. How do you keep track of your daily expenses?
  2. Would you use a mobile app to do it? Why or why not?
  3. Do you use any form of categorization?
  4. If your wallet kept track of all your expenses, what questions would you ask it?
  5. Any other ideas?

Wish me luck!

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.