<div class="heading_h4" style="grid-column: span 2; margin:15px 0">Introduction</div>

Artem Barmin

Is it easy to manage a team of such highly qualified engineers? 

James Trunk

You're doing it to solve problems that people have and you're doing it with people, for people. 

Artem Barmin

Can you make a small and concise list of challenges that you were expecting when starting the positions? 

James Trunk

You're not going to like the answer to this. It's not that they're bad technologies. I just think there wasn't maybe the right trade-offs. 

Artem Barmin

How do you, as a VP of engineering, find these challenges of finding the talents, scaling the team? 

James Trunk

I'm not saying that's a free lunch. Nothing is a free lunch. I feel like we've been talking quite a lot about the challenges. Could we zoom in on some of the benefits? 
Once you've tried it, going back to another language that doesn't have it feels like programming with your arms tied behind your back. 

Vadym Kostiuk

Clojure gives such an opportunity to move fast, to provide a really stable solution.

<div class="heading_h4" style="grid-column: span 2; margin:15px 0">Full version</div>

Artem Barmin

Hello everyone, welcome to the fourth episode of our podcast, “Clojure in Product: Would you do it again?”

Vadym Kostiuk

And today we are excited to have James Trunk from Stockholm, Sweden, joining us. James is a co-creator of an open-source software architecture called Polylith. And he's also a frequent speaker at different Clojure conferences. 

Artem Barmin

And he's also the vice president of engineering at Griffin. That's a technical-driven bank that is the first full-stack banking-as-a-service platform in the UK. And it's offering innovative financial products for their clients. 

Vadym Kostiuk

And we also have a question from our previous guest, Marten Sytema, who is a CTO at Catermonkey. Martin asks, what would be a good way to create more Clojure jobs? And how would you approach about doing this? 

Artem Barmin

Let's begin. Let's map over the questions and macro-expand them in a true-life Clojure experience. 

James Trunk

Hi, it's wonderful to be here. Thank you for inviting me. 

Artem Barmin

Hi. 

Vadym Kostiuk

And for a start, James, I'd like to ask you a bit about your background, how you first encountered Clojure, and what actually is that that attracted you to the language? 

James Trunk

I started my career as a software developer. I originally did a career aptitude test when I was about 10 years old, where you fill in like a psychological profile and send it off to the government, and they process it with a computer, and they send back firemen, policemen, racing driver or whatever. And at 10, mine came back as a software engineer. So was a kind of destiny. I think I was going to end up doing that. I was a bit nerdy and a bit sporty, I guess, as a kid. We had mixed your both and still am a bit like that. 

I studied it at A-level and then at university, and just sort of fell in love with the magic of being able to have an idea and actually turn it into reality. I guess artists can do it, you know, when you create a world, or you do a painting, that there's something about building an actual system that works and the mixture of art and science and maths behind it that just appealed to my brain. So that's what got me into it. <br/><br/>

I got a job working at a small startup after university and then just sort of progressed through my career, I spent maybe 10 years as a full-on software developer in teams and then realized, I guess after about 10 years, that I was also interested in the people side. When you build software, of course, it's ones and zeros at the end of the day, but that's not why you're doing it. You're doing it to solve problems that people have and you're doing it with people, for people. So, people is such a big part of the software equation that I got more and more interested in that part.

And I guess in a way, because I'm an engineer and I have an engineer brain, maybe in the beginning, I saw people as interesting systems to try and understand. And I guess we are in a way that's kind of a reductionist way of looking at it. But this is a very long-winded way of answering your question. 

Okay. Clojure. Clojure I discovered, think around 2010, 2011, I was working at a company that I've been at for a while. We were using Java and Clojure of C ran on the JVM. So we could bring it in, and a colleague of mine there, he'd gotten excited about it. He showed it to me. I looked at the syntax and just threw up in my mouth and thought, no, I'm never going to get into this. You know, I hadn't done Lisp at university. I had no exposure to Lisp. And it just, I, my brain in the beginning just couldn't quite read the code. 

Obviously, it was a brand new syntax. So my initial reaction was, ooh, stay away, let me stick to my Java, but I was working on something, and we were pairing with this guy who was loving Clojure, and we were pair programming, doing test room development, and we coming up with what I thought was a pretty nifty Java solution for this thing we were solving. And then he said, oh, do you want to see the Clojure version of this? And it was so much shorter and simpler. And even though I didn't really understand the syntax, like that's what got me really interested. I was like, that's like 20 times less code than we've just written here. And I kind of really understand how that test works. And I liked how the date…

That sort of got me into it. And then I started learning it and we had a whole campaign to shift to Clojure within that company that almost worked, but didn't. That's a whole another story. And then as my career developed and I became sort of a leader of tech teams and a CTO, I actually could choose a greenfield technology. So when our CTO of a recruitment company, I said, let's do Clojure. We hired a small Clojure team. And that's where we invented Polylith, which I'm really proud of. 

And then, Griffin, where I currently work, they'd already picked Clojure before I joined the company. And that was part of the reason why I joined. It's a very long way of answering your question, but hopefully it gives people a flavor. 

Vadym Kostiuk

No, it's understandable, given your extensive experience in software programming. It's just impossible to have a really, really short version of it. So, thanks for such a detailed response. About Griffin, I have a question. I found this analogy about how you described Griffin as it's like an AWS for banking. So, can you please tell us more about the platform and how it actually earned this title? 

James Trunk

I don't know if we use that exact analogy anymore on the commercial side of things, but I find it a useful analogy, at least when I'm talking to people that understand technology, so developers, just because they're so aware of what AWS is and what that gives to you. 

So the basic idea is we're a bank, but we're not a retail bank. So we're not a bank on the high street. We're a bank that other fintechs build their what's called embedded finance products on top of in the same way that AWS is a compute platform. But obviously, it's not just for Amazon. It's for other companies and other startups to build their solutions on top of. 

And it's one of the things that's so exciting to me about Griffin because we're not a fintech as in here's an idea, here's a solution. It's going to solve this bit of the market. It's saying, here's a tool set. Here's a platform that we're building where we understand all of the complexity in the world of banking and finance and payments and onboarding and financial crime. And there's so much complexity there. But if you're a FinTech and you have a great idea that you want to solve people's problems, you're kind of blocked by having to understand all of that. And we say, don't worry. We've got this really good API. We document it really well. We're using this really clean technology. Come and work with us. Send us a few things via our API and you're off to the races.

So that's the idea that we were a foundational platform for other people to springboard or sort of launch their ideas from. So, in that way, it's similar to AWS. Does that make sense? 

Vadym Kostiuk

Yeah, yeah, definitely, definitely. And I'm wondering, so Griffin has been using Clojure like from the very beginning, from 2017. And I believe the decision is made by Alan Rochner, the CTO of the company, to start off with Clojure.

Have you had maybe a chance to talk with him about the reasons behind this choice? And more importantly, how did you feel stepping into a leadership role into the Clojure-based company? 

James Trunk

Two excellent questions. I've spoken to Alan a lot about that. We have weekly one-to-ones. Obviously, we don't always talk about the history of the company, but in the beginning, I was interested. 

So he and other co-founder, David, who's the CEO, they had worked together briefly, and they ended up writing a book together about ClojureScript called “Learning ClojureScript”. So they had already shown enough sort of commitment to a language that they've written a book about. Obviously, that shows us a love and a passion and an understanding, a very deep understanding of the value. 

And Alan had also previously built a company, CircleCI, also with Clojure, so he had another Clojure success story already under his belt, which obviously boosts your confidence that that's a good technology. It worked well once it can work well again. 

And I think also banking is almost uniquely perfect for Clojure in a way, just because of the underlying principles and values that Clojure builds on are very immutable in nature. And banking done well is immutable in nature. You know, ledgers are append-only in the traditional way of doing double-entry bookkeeping, et cetera. You don't erase things, you don't update in place. So, your traditional relational databases or mutable state programming languages have an impedance mismatch right from the sort of foundational level that Clojure doesn't have, which I think gives us a massive advantage. 

And if you look across the other side of the planet to Brazil, where Nubank, obviously, has gone very heavily all in on Clojure and are making a massive success. They're one of these success stories with basically the whole of South America and maybe world domination eventually, who knows, but they're doing incredibly well, presumably for similar reasons. 

I remember when I was CTO, and I picked Clojure. It did feel a bit risky in a way. It felt like I was putting my neck out because, you know, it's the classic adage that if you pick IBM, you don't get fired. And I was the first-time CTO, I'm picking this rare, well, not rare, but a little bit niche and especially at the time, back then, language. 

But it went so well for us. You know, we were such a small team, we achieved so much, we literally came up with a new way of thinking about backend architecture whilst also delivering all the business value that we needed to. It was almost the dream success story. So obviously, that builds your confidence that, well, it's not just in theory, this is a good idea. In practice, I've actually seen it work. Obviously, Alan saw it work at CircleCI.

So coming into a company where people already understood the value of it and I didn't need to do that sales pitch and sort of get people on the same page just felt like a breath of absolute fresh air because we could just start solving other problems straight away rather than me having to sort of align on values. We'd already aligned on values. We already understood what's important about software development. My goodness, it's the game changer, let me tell you. 

Artem Barmin

Thank you for the answer. That's really interesting for me. What exact challenges were you thinking about when you joined the team? I think this may be helpful to other new CTOs that joining the Clojure team or choosing the technical stack and hesitating to choose Clojure. So what were you thinking about? 

James Trunk

You mean what was I concerned about when I joined? 

Artem Barmin

Yes. 

James Trunk

Yeah, that's a good question. I guess if we're diving into the strengths and weaknesses of Clojure. Maybe that's one angle to talk about this from. One thing that made me a bit nervous when I turned up at Griffin was we had a custom build tool that our CTO, Alan, had built at in Clojure. I don't think the current build tools that we have, either in Clojure or more general build tools, are perfect. So I think there's room for improvement there. But what made me nervous was that it isn't our core business. Obviously, as I said before, we're trying to solve banking problems. And whenever you're investing significant engineering effort with a small team on something that isn't part of your core differentiator, that was maybe the most nervous I was about technology choices when I first joined. Our architecture was not Polylith and still isn't. And that made me a bit sad because I think Polylith is a really good architecture.

But there were other benefits to the architecture that Alan and the original lead engineer had chosen. I don't want to go into too much detail. If the people are really interested, I've done another talk that they can find on YouTube. I think it's called “Banking in Clojure,” where I talk about that one. And the basic idea is we have prox or processes, and it's a message or event-driven system. And those processes are essentially what they are just transducers, which obviously is this fundamental building block now in Clojure and a very nice abstraction for being agnostic about the source of the sequence of the events that you're processing. 

So, that way of thinking about processing events and having that as a core feature in the language was really exciting to me. And I thought, okay, this is interesting. Let's see how we go. Maybe we'll get into more detail later, but we had a number of sort of technology changes that happened along our journey that sort of started pushing us away from that, and maybe slightly more towards the Polylith sort of just calling functions approach. So, for example, let me not be vague. We started with Kafka as our message bus and we used atomic for state, and we had significant challenges with both in terms of performance and complexity, and observability. And yeah, it was, we…

It's not that they're bad technologies. I just think there was, it wasn't maybe, the right trade-offs. It turned out for the kind of system that we were building in hindsight. It's difficult to predict that in advance. And obviously, they're both solid technologies. But so what happened was, over time, we moved away from Kafka and away from Datomic. And now, we use FoundationDB, Apple's database is sort of the foundation that we build on top of. And we have this really cool query engine that is custom built that sits on top of that is based on data script. 

And that I like, even though that's like built in house, it's so core to what we're doing. And it's such a competitive advantage to have that kind of scalability and correctness in the database. You want that, you want it to be acid. You want to know that every transaction has gone through and is, you know, that's so important when you're a bank, but giving us the flexibility of the atomic light data log querying as well.

It just feels like the best of both worlds and maybe something that a lot of other companies don't have. So I love how things are currently looking there. And then on the Kafka side, we basically moved to a foundation as well for storing the events. And maybe there's, I'm looking forward to next year because I think Alan is going to do maybe another conch talk. He's doing one this year about testing and contract-based testing. He's got an even better idea coming up about durability and how you… how you manage data and how you can store when a function has been run or not in the database and you cause a durable Clojure. So keep your eyes peeled for that. That's going to be very exciting. 

Artem Barmin

Okay, of course. And going back to my question. So, can you make a small and concise list of challenges that you were expecting when starting the position? So, one you mentioned is a custom build tool that's, by the way, are you still using it? 

James Trunk

No, no, we ditched that. So we switched to Bazel Google's. It's called Blaze internally, but when they open-sourced it, they call it Bazel. 

Bazel is interesting because it's extremely powerful and extremely flexible. But whenever you have something that's extremely powerful and flexible, there's often a trade-off and the trade-off is complexity. And there is a lot of complexity to it. And we're also kind of cutting edge as in, I'm not sure how many companies are doing Bazel for Clojure builds.

Obviously there are other tools that are much more common within the community, but you do get some very nice features from it. Like, caching is amazing. You get that in Polylith as well, but it works in a totally different way. But so test caching, we as a bank testing is very, very important to us. You we need a lot of automated tests. We can maybe dive into it later, but we do a lot of different types of testing. But what you, some of those tests can be quite slow to run and you don't want to be running them all the time. And what Bazel does is, you know, dependency checking basically and noticing has code change that could cause that test to fail. If so, rerun it, if not, don't. And that means that our feedback loops with our CI system are way, way faster. 

But the complexity means there's only a small… it's growing as the knowledge spreads amongst the team, but there's only really a pretty small group of engineers that really feel intimately comfortable with the internals of Bazel. And you have to write this thing called rules Clojure that Alan wrote originally that…

Yeah, Alan is a genius. I'm not a genius. You know, if I was going in there trying to understand how all of that works, you know, it would take me, it would take me some time. So that's definitely a challenge. 

The other challenge. I don't know if I was worried about this at the start or if I've become more worried about it just because I've been there for three and a half years now, is spec. So we use spec. And there are a lot of benefits to using spec. And it feels nice in a sort of progressive typing way, the parts of the system where you need more comfort around what's the shape of the data that we're expecting in and out of this function. They enable us to do property-based testing with shrinking, which is an incredible tool for finding things that you wouldn't find with normal scenario-based testing or unit testing. We also use them for our contract-based testing, the API level, or interface to third-party systems. We use spec to define those interfaces. It's really good for that. 

But one of the challenges is when you start doing that kind of testing, the spec just kind of spreads everywhere in the system. And it starts to, I don't want to say it becomes like concrete, but it, you know, one of the advantages of Clojure is it's dynamic, and you can quickly experiment and you've got the REPL, and I'm sure we're going to the positives of Clojure soon, but there's just something about it. 

This is going to sound very vague and hand-wavy, but it doesn't give me that warm fuzzy feeling that it's exact right answer. It feels like we're still searching for how do we solve that? And the feeling Rich feels the same way. So obviously he's been working behind the scenes in his hammock on, I guess, spec-two or whatever comes out after. But it's just this feeling of, hmm, we're using something and no one feels quite happy with it. Does that make sense? 

Artem Barmin

Yeah. Yeah. Thank you. Can you connect this custom build tool to some deeper roots in Clojure culture or maybe least culture, least culture? So, doing some things on your own. So not taking the existing tools and just building on your own new fancy good stuff that really does the job. 

James Trunk

And I like that, right? Because that's something that appeals to me about the Lisp or Clojure community mindset.

It feels like it's a lot of people that are very good at what I like to call first principles thinking. I think a lot of people are drawn to Clojure because they're more mature developers that have seen a lot of the problems with other ways of thinking about building software and realize, wow, Rich has really thought about this from first principles. He's used a set of those principles to then come up with a solution and he can clearly explain where they're coming from and why. And then that has a massive knock on effect to what it feels like to use it as a tool.

So I love that it attracts that kind of people. It means that we do a lot of that first principles thinking, but like I think you're alluding to, it can also mean that sometimes we're tempted to solve the wrong problem or dive in and fix something. So if something's 90 or 80 to 90 % of what you need, just off the shelf or as a library or something, that my instinct would normally, as long as it's not core to the differential of your business, it's probably a good idea to use that. 

Obviously, there are costs to integrating other people's software. Even if it's just a library, there's a cost there of understanding, of the integration, of maintenance, et cetera. So I'm not saying that's a free lunch. Nothing is a free lunch. But there's a heavy load that comes with deciding to take on that yourself and maybe heavier than engineers think. Because engineers think this is fun to do and we get to solve this and we can solve it in the best possible way. And that's true. But then you've got to maintain that forever. And there's a cost to that. 

So yeah, if I'm understanding your question correctly, I have seen that in the community. It's generally a good thing because it means we come up with some fantastic ideas. You know, when I look around, it just feels like there's innovation happening, new ideas, new ways of thinking about things, and the power of Clojure as a tool for doing that with macros and other parts of it seems almost unmatched to me. So you get this fantastic energy and momentum.

But you do need to be a little bit careful about the inner business. 

Vadym Kostiuk

Yeah, that's interesting. Moving to the present time, I just want to ask you a bit more about your current position. So, can you please tell what is your actual role and what are your responsibilities as a vice president of engineering and Griffin? The most interesting part is how are you personally involved in the coding process? 

James Trunk

You're not going to like the answer to this because the answer is very little. We've got Alan, who's the CTO. As I already mentioned, Alan is a genius and his strengths, I hope he doesn't mind me sharing this with everybody, but he's extremely good at the sort of high-level strategic thinking. You know, he really understands the business at a level that's quite phenomenal and impressive. You know, what he knows about banking and he's just like a sponge for that. And you can just process it in a way that I wish my brain works that well. And then he's, writes code, you know, he wrote our bill tool. He's been driving the work on this layer for doing queries. He's working on durable Clojure. You know, he's really our innovator-in-chief. So he's that kind of CTO that he's up here and down here, like at the top level. 

And my role fits in between there to sort of fill the gap. So we are sort of a joint leadership, if you like, a two headed beast that leads our engineering team. So what, where I fill in the gap is around people and process mainly.

So the people part is recruitment. Obviously, we've been growing. So we've gone from a single team of 6 or 7 engineers, I think when I joined three and a half years ago, and now we're well over 40 engineers, obviously spread over many teams. So recruitment takes a lot of my time. But then the other part of the people role is creating an environment where people want to be. And you don't just want to hire people; you want to look after the people, or we do, that you've hired by creating an environment where people feel safe, where they feel like they can challenge each other, where they feel like they get feedback, where they can grow, where they can try new things. So a big part of my role is that part of it. 

And then the process part, I think it goes back to being an engineer originally. I'm interested still in systems and processes, and my brain just kind of works that way. So how we work, how do we do product discovery? How do we involve the different parts of the business so that we're solving the right problems in the right order? How do we enable the level of quality at each step so that everybody's feeling good about how we're working and what we're delivering? How do we make sure that we're delivering the value to our customers that we should be and not just having fun solving fun engineering problems? So, I've spent a lot of time figuring that out. 

In previous companies, when I haven't had an Alan, and I was the CTO, obviously, I did his role as well. And I was doing a bit more coding and a bit more, maybe, on the strategy, but it's actually really nice because, yeah, when you can trust someone and when Allen just has brilliant ideas, and he's very good at changing his mind when he's presented with new information, and I tried to do that too. So it just feels like we had this really nice relationship, and how we work together works very, very smoothly. So it's not that I don't miss the technology side. I do sometimes and I do do pairing with a couple of developers just to, you know, not completely lose touch. But I don't write production code, I just don't have time in my calendar to do it. 

Artem Barmin

You know, if we talk about Clojure market of developers, I think it's rather niche. And how do you, as a VP of engineering, find these challenges of finding the talents, scaling the team? I can imagine that at some point you need to scale team very fast and you need to hire a lot of skilled people. 

Do you find this challenging actually or not? 

James Trunk

I would say yes and no. So, the advantage of fishing in a smaller pond, excuse the bad metaphor, but in a smaller pond with bigger fish, I would say, it's easier to catch the bigger fish, right? There's less competition, and people just understand you're more likely to be connected on values, which is particularly important for us, Griffin, not just the sort of technology engineering excellence values, but we have other softer people values around transparency and kindness and how we like to interact with each other. 

So it feels like a really good match in that way, just like the technology we chose matches our philosophy. So it's like a self-perpetuating circle. But the downside is it is smaller. There are fewer people and sometimes, you know, we don't just hire people that have previous professional Clojure experience.

It will be normal right now, at least when normally looking for people with functional programming experience, at least. So that, you know, if they have a Haskell background, or an Elixir or Erlang or OCaml, or even Scala, it's less of a risk that they won't be able to make the paradigm leap that you know, they've already kind of understood why we do in Clojure, what's the point of separating data and functions, do you understand what I mean? 

So that broadens the pool that we're fishing in, but it does increase the risk of onboarding because, you know, if they have a Haskell background, join us, they're all excited. And then they all go miss types. Specs good, but it's not exactly the same as the, know, the mathematically pure types that they're used to. 

Obviously, that's a risk, but so far, it hasn't really been a problem. All of the Haskell people that we've hired have ended up loving working with Clojure and haven't missed Haskell as much as they thought they would. So, so far, it's been working.

Vadym Kostiuk

It's actually matching what we already heard from previous guests. So Adam Tornhill and Martin Sytema from Catermonkey they mentioned that it's, it's not difficult, and it is difficult at the same time to find Clojure engineers. But in their experience, I believe Martin even said that it's a kind of natural filter, where you’re having a few applicants, it results in having higher relevance. 

James Trunk

Absolutely. Definitely. Yeah. That's the smaller pond points I was talking about before and bigger fish. It didn't clearly explain what I meant, but that's exactly what I meant that if you put out a Java or a JavaScript ad, you'll get a lot more applicants, but the quality of them will be harder to judge, I think. There'll be more of them. There'll be more chaff instead of wheat, and the signal-to-noise ratio will be very different than when you say we want functional programming engineers, preferably with Clojure experience. If you have, you're going to connect with them much more likely and they're likely to have thought more about software development as a practice, as an art form, as a type of engineering. Whereas somebody that's just gone the standard route ended up with a language without really thinking about why they use it more difficult. 

Artem Barmin

And why do you think Clojure attracts so many qualified engineers? Is it something natural to functional programming, or it's just, you know, lack of tooling, tutorial support, or anything else, and a person needs to be really motivated to get into the Clojure? So is it natural or it's just kind of artificial complexity? 

James Trunk

That's a really good question and you've kind of loaded it one way. I will try and answer it just the first way that came to mind. And then I'll try and answer it in the way that you kind of loaded it towards, I think. 

One of the things that pulled me in, I mean, I gave you the anecdotes of where he showed me code, but then I started watching Rich's talks, you know, the classic one that everyone discovers first is “Simple Made Easy.” And I think when you connect with people on the why, you start with the why. You can convince many people, you bring them over to the cause because they recognize the problems that you're saying, hang on a minute, this way that we're currently doing, it doesn't seem very smart because of X, Y, and Z. Shouldn't we think about this from another way? And that's what brought me over. I know that other people that joined the community have similar reasoning. So it's often you're a more mature software engineer that hits a load of problems with different projects that you've worked on. 

If you're fresh out of university, you still think everything's perfectly solvable with object-orientism. You won't have seen the problems that cause you to have an aha moment when you're watching “Simple Made Easy” at the same level of intensity, maybe. 

So I think that's part of it. And I just think Clojure is a beautifully designed tool because of how Rich made it. That if you appreciate the tooling, there was this great talk. I think it was at Clonj many years ago. I can't remember who gave it. I wish I could, but it was about woodworking and how using a good tool is about, you know, picking the good tools.

It feels like that with Clojure, that it's this really sharp tool that enables you to create sharper solutions. But you need to be able to recognize that. You know, if you're a novice, you probably can't tell the difference between the perfectly folded Japanese blade versus, you know, a knife from Ikea. It's a combination of things, but being more experienced, I think, helps with all of them. 

And then to the loaded part of your question, there are some blockers still to getting started. I think the story is much better now than it was when I started looking at Clojure in 2011, but it's still, you know, the classic thing that people complain about error messages, test results, and spec tries to help, but doesn't quite nail it. And yeah, Java stack traces because, you know, it's built on top of the JVM. So you also have to understand something about the JVM and about Java and memory management. There's a lot of complexity that you, again, takes quite a bit of engineering know-how and knowledge. 

So, in a way, I almost had the perfect route, you know, as a kind of jaded Java developer who's familiar with the JVM that, like, that's a natural on-ramp to Clojure. Whereas if you come from some other technology, Python or something, that whole part of it is probably quite daunting and off-putting. So are there things that Clojure could do to be even more attractive to a wider audience? Yes, I think the answer is yes.

Artem Barmin

Actually, I also started my journey with Clojure with 2011. I also had, you know, previous Java experience. That's why stack traces are not scaring me. 

James Trunk

There you go. 

Artem Barmin

Yeah. I remember all these huge, huge stack traces with a lot of functions that are not really understandable. Yeah. Yeah, that's true. It was a rather complex thing to manage everything to work, but having experience with Java, with Linux, with everything else, with the Gen 2 Linux, where I needed to build everything by myself, make onboarding and Clojure easier. But I heard stories from JavaScript guys that it's unimaginably complex for them to get into Clojure. We even tried to conduct an experiment, time to Hello World, for JavaScript guys, and they didn't manage it in one hour.

James Trunk

Even with tools like Calva and others, because Calva has a really nice get-in-started REPL. You literally just install the plugin in VS Code, and you should be able to get going if you're a developer, regardless of language. 

Artem Barmin

It should be easy, but for some reason they didn't manage it. 

James Trunk

Okay, that's interesting. 

Artem Barmin

Is it easy to manage a team of such highly qualified engineers? Probably a lot of them have a lot of ideas on how to make things more perfect. And it's really interesting to hear about the culture of architectural decisions. How do you choose libraries? How do you bring new approaches into the system? How actually you manage these conversations? 

James Trunk

Coming with a lot of excellent questions today. I'm really enjoying this. 

Artem Barmin

Thank you. 

James Trunk

I think that could be a challenge. I think our culture is again a good fit for that. So let me explain how we do decision-making. I actually wrote a blog post about this that people are interested to read more, but we do something that I termed democratic decision-making, where we try and use the power of everybody's experience to make effective and efficient decisions, but by collecting ideas from everywhere and trying to get to the best idea we can as a collective, know, as a cooperative.

So we have a whole process for that. I won't go into the whole thing because it's quite a lot, but basically, we do a lot about writing. We write RFCs. We follow Rich's advice that he gave in an excellent talk about design where we use decision matrices very heavily to sort of guide the terminology we're using. So we're on the same page about what are the trade-offs. So, good engineering is always about trade-offs. So we really try to think about trade-offs and we try and be on the same page about what's the… What's the relative value of these different trade-offs for this particular solution? So language is really important to us. I think it's important to Rich as well. Again, it's a cultural thing. 

So we have remote first, Griffin is, so we have engineers spread all over the place. So we have an asynchronous process using motion where we write a request for comments about here's the thing that I would like to change or here's a library, like, and here's why, here are the, here's the decision matrix, the different criteria that we care about. Here's how the different options score. One of the options should always be status quo, where we are today. And then here are the different options so we can make a good choice. Then we anonymously vote on it, which means that when Alan and I cast our votes, nobody knows what we voted for. We didn't start with an anonymity. And what happened was if Alan voted for X, it was quite difficult for people to vote for Y. Do you understand why? Because obviously, he's the CTO, he's very smart, and people are nervous about standing up. But if it's anonymous, that goes out the window and it's just people put what they think. 

And then if we're not in agreement, if we don't come to what we call rough consensus, we have a decision meeting where we meet, we hash it out, we figure out the blockers, we've stolen some ideas from the IETF and how they get lots of smart people in a room and come to good conclusions.

So we kind of borrowed ideas, did a bit of first principles thinking, and came up with this technique for making decisions. I think it works really well. And I think it makes us pretty good at letting the best idea bubble to the top rather than my idea, Alan's idea, or some lead engineer's idea. 

Artem Barmin

Cool, cool. Very interesting. Never heard about such a decision-making process with anonymity. 

James Trunk

Read the blog post. It's a good one. 

Artem Barmin

Yeah, yeah, of course. Definitely. And you know, still having such a good process, you mentioned several inefficiencies in a company, like managing your own build system. Can you maybe name something else that's bubble up, but it turns out to be over-engineering, and you need to somehow manage this afterward. 

James Trunk

I mean, the first thing that comes to mind is this sort of made this distributed systems choice, or I wasn't there when it was based on a book. It leads to a lot of outcomes that maybe you couldn't see in advance about the behavior of the system and how it feels to develop it. Now, I don't want to preempt with, we've built what I think is a very strong system, even given those sorts of restrictions that being event based like that. And having a message for us and having processes that pass back and forth to each other. 

It's just that all of that adds a level of complexity and sort of impedance over and above the inherent complexity that's in banking, that's in the domain that we're trying to solve. One of the things that I love about Clojure is, generally, it just gets out of your way and shows you, okay, here's data, here are the functions that work on that data, here's a pipeline, and just now that's the only way my brain can kind of see systems. It's just like natural that that's how it works. It's like the pipeline with data and functions.

And any other tools that we build on top of that, you need to be very nervous about because there's a risk that you're making fancy engineering for yourself that doesn't actually help you solve the problem better. So I'm thinking about things like types or objects or patterns or architectural layers or the mainstream. You can keep building tools on top of data and functions.

And I think a lot of those tools are actually a mistake and it's engineers just getting carried away with complexity because it's fun to understand complexity and work with complexity. And I think we should be working with simplicity. I can't predict the future, but if durable Clojure turns out to be the right avenue for us, I think that's going to make our system fundamentally simpler to understand. So you could, going back to your question, you could argue then, that our whole distributed systems, event-driven approach was a mistake.

But we learned a lot and maybe we wouldn't have got to this point of understanding without doing that journey. So I'm not sure I would regret it. And we have a very solid, nice system, but I think it's going to be even better in the future. Does that make sense? 

Artem Barmin

Yeah, definitely. That question actually arrived from our experience of doing consulting job for Clojure. And we often see over-engineered systems. And that's usually connected to a not very big experience of engineers that started the system. So they moved from Java to Clojure. Clojure gives a lot of features, macros, lot of power. 

James Trunk

You can get drunk on that power very, very quickly. I've seen that too. Yeah, Clojure doesn't solve programming, right? It doesn't mean that any developer can just come in and write the perfect system every time. No, not at all. You can write spaghetti code. It's difficult to understand in Clojure. And because it's dynamic, if you're not good with naming, if you don't care about language, if you're not good at consistency, you can really, you can make a mess for sure. So it almost puts a certain barrier to entry that you need to be at least this good as a developer to do well with it almost. Which is both a strength and a weakness, I guess. So yeah, I've seen similar. 

Artem Barmin

I would add if you like to write domain specific languages using macros. That also makes simple, very complex systems. By the way, are you using macros in your... 

James Trunk

We do. We try not to go crazy with them for the reason that you're implying that, yeah, if there's a lot of power in the core tool, you often don't need a DSL on top of that.

But there are places when they give you a power that other languages don't give you and you'll be kind of stuck without it. So when you need them, they're wonderful. But you've just got to be balanced about when you use them so that you're not creating another language on top of Clojure because that makes onboarding more difficult and potentially gives you more to maintain all the things we were talking about before. 

I feel like we've been talking quite a lot about the challenges. Could we zoom in on some of the benefits? Because there's a lot I love about Clojure and I feel like I've mainly been talking about the problems. 

Artem Barmin

Benefits, my point of view, are a mirror of challenges. So they are kind of connected. That's why we try to dig deeper into the challenges, all the fears that have technical guys when choosing the Clojure stack. 

James Trunk

I'm not upset with the question you've asked. I just feel like maybe we should be balanced and fair.

Vadym Kostiuk

What kind of benefits Clojure brings not only to the technical side but also to the business side? Because quite a few times, we have heard that Clojure actually gave an opportunity to be more competitive on the market for the businesses. For instance, when a small team like 10 or, I don't know, sometimes 50 people, but only a few engineers have to compete with larger organizations in terms of win the market. 

And they say that actually Clojure gives such an opportunity to move fast, to provide a really stable solution. It's actually shortened the time to market period. 

James Trunk

Yes. 

Vadym Kostiuk

Yeah. So can you maybe share your perspective and your vision? Maybe Clojure somehow gave you an advantage at Griffin that you can speak of. 

James Trunk

Yeah, it's difficult to speak in counterfactuals of what would it have been like if we had another technology with a similar number of engineers of a similar caliber because, obviously, I don't know that timeline. So what I'm going to say is going to be heavily biased to recency bias, to confirmation bias of what I believe about. 

So, just to preempt my answer with that, to answer your question, I do think it's given us a competitive advantage. We've built a banking-as-a-service platform from scratch with a very small team in a very short space of time. And I'm incredibly proud of that. And I think the technology, you know how I talked about in the beginning about it being a match to the underlying domain. That's had a massive impact on it. I think there are other, if we go into the benefit, I can go into other reasons why I think it's helped the brief, the short answer to your question is I'm not sure we could have picked another technology that would gotten us to this stage with this quality and this level of confidence, except Clojure. 

Artem Barmin

Can you say some numbers, maybe? A number of team members, how long does it take to get first production version and to start selling? 

James Trunk

I shouldn't talk too much about what things were like before I joined, because, obviously, I don't know that, but I've been there for three and a half years. And in that time, we've gone from, I would say, the bare bones of the prop system with no real banking functionality, no ability to make payments, no ability to onboard customers, no proper interface to having a fully fledged bank that millions of pounds flow through. 

So, and we also got our banking license during those three and a half years, which is a massive process and endeavor in and of itself that sort of happens alongside. And obviously, engineering was involved, but we weren't driving that. That was other parts of the business.

Let me dive into the benefits a little bit. So, the first benefit that comes to my mind when you're building a system is the sort of interactive development that you get with Lisp and with Clojure obviously as a Lisp, but the REPL-driven development. It's one of those things that once you've tried it, going back to another language that doesn't have it feels like programming with your arms tied behind your back. And until you've experienced it and what it means to be running your entire system, you know, even at a banking scale in your local REPL and being able to change any piece of data and any function to try something else. 

The analogy that I think of is it, you know, a sculptor that works with clay. To me, having a REPL and being able to do that with your code feels like just getting in and molding the clay, just feeling it as you're working with it. Whereas a test-driven approach like you have in a compiled language where the only way to interact with your code is by writing a test that you can compile and build and deploy and run. And it just, the feedback loop doesn't feel like molding the clay. It feels like sort of prodding the clay from behind a glass window with a stick. And you can still do something with the clay, but it's not the same immediacy. So, for me, that's huge. 

Everything else about Clojure could be completely different than it is. If it just had that, it would be a huge selling point that you should almost drop everything else and just... And the fact that it has immutable data and all of these other brilliant things, a great testing story, it's like icing on the cake. But do you understand why record-driven development is just so game-changing? 

Artem Barmin

I think it's a good place to mention your manifesto that you've talked about on one of the talks. Did you enforce this manifesto inside the company? 

James Trunk

No, no, not really. And it was kind of...

I did ask for feedback on it and people didn't sort of disagree with anything. But that's not a manifesto that we have up on the wall or anything. It was just something to share a little bit how we think, how I was thinking about some of the values that Clojure has. 

And part of that was how it separates data as a sort of segue, how it separates data and functions. And I touched on this a little bit earlier, but it's worth revisiting again that the importance of that and the way that combined with the REPL-driven development, it just gives you the right level of abstraction, I would say, to solve real-world problems pragmatically. You're not worrying about patterns. You're not worrying about ORMs. You're not worrying. You know, all of those other things we talked about before, they just kind of vanish, and you just see that you, like in the matrix, you just see the world behind the code kind of thing. That's what it feels like to me. 

And obviously other, there are other languages that add the data and functions, you know, a lot of functional languages are quite good at that. Some better than others, you know, obviously, languages like Scal,a where they try and be everything in the kitchen scene, can let you do all different kinds of approaches. They're much less opinionated and it's much easier to get into really bad situations with languages like that. But there are other languages where they're really good with separating those, but they don't have that REPL story. So even there where they're really strong on the functional, they don't have the list REPL story. Yeah.

That's a big part of why I think it's so powerful. And I talked about transducers. It may be that we slightly move away from those, but transducers are an incredibly powerful processing abstraction that our architecture wouldn't work without it. I talked about going through these different technologies from the Atomic and Kafka. 

The reason that works is because our prox are agnostic to what the technology is. They just want to sequence. And they're going to process each element in the sequence in turn with this, you know, with a rule, basically a function. And so we could rip out Kafka and put in Foundation DB and the props didn't even know that anything had happened. That's, that's useful. That's amazing. Like that enabled us to be quick. Imagine if you had spaghetti there where everything was knowing about things that were deep in the technology stack. As soon as you try and do open heart surgery like that, you're in real trouble, and it's going to take you forever. That didn't take us forever.

We had brilliant engineers doing it, and there was still, you know, I don't want to say it was trivial because it wasn't, but it was doable, and it was doable quickly. That's, that's game-changing. 

And then I talked about testing. So, we do a lot of property-based testing. It is a great feature with spec, that you can generate randomly shaped data that fits a certain spec. And we do other kinds of testing that also are helped, you know, pure functions are easier to do unit testing on because you don't need to mock things because you pass in the context by the arguments. The testing is a very, very nice story in in Clojure. We do contract-based testing. Alan's doing a talk on the Clonj. Everyone should go and watch that because it's brilliant. It's a very good idea.

Spec enables it, Clojure enables it, difficult to do in other languages. We do chaos testing of our infrastructure. That's not so Clojure-specific, but still, it's not hurt by having a powerful tool like Clojure to help us set that up and set that down. 

Testing gives you confidence. Confidence gives you speed. You know, coming back to the whole, can we be faster? For me, having this huge suite of tests that we run.

And we run when we need to because of the catching and Bazel that I talked about before, just means that developers can move quickly and feel comfortable and confident. There's nothing worse than working on a code base, especially in a bank, right? Where real money is flowing through, and you're making a commit, and you're thinking, I don't know if this is going to break anything. That's a horrible feeling that you don't want to give your developers day in and day out. Whereas with Clojure, with the way we've approached it, we don't often have that feeling.

Artem Barmin

That's interesting. I noticed I had experience with different languages for the past 10 years. Clojure, JavaScript, TypeScript, and Clojure somehow encouraged me to write tests and manage test cases database. And I was thinking right now maybe it's somehow connected to benefits of Clojure because it's really easy to write data-driven tests, to describe some infrastructure of a test in data just as a domain-specific language. When I talk about benefits, I really like stories. And I know that you also use storytelling as a part of speech on the conferences. And my most favorite story is about REPL when guys debugging a satellite near Jupiter and was able to fix some bug. Maybe you have some stories from your bank, a really big organization when a Clojure saved the day. 

James Trunk

The first one that comes to mind, I did share basically the same anecdote in one of my other talks that I've done, but it is a good example. And it goes back to the property-based testing. So you've probably heard this one before, but maybe other people who haven't watched that talk haven't heard it. So, it could still be interesting, but the basic thing that happened was there was an XML spec for a particular payment trail that we were doing. 

So we had an integration with a clearing bank, I think it was in this case, and you would send them an XML file, and it would transfer the money basically. And we had a generative or a property-based test that figured out that it was possible to send an amount that was larger than the spec allowed, which would break the spec because it was just trying all random numbers, and it just happened to randomly try an incredibly big one that you probably wouldn't think of as a developer to try, and it broke, and then it shrank the test cases down to literally exactly the number that broke which when you look in the spec you're ah! because it's that size of a number, that's why it breaks up exactly, and it was just so easy then to figure it out and fix it that, I mean, a quick check actually comes from Haskell, so that's it's sort of a borrowed good idea and shrinking comes from QuickCheck. But it's something that if we didn't have the power of a library like that, we wouldn't have found that bug as quickly. And who knows, maybe we would have found it when the company is already a unicorn and we're transferring trillions of pounds around, right? And then it's like, that fails. But we won't make that mistake now if we do get to that point. So that's exciting. 

Artem Barmin

Maybe you have used the REPL connection to debug some problems that occur only in a production environment or staging environment? 

James Trunk

We try not to do that for regulatory reasons. Obviously, a REPL is incredibly powerful and with a running system, you can literally do anything. So we have a lot of for-rise security checks that if you're doing anything in production, you can't be doing it by yourself. But we try to only do that kind of REPL-based fixes in staging or other environments, not in production because we're a live bank with real money. 

Artem Barmin

Yeah, of course. But for staging, that's deployed on some servers... 

James Trunk

Yeah, and we make that look as much like production as possible, and then we can do that, and then you can go hog wild, and you can do whatever, and you can completely change functions live as you're working in the running code. You can rerun payments and see what happens if you change this or that shape of it. So obviously, that's where it comes in extremely useful. 

Artem Barmin

Yeah, I agree. I like these live environments. 

James Trunk

Yeah, it's addictive. It's really addictive. 

Artem Barmin

Would you take Clojure as the main technical stack for your product right now in 2024?

James Trunk

If I'm building the same company, so building a banking-as-a-service platform, knowing what we know now, would we make the same choice with Clojure? Yes, 100%. Yes, no question in my mind. 

Vadym Kostiuk

What advice maybe can you offer to a tech leader like yourself stepping into a Clojure engineering team, especially regarding leadership, and navigating through the Clojure ecosystem?

James Trunk

Maybe a bit like we spoke about before, there's often a certain level of maturity and understanding with the engineers. So, giving them space to feel like they have autonomy, they can suggest ideas, those ideas are listened to. I think the quickest way to break the Clojure team or any team of good engineers, regardless of what technology they're using, is to take that autonomy away from them.

That can sometimes be difficult even for us. You know, we have a highly autonomous, you know, I talked about our democratic decision-making process, but things like business strategy, the knowledge tends to live elsewhere in the organization. You know, it's the customer success team. It's the commercial team that are talking to potential clients and understanding well, what features is the market screaming for now, which then should guide a roadmap if you like. And then it's figuring out how do you get engineers involved in that early enough so that we don't end up picking something that although it makes sense from a business perspective, doesn't make sense from an engineering perspective. 

And we have a whole, I won't go into it, but we have a whole process about how we score, we basically score the different opportunities, and we care about costs, and we care about risk, and we care about the  opportunity in the market, and we care about customer experience. And all of that helps us, even though the numbers might not be their predictions and they can be a big guesswork, they create a bit like the decision matrix does.

They create an opportunity for understanding, alignment, disagreement. And why, why is that such a high, I didn't, do you see what I mean? Just by airing that and having it visible, it creates an opportunity to let people get involved and feel like they can make an impact. So I'm giving you really long answers here today, but I think this the short answer is give them a lot of space because they're probably very good. Trust them.

And of course, even strong engineers can get bad habits or they can want to solve problems that they so it's not like you should just leave them be. You need to be involved. You need to understand right at the low level of detail. The way Alan frames it is you need to be up here, but you also have need to have your feet touching the grass. And I really believe that's true. And it's something we have engineering managers that I manage that lead each team and I really want them to be involved in both the technical and the product details. It's a difficult role because you're kind of struggling both worlds. But if you don't understand both, you can't be trusted by the team to make, help them to make good decisions. 

Have your feet touching the grass, get involved in the details, and give people space to let their good ideas shine. 

Vadym Kostiuk

That's a good, that's a good advice. Thank you very much. Thank you very much, James. As we told you before, we have this special part of the interview the chain of questions between the speakers. So we have a question to you. Marten Sytema, he is a co-founder and chief technology officer at Catermonkey. He left your question and it is, what would be a good way to create more Clojure jobs? And how would you go about doing this? 

James Trunk

Create more Clojure jobs. Well, we're trying to do it by building a successful business that runs on a 100% Clojure stack, right? So we, our front-end is ClojureScript, our back-end is Clojure, parts of our building infrastructure written in Clojure. So by making successful businesses that grow, I mean, we've got 40+ engineers at this stage and if we continue to grow, obviously that creates more jobs. 

I think that's the only answer really. It's just identify needs where Clojure is a good fit for solving that problem, like banking, like finance. But it's not just banking and finance. It's a good fit for, there are a lot of other fields. I mean, I used it before in recruitment. You know, that was a lot about psychometric testing and it was completely different. And we did database migrations and we used the power of data script or it was Datomic and Datalog back then, but to really make what would have been almost impossible in any other technology that I've used before, not easy, but, again, doable, a bit like with the transducers. 

So spot those kinds of problems, find like-minded people and start a business. And then if you do well, you're going to create more jobs. 

Vadym Kostiuk

That's a nice response. Thank you very much.

Artem Barmin

Thank you. And you can ask question to the next guest. 

James Trunk

Yes. So I wanted to ask about their approach to defining the shape of the data in their system, how they do that, how they're finding it with the current set of tools, maybe describing a bit of the challenges and advantages to their approach. Like I said, so just to give a bit more context, we're using spec for that, but it doesn't feel quite right. I know a lot of companies use Mali and it is well liked within the community. So if they use Mali, that would be super interesting. How do they use it? Schema is an older technology that I know a lot of people like. Or are they doing something else entirely? Are they nervous that Rich is going to come out of his hammock and deliver this wholly, you know, aha-moment and they're doing something completely different that they need to change. I think that's the feeling I have. 

So yeah, that would be my question. How do they specify the shape of their data? 

Artem Barmin

Cool. 

James Trunk

And how deep in their system do they go? Because for us, we've gone pretty deep. But I know some companies just keep that specification at the edges of the system. And then they try and leave the innards more dynamic to have some of the other sort of fluidity, you know, play with the molding the clay kind of benefits. 

So yeah. Long question, like my long answers, apologies. 

Artem Barmin

Thank you, James. It was pleasure to talk with you and to hear your insights and to hear that you liked our questions. That also was pleasure. 

James Trunk

They were excellent questions. If it was a good chat and people got value, most of the thanks has to go to you and your good questions. So thank you. 

Artem Barmin

Yeah. Thanks. 

Vadym Kostiuk

Thank you, James. And additionally, I wanted to say to our audience, if you're curious to learn more about Griffin, we'll include links to their website in description below this video. So yeah, be sure to check them out. 

James Trunk

Thank you. Yeah, we're hiring and it's an awesome place to work. So come and work with us. Thanks for the plug. I forgot to do that. 

Artem Barmin

And not only about Griffin, you can share any link that you want to share with the community. And thank you once again, James, and looking forward to catch with you on Heart of Clojure. 

James Trunk

I'm looking forward to that too. Thank you, gentlemen. 

Vadym Kostiuk

Thank you. Thank you. Bye. 

Artem Barmin

Bye bye.