https://juxt.pro/blog/posts/clojure-in-seattle-world-singles-networks.html
3 Likes
I’m happy to answer any follow-up questions that folks might have, based on that interview/blog post!
2 Likes
Often times many experienced clojurists claim clojure’s concurrency primitives as an important arsenal and possibly a super power in clojure’s repertoire. How important has concurrency been a factor in building of and sticking to clojure in World Singles Network’s case if any?
As the interview says, when we first got started with Clojure, we were able to sprinkle pmap in a few places and get crazy amounts of concurrency so that was very powerful. Of course, pmap is a bit of a sledgehammer and you don’t get a great amount of control with it – but it can be very effective for certain situations. We use future a lot, both for “fire-and-forget” processes and in our reporting engine where we’re performing a number of complex queries and combining the results. We use agent in a handful of situations. Over time, as we’ve wanted more control over concurrency in a number of areas, we’ve wrapped Java’s Executor functionality up and exposed very simple, Clojure-like concurrency backed by controlled thread pools. And, finally, we have several applications now that are heavy users of core.async which allows heavily concurrent applications to be broken down easily into a series of communicating sequential processes.
I’d considered Clojure’s “simple concurrency” story to be very important to why World Singles Networks sticks with Clojure.
2 Likes
Thanks for the answer it is quite useful. You mentioned that a number of applicants wanted to do clojure were good in other tech, did these applicants had any clojure experience on personal projects or they were curious about clojure without any serious effort on the github/personal projects front?
How do you find time to contribute/maintain so many libraries? Is it because you have an efficient workflow/tooling? Working over time? In your free time/weekend? Thanks to boot? Of course it’s also because you’re quite comfortable with Clojure, but this is not the part of the answer that interests me.
Regarding GitHub, it’s worth mentioning that using published, open source projects as a measure of a candidate’s suitability is fundamentally flawed and bad for diversity. There are many valid reasons that candidates don’t have GitHub footprints: they may work for a company that disallows employees from contributing to open source, or they may have other commitments that prevent them working on software-related projects outside work hours.
If someone points me at their GitHub repo from their resume, I will go and look at it but I’m more likely to use it as a disqualifier if their published code is sloppy (non-idiomatic, lacks tests, lacks documentation, etc). 
As for the candidates who applied that didn’t have production Clojure experience, that was generally a disqualifier for us simply because we’re a small company with a small development team and it’s not reasonable or practical for us to hire someone who can’t hit the ground running in Clojure already. As I said in the interview, if you’re a company that has bandwidth to train/mentor Clojure beginners, there are plenty of willing candidates!
1 Like
I’ve essentially built “working on open source projects” into my workflow over the years – and it’s a requirement of any employer that I am permitted to continue working on any OSS projects that I’m already maintaining without a conflict in IP (I’ve adjusted employment contracts in the past because of this hard requirement). I also tend to probe potential employers about their attitudes around OSS to see whether they are supportive/open to releasing some work code/projects as open source. It was one of the things that frustrated me about Adobe, after they acquired Macromedia (where I worked from 2000-2006) – Adobe’s attitude to OSS was much more restrictive than Macromedia’s 
I tend to work on OSS outside work more if my job has me doing less coding (or less interesting coding) but I try to schedule part of my regular work time to maintain OSS libraries. That’s relatively easy to justify if they’re ones I use at work (again, if an employer doesn’t consider that appropriate, that’s a red flag to me).
I don’t think efficient of workflow or tooling really has any impact on it. I’m mostly happy to work with whatever existing tooling a project has (although I’ll certainly propose improvements if I think it’s worth doing) – and for any new projects I start (often ones that I peel off from something we’re doing at work already) then I’ll continue with whatever tooling I already use
2 Likes
Interesting answer there, never thought it could be used as a disqualifier.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.