Playing with ClojureScript: Illustrating a Monte Carlo experiment in browser

By day, and by most other occasions, when at a computer generating code, I’m often rather far removed from the web browser. I typically spend my time building systems that deal with massive amounts of data, running on a bunch of servers. Visualising or exposing this in a UI is either an afterthought or left to someone else. And I feel the back end is the area I enjoy working on the most as well, but it doesn’t mean I don’t see the value in good UX and UI in general.

Often having a good interface is the only way to show and tell the story. So a few weeks back when I wrote a simulator for a little company, with parameters for who you’d hire, fire, and how you’d train and retain good employees, I wanted to write a blog post about this. But I found it really difficult to imagine how I’d write and present this in a solid manner.

As I’d initially written the code in Clojure, I thought I’d venture out into new territory and give ClojureScript a try. As ClojureScript is supposed to be just a dialect of Clojure, targeting JavaScript rather than the JVM, this didn’t pose too many challenges. The core simulation code remained unchanged, with just UI code added to make it look good in your browser.

Blender Corp HR simulator

Above you see a screenshot of what you find over at the “Blender Corp webpage”. Most of the stuff you see in that web app is described there, so I’ll focus on some of the technical details below. The code, by the way, is over at GitHub.

Core the the dynamics of the simulation is the transition probabilities of employes. We divide employes into 5 categories:

A-level, B-level, C-level, D-level, and F-level. A-level employees represent the top notch people, with gradual reduction in quality from average C-level to F-level failures. It’s assumed that A-level employees have more external opportunity. They are hot goods, with plenty of opportunity. They also demand more from their employer, being less happy about working with less skilled people.

These behaviours boil down to a set of transition probabilities:

(def transition-for-level {
   :a {:stay {:stay 0.6, :leave 0.4}, :leave {:stay 0.1, :leave 0.9}},
   :b {:stay {:stay 0.7, :leave 0.3}, :leave {:stay 0.2, :leave 0.8}},
   :c {:stay {:stay 0.8, :leave 0.2}, :leave {:stay 0.3, :leave 0.7}},
   :d {:stay {:stay 0.9, :leave 0.1}, :leave {:stay 0.4, :leave 0.6}},
   :f {:stay {:stay 0.95, :leave 0.05}, :leave {:stay 0.5, :leave 0.5}}})

You’d read this as: An A-level employee, currently working for the company (:stay), have a 60% likelihood of staying, 40% of leaving. If the A-level employee is currently leaving the company (:leave), there’s a 10% likelihood of making them change their mind.

All the way down for an F-level employee, he or she is a lot more keen to keep on staying in the company, with only a 5% likelihood of quitting, and a 50/50 likelihood of changing their mind if about to leave already.

It’s clear from looking at this that keeping high level employees is a lot more difficult than keeping less good employees, and this is the challenge for any company. I’ll leave it with you to play with the parameters and code, feedback and comments are welcome as always.