In this week’s Clojure Corner, we have asked Sean Corfield to spend some time with us. Jiri our Founder is there and our awesome developer Iain Wood led the Corner time.

Iain: Hi everyone!

Sean: Hi folks!

Just so you know, I’m on Pacific time and not much of a morning person so I expect I’ll find questions from you in the morning and I’ll answer them sometime during the day so you’ll see my answers the next morning, your time.

Iain: Hi there! Iain here. I’m on GMT+7 (Vietnam) so I think you are right there. Just saw your message as I was about to finish for the night.  Maybe we could start with a bit of an introduction? I gather you are also from the UK. How did you end up on Pacific time?

Sean: I was born and raised in Northern Ireland (during “The Troubles”) then moved to the South of England. My early career was in compilers and static analysis tools (including automated coding standards compliance checking), followed by a brief stint in embedded telecoms systems, and then I moved into e-commerce and knowledge management systems (originally in C++ and then in Java). The UK company I worked for expanded its software business into the US, and I came over to run their new Bay Area, California office in 1999.

After about a year, I was headhunted to work at Macromedia as their senior software architect for IT, working in a mixture of C++ and Java. Then Adobe acquired Macromedia and I decided to move on, initially providing freelance consulting services on architecture and coding guidelines for a few years, then moving back into software development for a couple of startups, where I worked with Groovy and Scala — and ColdFusion, which I’d been exposed to at Macromedia after they acquired Allaire.

One of my clients offered me a full-time role as their senior software architect — and that’s where I still work today: World Singles Networks LLC 

After I joined full-time (2010), I introduced Clojure for some backend systems and that’s gradually become our primary backend language: we have a Polylith-structured mono repo, containing 137K lines of Clojure, producing nearly two dozen artifacts (a mix of web apps and background processes).

Iain: There are lots of things I would like to ask about. Firstly how did you discover Clojure? I see you introduced it at World Singles Network so I’m guessing it started outside work first. Was it your first Lisp language?

Sean: I was exposed to Lisp at university in the early ’80s and I went on to do three years of PhD research into “The Design and Implementation of Functional Programming Languages” after that.

After working with Groovy and then Scala, I was keen to follow a more functional style in my code. I don’t remember where I first heard of Clojure but Amit Rathore (author of Clojure in Action) ran an “Intro to Clojure” workshop one Saturday morning fairly near me so I decided to pay the $200 to go learn about “Lisp on the JVM” in early 2010 — and I was hooked!

So that’s how I came to try replacing some Scala at work with Clojure

Iain: You have been involved in lots of open source projects over the years (We were just using one last week, deps-new, to create some templates). Of them all which did you enjoy the most? And are there any that deserve a special mention?

Sean: Currently, I think HoneySQL is my favorite since turning a data DSL into SQL harks back, in a way, to my days working on compilers and interpreters. It’s the project that has to field some of the more bizarre issues because SQL and DDL together have so many weird extensions for different databases.

Prior to Clojure, my favorite was a small, lightweight MVC framework I wrote for ColdFusion, which ended up being one of the top two MVC frameworks for that community for nearly a decade. I also wrote a companion DI/IoC framework which the MVC framework used by default.

Overall, I’ve been doing OSS since the early ’90s — and things have changed so much since then. I think it’s awesome that it is becoming more common for active project contributors to get sponsored by other developers and companies: a lot of collective work goes into building all the software that so many people use “for free”.

Over the years, I’ve tended to find that I work on OSS projects more when my job involves less coding from time to time — and I have to “scratch the coding itch”

Iain: What is your feeling on databases in general, and SQL in particular? Over the years there have been many different types that promised, or at least hinted, that they might take over from SQL. Mongo springs to mind, it was my favourite while I was learning Clojure, but it has fallen out of favour.

Sean: Although I was exposed to databases very early on in my career, I managed to avoid SQL for a very long time. One of my first jobs was at an insurance company doing assembler and COBOL and I worked on a team building a hierarchical database engine in assembler (they wanted an IBM mainframe-style database available on an 8100 mini-computer). I had a SAGE IV at home, with UCSD p-System, and built a database for my music, in Pascal.

Working with C++ later on, I was exposed to object databases (such as POET) but wasn’t until I’d been doing web development for several years that I wrote my first line of SQL and it was still a few more years before I wrote “complex” SQL queries!

We’re very heavily dependent on MySQL at work but we also spent quite a bit of time using MongoDB — and I maintained CongoMongo, a Clojure wrapper for the Java driver, for several years. Ultimately, we decided MySQL did a better job for most of our needs and, rather than maintain two large database clusters, we’d rather maintain just one very large MySQL cluster, so we migrated back off MongoDB.

I’m very excited about where XTDB 2.0 might go: bitemporal queries would be useful to us at work and it has a pretty complete SQL API as well as its Datalog API. I like that it is schemaless — that was what appealed to me about document stores like MongoDB.

These days, SQL is core to both my professional work and my OSS work so I’ve sort of learned to love it — after avoiding it for so many years!

Iain: Interviewing candidates for technical jobs is a tricky process. What are your views on this, and the problems with current approaches? More importantly, how can the current approaches be improved?

Sean: I’ve been a hiring manager for over twenty-five years and when I hear stories of the sort of interviews people go through in the tech world, I’m amazed… I’m horrified… I am not at all surprised companies end up hiring people who can’t do the job!

Look at how developers work: sure, we code, but it’s only a part of how we work — we communicate, we work in teams, we think about problems, we negotiate on solutions, we consider trade-offs, we imagine test scenarios and performance/scalability scenarios… and, yeah, we code too. And when we do all of that, we have time allocated, we have the Internet, we can do research and have our “hammock time” and we can bounce ideas off peers online (and colleagues at work, around the water cooler).

Then look at the typical interview process most companies inflict on candidates: it doesn’t look anything like how developers actually work! There are often “whiteboard coding” sessions, or “write code” on paper or on a computer, or full-on “tech trivia” quizzes — and it’s all under pressure and time constraints that are completely unrealistic.

We all know that people can “cram” for exams at school and pass, without actually being any good at their subjects — and there are books and courses on this subject and talk of LeetCode. It’s awful! It has zero to do with a developer’s actual ability to work in your team, solving your company’s problems.

So I don’t do any of that. I have a conversation with candidates guided by prompts in a mind map I created years ago: tell me about your favorite/least favorite project; tell me about some greenfield projects you’ve worked on and some maintenance projects; talk to me about how you keep your skills up-to-date; how did you end up working in Language X / Tech Stack Y, and what do you like/dislike about it? Open-ended questions that get candidates talking about their experience and what excites them (or depresses them) about software development!

We have to remember that candidates are people and they’ll be working with your people, collaborating and communicating, and solving problems together. The bare bones tech stuff: you can teach anyone that — you can grow and mentor anyone into a solid tech contributor, as long as they can communicate, work with people, and can solve (business) problems.

And I have never had to fire anyone for not being able to do their job technically in over 25 years.

Iain: Over the years Clojure has slowly increased in popularity but is still considered a “niche” language, despite there being few areas where (theoretically) it couldn’t equal or excel other languages. Do you have any thoughts on why this is so? What might it take for Clojure to become mainstream, and is that even possible/desirable?

Sean: I’ll tackle the last part of that first: I’m not sure it’s entirely desirable for Clojure to go mainstream — I think there’s a risk that we’d lose some of the friendly, patient, helpful, supportive nature of the community, and I think there might also be a lot of vocal pressure to add features / make changes to the core language, libraries, and toolchain that might be detrimental to both their simplicity and the ability of the core team to focus on their work while still engaging with the community.

I feel pretty confident in saying that it has never been a goal of Clojure to go mainstream: it very deliberately doesn’t pander to popularity or trends

As to why, I think there are a number of reasons:

• It’s a Lisp and, for whatever often visceral reasons, a lot of people think Lisps are just plain weird — OMG! The parentheses! https://corfield.org/articles/omg_parens.png
• It’s on the JVM and for a lot of folks that still screams “enterprise” and “bloat” and doesn’t fit with their view of lightweight, quick’n’dirty solution languages
• Being functional-first, with immutable data, is also a real stumbling block for a lot of people
• I think those are all “poor” reasons to not learn/use Clojure but a lot of people just can’t get past those things.

I think the data science folks within the Clojure community are doing an amazing job building out tooling that is increasingly “user-friendly” but whether they’ll make much of a dent in the Python/R/Julia world… I don’t know enough about it to have an opinion.

When I’m working on the React/Redux/Immutable JS app at work, I often wish it was written in ClojureScript (but that wasn’t realistic when we got started with it and a rewrite at this point would make no sense).

I’ve been on the JVM for most of my work for about 25 years at this point (which is sobering to see, written down!), and I did quite a bit of Lisp and FP at university, so none of those reasons above apply to me — I’m just glad I’m no longer writing Java/Groovy/Scala!

You can read the second part of this Clojure Corner with Sean Corfield here.