<div class="heading_h4" style="grid-column: span 2; margin:15px 0">Introduction</div>
Jereme Corrado
Clojure popped up on my radar. And I thought, this is pretty cool. And I explained Clojure and she's like, what's that? We make robots and we use Clojure and we build developer tools.
Artem Barmin
You need to spend a lot of time learning Lisp, setting up the infrastructure, learning new concepts.
Jereme Corrado
We all just want to build something we're proud of.
Artem Barmin
If people already did this, that's a good sign.
Jereme Corrado
This is going to help us find the right engineers to build the right product. When you're trying to build a team, Clojure is a painful filter. Clojure? Really? What's that? Why? Why not just build it in JavaScript?
Artem Barmin
How it actually works if you choose Clojure in a startup.
Jereme Corrado
So the reality of leading an engineering team is you're going to have to make a bunch of ugly decisions at times of which corner to cut.
Artem Barmin
If everything is great, for me it looks like not the full picture of a technology, of anything actually.<br/><br/>Clojure really shines with data-oriented programming and data manipulation because it's kind of native.
Jereme Corrado
Should we hang up the ClojureScript-based frontend and just move to, you know, know, TypeScript and more, more widely embraced solutions.<br/><br/>Is Clojure dead?
<div class="heading_h4" style="grid-column: span 2; margin:15px 0">Full Text</div>
Artem Barmin
Hey guys, welcome to the eighth episode of our podcast, “Clojure in Product: Would You Do It Again?”
Vadym Kostiuk
And today we’re excited to talk with Jereme Corrado, former CTO at Mobot. Mobot is a cutting-edge QA-as-a-service platform that utilizes real robots to automate mobile device testing.
Artem Barmin
Jereme, a Clojure enthusiast since 2016, has driven transformative projects at Mobot, from developing core data models to scaling the team.
Vadym Kostiuk
Plus, we have a question passed from our previous guest, Nathan Marz. He is a founder and CEO at Red Planet Labs, and his question is, “What is the last time you spent all night working on a Clojure project?”
Artem Barmin
So let’s begin, map over questions and macro-expand them into the real-life Clojure experience.
Vadym Kostiuk
Hello, Jeremy, and welcome. Thanks for joining us on our eighth episode of “Clojure in Product: Would You Do It Again?”
Vadym Kostiuk
To kick off our conversation, Jeremy, you had a really long career in engineering starting from 1997 and have previously held roles such as CTO at Mobot and VP of technical operation at Birchbox. So could you please share your journey and how you first encountered Clojure and what is it that actually attracted you to the language? It would be really nice.
Jereme Corrado
Sure, yeah, absolutely. Okay, I'll start from the beginning, but I'll sort of accelerate to the interesting parts. So as you mentioned, I started working in the mid to late 90s. I was in college at the time, was a philosophy major, do not have a philosophy degree, dropped out, kind of fell in with a guy with like a one-man computer fix-it biz out of his apartment. It was interesting, but I wasn't super passionate about it.<br/><br/>Shortly thereafter, I discovered Linux and free software. I was a Debian package maintainer for a little while, and I just really fell in love with it. Over time, taught myself to program. My first programming language, what was C, but the first one that ever paid any bills was Perl. That was long ago in the mod Perl two web days. <br/><br/>And right off the bat, everybody has to pick an editor. I picked Emacs. And that was really my introduction to Lisp and still a daily Emacs user. Absolutely love it. But I think that's what planted the seeds for me. And as my career progressed and as I spent more and more time programming, I just was always attracted to Lisp and Lisp dialects. Played with Scheme and Racket a bit, Common Lisp, some Emacs Lisp, a little bit here and there.<br/><br/>Let's see. I think it was toward the end of my time at Birchbox. I was at Birchbox for eight years. It was a pretty long time. Towards the end of my time there, I was kind of looking for a new personal project. And I was like, you know, I'd really like to truly learn Lisp. Like, I had my copy of SickP, which is, I can see it from my desk. But it's not something I felt like I really knew well. And it had always had this allure, right? Like, this is true programming.<br/><br/>But then I like, well, how come people aren't using it so much? Why isn't anybody building big things I've read about? And I just started to research. I'm like, well, where is Lisp today? Again, at this point, it's toward the end of my career at Birchbox. I guess it's probably seven, seven, years ago. And in that process, Clojure popped up on my radar. And I thought, this is pretty cool.<br/><br/>And just the idea of a JVM hosted Lisp really appealed to me. just thought like that kind of bridges the gap that I think was missing, right? I'm like, cool. Like now I don't have to wait for people to build every tool I might possibly need. I can access it. And I don't have to contend with, you know, performance issues as much, right? Like that you would think of something in that paradigm. was like, no, I mean, people have invested billions of hours into optimizing the JVM. It seemed kind of like the best of all worlds. So I was just really attracted to it. <br/><br/>And then I started playing with the language and teaching myself very slowly. It was a bit of a learning curve. As I said, I already had a bit of a background in Lisp, but still, there was definitely a little bit of work for me personally to come up that Clojure curve. It was also right as our first child was being born, so maybe it was a little sleep deprived too.<br/><br/>I just remember those early days really enjoying getting little bits of time to sit down and play with the language. And there are just a number of really well-written books out there that I just really enjoyed getting to get my teeth around it. As I was transitioning out of Birchbox, I was very lucky my last year there, I was kind of on a partial schedule. And so I looked for an open source project to contribute to and I found YetiBot, which is a really fun little project run by a guy named Trevor Hartman, who's just a great human and a great engineer and just really a good community builder. <br/><br/>So that was a great experience to get to build something useful, learn from people with more experience, do a little bit of mentoring of people who were coming up with even less experience than me. And yeah, that was my introduction to Clojure. And then once I finally left Birchbox and I was thinking, well, where am going to go next? A real big thing for me, there were two big career motivators for me at that point.<br/><br/>One was that I had been a VP of technical operations. had been a systems architect. had done a lot of professional programming, but I'd always sort of worn two hats of like system side and software engineering side. And I really wanted to move out of like VP tech ops into more general VP of engineering. So my career goals at a Birchbox were to find someplace that would let me take on the wider challenge of all of engineering. And then the cherry on top would be if I could get into like a zero day project, you know, somebody's like total greenfield early startup and convinced them that we should build it on Clojure. It's like that would just be the best thing ever. <br/><br/>And I held out for a little while and I found a really awesome lady who had just come out of Y Combinator and she had this fun, interesting idea of building a set of mechanical robots to do testing of mobile apps. And I thought, wow, this is really well suited to Clojure. Like one way to characterize testing as a state management problem, you know, like control things and then change some and see, you know, assess the delta. <br/><br/>And the other is it's just a big concurrency problem, right? Like orchestrating a whole bunch of robots. I'm like, well, what do I know that's really good at state management and concurrency? And then I explained Clojure and she's like, what's that? But after a few conversations, she bought in and I guess the rest is minor personal history. So that kind of brings you up to today.
Vadym Kostiuk
We will be talking a lot about your experience at Mobot as it's an interesting case when you started up a Clojure project literally from scratch. But to begin, I'd like to ask you, if you could summarize what Mobot does actually, in a few sentences, can you please share it?
Jereme Corrado
For sure. Absolutely. So if you are building a mobile application, you, as is the case with any software product, should test it. If you want to test it, there are a lot of really good ways to test mobile apps. There are great virtualization platforms for both of the dominant OS families, iOS and Android. And you should absolutely leverage those tools. Depending on your application, those could get you all the way, but they could maybe only get you 85% of the way. Depending on the criticality of that 15 or whatever percent, you will probably find yourself doing some manual testing. It's a bit of the dirty secret of the mobile industry that there's just a lot of manual testing that still goes on. <br/><br/>My founder was a PM and she had a pretty mature mobile application and she had a desk full of mobile devices and for every release she was still poking away on 15 different phones just to make sure even though they had a really replete test suite and it was well conceived engineering, good release pipeline. She's like, isn't there a better way? Let's build some robots to do it. And then that is how Mobot was born.
Artem Barmin
You mentioned one step back that you had a conversation with CEO about Clojure. And I'm curious, what did you say actually about Clojure? How do you sell it?
Jereme Corrado
Yeah, sure. So this is my whole thesis on teams and language selection and tooling. And it may be a little divergent, which is not to suggest that the typical arguments people make about the fitness of a language for a particular task isn't critical. I think it absolutely is. I adore Clojure because it is a fantastic way to solve programming challenges. But that is not how I actually managed to get it over the line with my founder. And it is not actually what I would characterize as its greatest superpower. <br/><br/>She asked me, she's like, how do we build an engineering team? What does software engineers want? What makes engineers happy? Like what motivates them? How do we keep them? How do we find them? And I was like, engineers are super duper simple. She's like, do mean? I'm like, no, no, we're very simple. We all just want to build something we're proud of. Right? Like we want to build something where we look at it and we're like, that's, that's the best I was able to produce right then with those constraints, that time, those resources, this is the highest quality outcome I could produce. Like we just want to build things we're proud of. <br/><br/>So what I think Clojure's superpower is, it's a fantastic tool. The ecosystem is a great community, but it just attracts a quality of engineer that I want as my colleague. And the thing is software is at least for the foreseeable future until LLMs totally take over. It is built by people. And I find that when building a team, building a new product, you're thinking about the software architecture for sure, you're thinking about the tooling, but just finding the right people is really what it boils down to. We hired, we're relatively small shop, 15 engineers. Most of those were very senior people. Most of those were people who had a lot of Clojure experience. But two of the people we hired had never even heard of Clojure. I just knew that they were the cut from the right cloth and that they were just the right kind of people you wanted as a colleague and they could learn. <br/><br/>So the way I got Clojure over the line with my founder, one, she and I just had a good rapport and she trusted my technical call. And I said, this is the right language. And then I made a bunch of arguments about. Concision efficiency, density of defects, you know, all the stuff people normally say. But the main thing is I just was, I just explained that this is going to help us find the right engineers to build the right product. <br/><br/>I will also note we had the advantage of being tasked with building a product that really benefited from a high level of quality. And what I mean by that is not every solution needs to be solved with top quality engineering. I mean, the reality of it is as a professional software engineer, you are tasked with delivering a solution within a set of constraints. That doesn't mean that everything you ever build has to be the highest quality. And that's a bummer. None of us liked that, right? We all hate that. But that's the reality of it. <br/><br/>When you're building testing tools, when you're building infrastructure, when you're building things for other engineers, you can justify a higher level of polish. It was actually one of the things I was very intentional about seeking out as I left Birchbox, which was e-commerce, Beauty In a Box. It didn't require, you know, top quality engineering. It required really thoughtful engineering and it was a great team. That team is always, I thought, punching below their weight almost. Like they were more talented than what we had to ship. But I specifically wanted to work someplace where I could justify really high quality engineering. <br/><br/>So with that in mind, you can bring in something like Clojure. You can lean into a team model where you're going to be paying for and staffing more senior people because you're going to be producing something of the appropriate level of quality. But I still thought it was a good idea to mix in more junior people just for the fitness of the team and just team culture. So it was pretty easy to get it over the line with my founder and explaining to her, like, hey, this is the right quality of engineering. But really, I think it was just, this is going to help us find the right engineers to build the team, the company, the culture that we want. Because it's a very engineering-first company. <br/><br/>I joke with people all the time that when you're trying to build a team, Clojure is a painful filter. You're going to find 10,000 more JavaScript engineers. But it's a great selector. The 10 engineers you're going to find, they're probably 10 engineers you want to work with. It's almost nobody's first language. And the people who come to it generally bring their own steam. They're people who are curious and excited and people who appreciate the elegance that a language like that allows you to embrace. So I thought it was a really good choice. It worked well for us. And we also were very lucky. We got to build a very complex backend. We decided to build the whole front-end enClojure script. We had a mobile app that we built, know, with ClojureScript Expo. And we also had a pretty complicated sort of like middle-service tier, a lot of independent daemons that we built for doing things like packet captures and log aggregation. And so there's a lot of fun engineering opportunity in there and Clojure really overlaid well with pretty much all of it.
Artem Barmin
Yeah, I heard this idea about Clojure as a filter. Basically, it makes the hiring process easier, I think. Because if you have a Clojure engineer, for some degree, it should be a good engineer. Because you need to spend a lot of time learning LISP, setting up the infrastructure, learning new concepts and such kind of things. And if people already did this, that's a good sign.
Jereme Corrado
Plus they're so excited to work with Clojure. We were lucky, right? We were like, we make robots and we use Clojure and we build developer tools. We were not short on people who thought it was a fun project to work on, but yeah, you're absolutely right. It brings in just great developers, great engineers.
Vadym Kostiuk
Yeah, I just want to say that it's funny you mentioned this terminology filter. I just want to say to our audience, we haven't asked you to say it because you're like the first person on our podcast who said the same thing, that Clojure acts as a natural filter for engineers.
Artem Barmin
Yeah. And did you have any alternatives if we speak about languages when you started this project?
Jereme Corrado
Yeah. I will say I am fundamentally a backend engineer. I have been my entire life. I always joke with people. If you want me to build the front end, it's going to be gray and left justified. I'm just not the one, which is not to suggest that I don't love a really high quality interface. I absolutely do that. Just the feel of tools really matters to me. I just know that that's not my, my special power, not my secret skill.<br/><br/>I also have an ops background and a hardware background, so I've just always been a backend person. So there was really no question that we were going to build the control plane, the service tier, the back of the front end. There was no question that was always going to be Clojure. Came in and the bee was in my bonnet. <br/><br/>I did not know how we were going to build the front end. In the early days of Mobot, we really didn't have much of a front end. We had a very lightweight reporting layer, and it was server side. We used Luminous as the framework initially. We had a Python desktop app using Tkinter. I don't know if any of you know TK and the old TickleTK days.<br/><br/>Just because we were initially directly connecting the robots over a serial bus, just USB onto a laptop to do this stuff, in later days we pulled that into a Raspberry Pi and that became the high level controller on the bots. The bots have always been stateless and that was all Python, was all step remote or interconnect. So there wasn't a ton of a front end in the very, very, very, very early days. We're talking the early days, like the first six months and a bunch of us standing around and we work.<br/><br/>And then the first engineer that I hired was a friend and former colleague from the Birchbox days, a guy I'd worked with for many years. Brilliant engineer, just a guy I've always, and just, just an awesome human. And so he was the first guy I brought in. And I was like, his name is Luis. I was like, Luis, what are we going to the front end in? I guess, I guess JavaScript, right? And I don't know JavaScript. And I'm famous amongst my friends and colleagues as being kind of a JavaScript hater. And I feel like, I maybe should be more informed before I put that on my resume, but I know, it's just an ugly little language. And anytime people show you weird JS anti-patterns, I was looking at and thinking, well, that smells funny. But whatever, it's super useful, it’s out there. I assumed we were going to just build a React app or whatever. <br/><br/>He's like, no, we should use ClojureScript. And I was like, man, I want to buy into this. I really do. I'd read about Transit, and I was excited at the prospect, I really...<br/><br/>I like spec, I like the idea of being able to have a common description for the data as it moved through our system front to back. But he was one who convinced me to ClojureScript. And his whole thing is that, and he made a really strong point, we had been watching this rising tide of functional idioms in the front end. People had just paid enough, I guess, enough pounds of flesh to callbacks and just nasty nets.<br/><br/>And he's like, no, there's enough people who are going to get the idea. We could definitely use ClojureScript on the front end. And that's what we did. And absolutely no regrets on that. It's been great. I think some of the promises of ClojureScript, it delivered. I think it delivered a little different than I was expecting. So we can unpack that in time if you want. <br/><br/>So I was dead set from the beginning. We were going to use Clojure on the back end. There was no other alternative option, and for the front end I was like, meh, I'll wait till my first hire who is much more knowledgeable here and much more opinionated. I just presumed it would be JS and TypeScript and stuff. And he's like, nope, let's go ClojureScript. And no regrets, really glad we did. As a matter of fact, one of the most talented Clojure engineers I know, again, another colleague over at Mobot, just another brilliant dude, he once described ClojureScript as Clojure's killer app. And I thought that was just a really interesting way to frame it. He's great front to back, but he just had a particular fondness for ClojureScript and it worked out well. <br/><br/>Yeah, as for the service tier, there are actually a few other languages we wound up using in a few places. Like one of the things we do is a lot of the way Mobot represents state is visually, right? The core design of Mobot is this idea of a big directed graph where like there's the advice in a state you apply some action, this produces another state right the vertices are just generally represented screenshots. And to get screens off of devices, we would use ADB on Android, where it made sense. We would use AirPlay. So in some of the screen acquisition stuff, we wound up using C++, just because it made sense. But by and large, the rest of our system, the preponderance of the service tier was all Clojure. <br/><br/>A little bit of interop here and there, which we did. We also did a bunch of streaming. You could watch the bots as they were working. So we did a lot of WebRTC stuff. We used some JavaScript component trees. So we did a lot of interop there. We did a lot of Java interop, just talking to different GCP resources. But yeah, no, it was always Clojure, front end’s moved to ClojureScript.<br/><br/>And then I was really not sure what we were going to do for our native app. I'm sorry, for a mobile app. I presumed we would have gone native. We actually use ClojureScript and Expo. That's actually the only decision that I had more of a management role in that. I wasn't an IC on those projects, but I was more design and oversight. I know the team there after two years kind of felt like, eh, maybe we should have gone native. It was relatively small, an internal app. We do a lot of calibration of the phones, and we need to do a lot of screen manipulation. And I think some of the abstractions that the tool chain provided got in the way a little bit. it was clearly very high quality tooling, and I don't want to besmirch it or suggest anything less. Might not have been a perfect fit for our team. But yeah, those would be the language selection choices as they went. And then I said there's a bunch of Python, all the robot stuff, all the motors. It's all Python.
Artem Barmin
How do you think, did ClojureScript solve some issues that you would have with JavaScript?
Jereme Corrado
Yeah, so I can't offer as informed a perspective as I can on back end things where I was a primary code contributor, but I can tell you as this is a small and very tight team, we spent a lot of time with upfront design discussions. So I think I can maybe summarize and speak to the trade-offs and understanding my team reach and these are people whose opinions I would respect. I respect very much.<br/><br/>My big takeaway from ClojureScript in the end was that I don't know that it made us move any faster, you know, from today to tomorrow necessarily, but I think the quality of the product that it produced overall, fewer defects, easier to reason about in your head, greater clarity and subdivision and reusability, I think it was definitely a big net win for us. But if somebody tells you like, “Hey, write this in ClojureScript, you're gonna get it done in a week instead of three”. That may or may not be the case. And for us, I don't know that it moved us forward in the early day to day faster, but it definitely produced something much more maintainable, which leads to overall speed for sure. So that was the payoff for us with ClojureScript.
Artem Barmin
Correct me if I'm wrong, but that was your first project when you decided to use Clojure as a full technical stack.
Jereme
Yeah, the first paying gig with Clojure. Prior to that, I'd done some open source. I'd done a bunch of personal projects. I'm a tinkerer, just by nature. So the first thing I really built where I showed it to somebody is when... This is ridiculous. When I was at Birchbox, I remember the VPM... So Birchbox was a very fun place to work. A lot of fun perks. One of the things is we always had just cold brew on tap. Like these big casks of cold brew, everybody loved it. And I remember, you know, people would just queue up in the morning and get that. And after a while, people stopped buying their own coffee and they would just come to work and they would just drink the free cold brew. But every once in a while it would be out. And right. was just apoplectic, right? Like where am I going to get my free coffee? <br/><br/>I remember the VP of marketing came over to me one day. She's a very cool lady. And she's like, is there any way that the cold brew could just maybe email me in the morning or tweet or something so I know if I should get coffee or not? I just thought it was really kind of a funny request. And that was actually one of the first things that I built an in Clojure myself. <br/><br/>One of my colleagues was into hardware. And so he used an Arduino. We got a little flow control valve. We tapped into the feeder line on the cold brew cask. And so we were able to keep account of how much was in there. They would put in a new cask, you would reset it, you would count how much had been distributed, and then could tell people when it was getting low. The Arduino connected over RS-232, a traditional serial interface, onto a Pi. And on the Pi is where I ran a little Clojure daemon that just tracked the capacity of the cold brew cask when it was empty and just would send out emails when it was low. So that was the first thing I ever really built in Clojure that anyone ever used. I built like a crappy slide the paddle line break game. But that was it. But Mobot was really the first thing, like a real honest project with other engineers and funding and such.
Artem Barmin
Maybe you had some, you know, challenges that you were expecting when you started using the Clojure because, you know, it's pretty risky decision to select such niche technology and on the role of, I know what was the role when you started work with Mobot. It was VP of engineering role or it's kinda, it was a bit more technical.
Jereme Corrado
I started as the VP of engineering. I was the first full-time hire. There was another lady who was an initial consultant doing some mechatronics engineering. And there was a lady who did some marketing consulting, but I started and it was Eden first employee. Eden is my founder, was my founder, first employee. I started, there was nothing there. So it didn't feel super risky. It felt like a reasonable technical decision, right? Like it was a proven robust language. It was a rich community. It had all the things we needed and it sat on the JVM and you could elegantly go grab the functionality that somebody hadn't produced in a native fashion. So I didn't feel crazy about that. And I knew that we would be able to hire up the people we did. <br/><br/>And one of the things that as an engineering lead in venture capital backed startups, one of the things you are assessed on is hiring. How quickly can you hire the right people? We were consistently able to hit all of our hiring targets in record time. consistently beat out the rest of the portfolio companies. We're always able to add the right engineers at the right price point very quickly. So from the outside, there was definitely always.<br/><br/>We definitely had investors ask us like, Clojure? Really? What's that? Why? Why not just build it in JavaScript? And we can talk about why people, you know, hedge those bets. But when they saw that we were consistently releasing features, we were on time and we were building the team, they were comfortable. They were happy with that. But of course, you know, they always ask you, don't you just, it's like that old joke, right? Nobody ever got fired for building it in Java, right? Like there's always a safe choice. <br/><br/>But I think we proved pretty quickly that this was a reasonable one. Really the main one for me was just once I convinced my founder and once she offered up that trust and buy-in, I felt like, okay, cool, we have a clear mandate. Let's get building. And then as we were able to ship the features she wanted, everybody was happy.
Artem Barmin
I see. You know, one of the goals of this podcast is to give other technical leaders who are curious about Clojure, real-life perspective, how it actually works if you choose Clojure in the startup. And yeah, you mentioned hiring and that's great that it wasn't a problem to solve this
Jereme Corrado
It wasn't, but I don't want to suggest that there, cause you're right in intimating that there's going to be pushback. There's going to be concern. I mean, I've mostly done startups my whole life, so I can really only speak to that model for funding and the leadership that gates it, right? Like the people to whom you have to answer. And my experience is that you are primarily answering to successful people who have built and exited, right? And so there's a natural confirmation bias that comes with that, right? People are like, hey, I've done this. I know how to do it, right? <br/><br/>And I think a very reasonable first blush you get from people is why not use the most proven and widely tested thing. But my experience was that as we were able to rapidly deliver functionality and that there wasn't a demonstrated deficit to the talent pool, right? Like we were able to quickly add thoughtful engineers producing good quality code. I think that basically is what got it over the line for us. <br/><br/>I think the other thing that benefited us - I feel like as an engineering leader, big part of your life is technical debt trade-offs. And, you I was fortunate enough to have founders and investors who had enough experience to not only assess your daily, weekly, monthly velocity, but rather to understand like, okay, sometimes an engineering team will move at a good clip for six months. And then all of a sudden you'll ask them to do something new. And there's this unexpected delay in delivering the new functionality because they have to retool, they have to walk back old decisions, they have to pay down some debt, they have to dig themselves out of some holes, or they painted themselves into a few corners. You need to like, we have to do all of this stuff. And at the end, everything was going to work exactly that it did, except now we can add that new feature. <br/><br/>One of the things we were able to do on our team was basically keep those technical debt trade-offs low enough so that our daily velocity felt fast enough, but we never hit any, hey, we're gonna need to redesign this for six months before we can deliver a feature. We were able to move pretty consistently. I attribute that to the seniority of the team, good architectural insights going forward, clarity on what we needed to build, we never had to pivot. <br/><br/>I think once you get enough of those ones under your belt, like our leadership was pretty senior and I think after the first year, not seeing any of that, they're like, okay, these guys did it. Cause people stopped asking me like, why didn't you just build in JavaScript after the first year?
Artem Barmin
So basically answer to investors and their questions about technical choice was the results.
Jereme Corrado
Yeah, I think demonstrable results, which I think it's easier when you're a tiny, when you're the first boots on the ground, right? Like you get a little bit of, like nobody's expect you to show up with a working product, right? Like they give you six months to see what you get. And if you can show them something useful quickly, it's, know, the proof is in the pudding, so to speak. <br/><br/>It's one of those things where like once you deliver, they ask fewer and fewer questions. And we never had any sort of a problem where we needed to go blame the tool chain or the language, right? Like, sorry, I can't do that. You like, you pick a language maybe that doesn't have strong support for concurrency, and then you have a problem that can really only be solved sensibly with your concurrent design, and then you're like, shoot, now we got to we didn't have any of that, right? It was well suited for what we wanted right out of the gate. But again, it was also just about, it attracted the right engineers, and these were like super motivated, very productive people who were very excited by the problem space and they just cranked out tons and tons of code and moved it along quickly.
Vadym Kostiuk
You mentioned it a few times that it was really easy to find a team. However, it started only with you. So as far as I understood, now there are like 15 engineers in the department. It's interesting to hear how the team evolved through the years. mean, at what point you decided that you need this amount of engineering team and then hire a few more engineers. How was it? Yeah, how was it for you?
Jereme Corrado
It's based on funding. It's when you get a new round of funding, you get some new money. So the way that funding generally works is you have sold some investor on the idea of what you can do if you have the resources. Like, hey, I've done this, I've proven that. Now let's stretch to the next thing. I need you to pour some fuel on the fire. Give us another 10 million bucks, we'll hire another 10 engineers and we'll deliver this in another 10 months. So it's that kind of thing. <br/><br/>So the hiring cadence is generally beholden to the funding. The funding is beholden to, well, you need a great founder who can build those relationships. I spent a lot of time contributing to fundraising, but I was not the leader. It's a special skill and you need to have a founder who has it. <br/><br/>As an engineering leader, you need to be a part of a really high quality dog and pony show, you need to get people to buy into the vision, you need to demonstrate it. But yeah, our team growth was always gated by funding and funding was gated by people buying into the next iteration of the vision's expanse. Yeah, so that's how we were able to sort of stepwise grow the team, right? It was in the very beginning, there were four software engineers, well, there was one and then there were four and then there were 15.
Vadym Kostiuk
And can you please tell us a bit about your responsibilities as a CTO at Mobot? I imagine they evolved through the years and were you actually coding as a CTO or you were busy with some other responsibilities and duties on the team?
Jereme Corrado
Yeah, I can describe my role in these. I feel like roles, like we're all familiar with those titles, right? VP of Engineering, CTO. I think they're expressed in radically different ways at different orgs, depending on the character of the org, the problem their business tackles, the size of the company, right? Like there are plenty of CTOs out there who are boardroom CTOs. They're executives, they're not engineers. They are executives who are tasked with advancing the company and the ore they are given in moving the boat forward happens to be engineering. <br/><br/>That is not at all what it's like, I think, oftentimes in small startups. I've been through a bunch of startups and I've been fortunate that my CTOs, every time we're super technical people. The lady who was CTO at Birchbox, brilliant computer scientist. Before I was at Birchbox, was at Meetup. Greg, the guy who was the CTO over at Meetup, engineer through and through. So I think on tech startups, there's a lot of times that the CTO is really an engineer who just sort of snuck into the monthly board meeting. That was me. <br/><br/>So my role. First real FTE boots on the ground. I was there to just write code. And I basically, day in and day out, just was sitting there. I would talk to my founder. We would go over the vision, like, what are we building? What is the character of our solution to this problem? How do we think about testing? How do we think about a mechanical fleet to automate the gaps in virtualized testing? You know, I still have all my early notebooks, which I recently went back through to read like the design work. And you just sort of come up with an idea and you just start coding. You make those early decisions. We're going to shove this into a graph database. Nope. We're going to make it square and shove it into Postgres. Okay. Are we going to… You know, how are we going to host the application? You make all your early decisions. <br/><br/>And I spent the first two years, I would say, just doing design and coding day in and day out, grinding and grinding and grinding. And we had four engineers, then six engineers, the first couple of years. So my role in the very, very early days was, you know, I was primarily contributing code, designing stuff, doing some team building, doing some culture. But, those early days we were a 20 people company, then the company grew to 30 people and go from there. As we got bigger and bigger, and my role was always VP of engineering. <br/><br/>As we got bigger and bigger though, we kept the engineering team mostly flat by choice. In time, as we got larger still, we began to introduce a bit of an intermediate tier of managers. All of the people on Eng, they were all ICs who really wanted to have their fingers in the code. I actually think that my success to whatever degree I can claim to have had any success as an engineering lead is really largely born of the fact that I am just fundamentally an engineer and I like writing code and I like building stuff. I think that that…<br/><br/>So the reality of leading an engineering team is you're going to have to make a bunch of ugly decisions at times of which corner to cut. And if you are an engineering lead who is still very hands-on, if your team respects you, you are going to be able to sell those compromises, right? Because they're going to be like, okay, this guy gets it, right? Like he doesn't like, you know, stinky code, but he understands sometimes there have to be trade-offs. And honestly, being an IC, you're kind of blessed with the luxury of almost getting to always take the high ground, right? Like it's the bummer role of the engineering lead who has to decide where to cut a corner.<br/><br/>So I've always liked being very much an individual contributor. And even in my leadership goals, I was always an IC, even if I was focused on architecture and team growth and, you know, and stakeholder management, I was still always having a lot of my time where I was directly involved in design discussions, directly involved, you know, grab a few tickets, write some code, you know, do code reviews and then put up code to be reviewed. So I've always been very hands-on. I mean, I've also never worked in any place with more than 300 people. So take it for what it's worth. <br/><br/>And then in time, I transitioned out of EPOE to CTO. I did that because it just felt like something I really wanted to accomplish professionally. I don't know that I ever need to be a CTO again. It was great. I'm very proud to have accomplished that. It was a lot of work to get there. It was not something that my founder or my board were just going to give out. It was something I really had to earn. But was my day-to-day truly different? It was in the sense that you have to sit down with your organization and decide what CTO means to your shop. And what we decided it meant for us was that we would begin to bifurcate the leadership of engineering, and we would have more of a day-to-day engineering lead.<br/><br/>And then CTO would get to be a bit more future focused, a bit more exploratory. I was very, very, very fortunate that I was able to hire a dude that I had worked with at two prior startups, my friend Dave. So Dave joined Mobot. It was our third startup together. When he joined Mobot, we had already been friends for 16 years. We worked together at the Electric Sheep, which was like a virtual reality gaming second life weird fun startup way back when. Dave was always just a fantastic engineer when we worked at Birchbox. He was always like my go-to guy when there was a real big problem. I would take the operations side, he'd take the soft edge side. And then he transitioned into a bit of more of a management role. He just really liked it and the universe is blessed with those rare software engineers who really decide they want to be great people managers and he was one of them. And so I scooped him up as quick as I could over to Mobot.<br/><br/>And so then as I grew into the CTO role, got to pull away a little bit more from the daily operations. He rose as head of engineering to take over daily ops. So he's the guy at that point who's doing, grooming a backlog and running sprint planning meetings. And I'm doing more of the architecture and design meetings, which are the things I like and I think where I can make a more useful contribution. So that's what CTO meant to our org. And then of course it's talking to the board and talking to investors and all of that kind of, you know, stakeholder.
Artem Barmin
The whole story that you told looks very, very smooth. So it looks like you didn't have any challenges, any problems, I don't know. There was no problem with hiring. Everything was technical, stack was great. But, you know, for me, it's really important to cover not only benefits and good sides of a technology. And I always want to know what real limitations, drawbacks can exist actually in the platform. Because if everything is great, for me it looks like not the full picture of a technology, of anything actually. And I'm curious to hear maybe some challenges or drawbacks that you faced.
Jereme Corrado
Yeah, I mean, there are certainly lots of bumps. I just think they were mostly my fault and not Clojure’s. I can speak to a lot of bumps, but they're going to be more like the bumps I experienced as an engineering lead in a startup. I don't know that I point to Clojure as having a particular role in that. I led a team that lived through the biggest engineering hype of my life, right? The big like, hey, where's AI in our product kind of a thing.<br/><br/>One of the challenges that I have faced over the years as an engineering lead, there would really be two big ones that come to mind. One is that I once inherited a product with a tremendous amount of technical debt. And the other would be that in my time at Mobot, I think there was quite appropriately, and I don't want to suggest to the contrary, quite appropriately a lot of pressure like, hey, are we keeping up with the tide of AI and ML solutions? <br/><br/>There were a lot of those types of things like, hey, are you guys making the right choices in terms of a product roadmap? So there was always plenty of friction and pressure and scrambling there. One of the first things I was tasked with as I moved into my CTO role was to explore like, hey, could we bring AI to bear on some of our more complicated image analysis problems? So that was a fun project.
Artem Barmin
How do you assess the usage of Clojure in the area of AI and all these libraries that are available for Python?
Jereme Corrado
Yeah, so the AI project we did was in Python, as it were. We used Fast AI. I myself have no experience with machine learning projects in Clojure. Certainly, I'm no expert on AI and ML, but my experience having built a useful tool in our org that did what we needed it to do, was advance, improve the efficiency of the way we assessed images from baselines to actuals as tests were progressing. My experience there was that a tremendous amount of the efficacy of the models we built was a product of the data we shoved into them, less so than model parameters or tuning or training, right? Those processes were pretty well understood. We were able to use a lot of off the shelf stuff and without a tremendous amount of effort, we were able to deliver pretty high quality results. But the biggest factor for us was the data we shoved into it and all the data we shoved into it moved through Clojure based systems. So in that sense, they were very central to it. I think our ability to just generate tons of input data effectively through the success of the product more generally would speak to the way those projects progressed and the success they met. But I didn't do any direct training with Clojure as the overarching harness or anything like that. Sorry.
Artem Barmin
That's very interesting because the data aspect is not always covered in success of the models that we've created. And Python is not the best tool sometimes to gather the initial information.
Jereme Corrado
No, actually we did a ton of, I mean, a huge, so we at MOBA, we ran tests, right? We tens of thousands, hundreds of thousands of them daily, right? Actions. There's just a tremendous amount of data generated in that process. There's device logs coming, right? There's all the screenshots we're capturing. And a big part of what we did was also like, we own the device under test. We own the whole network egress path. We were able to do transparent TLS decoding to intercept the communication between your application and your backend, right? Basically a man in the middle, but with the blessings of everyone involved, right? <br/><br/>So we were generating tons and tons of data. How you do all of that capturing of that intermediate data, that's really where Clojure shined for us, right? Like take something like doing like network telemetry, right? There's obviously a lot of infrastructure involved in that, just routing traffic the right way, egressing through the right points, having that visibility to intercept. But in the final analysis, you wind up with tons and tons of PCAP streams being generated by daemons sitting on routers or multi-home hosts that we were using as routers. And we were using Clojure daemons to read a bunch of PCAP sockets, decode those packet traces, group them by source IP, chunk them, shove them up into GCS, throw a message onto an event bus so that a downstream processor could work on it. That level of efficient processing of lots of concurrent inputs, that's really where Clojure was just a huge, huge lever for us. There wasn't really an easy way to do that, in my experience, with something like Python. We weren't going to do that effectively with Python. <br/><br/>The Clojure and the JVM support for concurrency, its performance, stuff like that, we really leaned into it. It really did well for us. We were aggregating millions and millions of lines of log data every day from hundreds and hundreds of phones on robots, all Clojure daemons that we were running in various places around our network to do that.
Artem Barmin
Yeah, Clojure really shines with data-oriented programming and data manipulation because it's kind of native. You don't need to think about, for example, from Java about data transfer objects, getters, setters, all this stuff just to manipulate the data. <br/><br/>Sometimes I see from my prior experience, because we do consultancy for different Clojure projects, and sometimes I can see that the power that Clojure gives to developers creates some very over-engineered, strange solutions like macro-based domain-specific languages.<br/><br/>Have you faced these kind of situations in your practice?
Jereme Corrado
Yeah, for sure. I don't think I would limit that specifically to Clojure, though I do agree with the connection you're making that the power almost makes it an easier mistake to make. I'll give you my sort of generically, but I think an honest answer, which is that over-engineering, under-engineering, bad engineering. I think that it really all comes back to like, what is your team's culture in terms of design discussions? <br/><br/>I remember a long time ago, I worked at a shop and we had a standing weekly meeting called the design review. And basically what happened is people would work on stuff. They would bring it to design review. They would share it. People would critique it. And then people would get grumpy because they're like, well, I already built it. Don't dunk on the thing I already built. So when I was establishing the design culture at Mobot, I was like, let's call it design discussion and let's do it before you go write a ton of code, right? Because people, once it's a precious thing that you've already built, they don't want to let go of it. <br/><br/>So to the question of over-engineering and the power that Clojure gives, for sure. But I think if you have a culture where you are reviewing designs collectively early on, where you have a good code review culture, you can keep people honest. Also as an engineering lead, I knew who on my team was going to be quick and dirty and who was going to be the one to introduce like three layers deep of needless abstraction. It's funny. I was actually just writing some code yesterday, a little toy project. And at the end of the day, I sat down and I looked at it and I'm like, why am I abstracting this one thing? There's only one of them. I don't need, like I understand over here, I have six things that kind of are the same. So there's an abstraction from that over here. I've got one and you know what? There's never going to be a second one. And so if there's not a rigorous review process, think anybody can fall into that. And then yes, there's always the dude on your team who wants to write a bunch of macros. There's just, are very few, in my humble experience, there are very few places where I have found that that has, the benefit of that has outweighed the cost. So I think it's really just, you know, review a bunch.
Artem Barmin
Actually, you are not the first one who talked about the importance of decision-making culture and the process. Other teams use pre-mortems and all this voting. You can hear it in other episodes. It's pretty interesting to hear what the differences, but they all come to the same. It's collective discussion beforehand, usually.<br/><br/>The next very important question for me, also from our experience of doing consultancy, we sometimes see push from Clojure to more mainstream languages like TypeScript, like JavaScript, especially this is connected to the front end tasks. And I am very curious to hear your story about maybe you had this internal push or external push from investors to switch the stack to more, I don't know, more popular.
Jereme Corrado
Yeah, for sure. I can recall specifically after our series a funding when we were doing a big hiring push, we asked ourselves the question. We're like, okay, is now the time like Clojure on the back end was a, was a clear, clear path for us. But we did at that point ask, we're like, okay, we're at a fork in the road. <br/><br/>Should we hang up the ClojureScript based front end and just move to, you know, know, TypeScript and more widely embraced solutions. We sat down and had a very careful week of reckoning where we weighed the benefits and costs for us. And we decided it was worth sticking with for us. I think it's going to be a very personal choice for each team. At that point, we had worked with it for two years and already had the perspective that even if it didn't add tremendous day-to-day velocity, it just produced a clear, more coherent product that was easier to reason about, lower defect rate, easier to extend, people were more comfortable with it. And given that we had had no trouble finding engineers to add to the team, we weren't really wooed by the ubiquity of the talent pool in JavaScript. Also, we had been very happy with the level of sophistication and quality of the engineers that we had had.<br/><br/>Quality over quantity, though not trying to besmirch JavaScript engineers, mean, there's tons of brilliant ones. It's just our experience was that sure, there's tons and tons more, but we have been very happy with the Clojure engineers we have and the transition to ClojureScript. We also had a couple of people join our team who were established Clojurians, but had no real ClojureScript experience. And they made the move to that easily. So we didn't see any of the hurdles and we'd seen a lot of the upsides to it. But for sure, you definitely have investors who are like, why aren't you just going to build it in JavaScript like everybody else? But at that point in series A, we had had this track record to point to.
Artem Barmin
Sometimes I notice the situation that most of the Clojurians that I've interviewed, they really like back-ends work. And sometimes it's hard to find people that are Clojurians and they also have experience with React.js, with CSS, with all such front-end work. Maybe you have some face, maybe you faced some similar situation.
Jereme Corrado
I think I kind of got lucky. As I said, the first guy I brought on was an old friend and former colleague and he had a lot of ClojureScript experience. And so I went into my first experience, you know, working on a project with Clojure script one, I didn't do any of the Clojure script myself. He did, I got to just go back and he did the front end. <br/><br/>And then when we had our next big push of hiring. We basically, it was about 40% of the people we brought on had ClojureScript experience right out of the gate. And then, you know, the rest sort of filled it in as they were curious. We had one or two people who had no interest in moving ClojureScript. We also had one person who came, she joined our team as a front end engineer, but no Clojure experience. She learned Clojure. She did a year of working on the backend and she said, I have no interest in the backend. I just want to be the front end. So people, know, their proclivities make themselves clear and you follow that. But we did not have specific experience with the challenge of people moving front to back as they were inclined.<br/><br/>I will say though, I have not done any ClojureScript and so it looks opaque and challenging. I don't know, I'm trying to find a potential award. It looks tricky to me, so maybe it'd be hard for me, but for the rest of the people on my team, it was not hard. They had very good comfort with it.
Artem Barmin
Glad to hear that, you know, there was not a big problem here. And we move into our last block of questions. And can you assess the current state of the Clojure ecosystem? Do you like the direction where Clojure is moving? Clojure script, the whole tool set? Maybe you dislike something?
Jereme Corrado
Yeah, I think the first thing I would say is that I don't know that I'm the most well qualified to opine there. Like, you know how there are people who are very much have their finger on the pulse of where community is going, what's new, what comes out. I'm not that person. I just have never really been. I mean, I periodically pop into Clojure.org and check out the news and read a few links and follow stuff, but I'm not super up on it, but.<br/><br/>As I was thinking about that, I almost feel like that speaks to Clojure strength, right? Like I remember working in, know, Ruby, Python, if you would need a lib and you'd go and you're like, nobody's touched this in 18 months. You're like, that makes me nervous. Whereas like in Clojure, you'll go and you'll find something that no one's touched in two years. And you're like, I guess it just works really well. I guess like it does its one thing and you know, everybody's happy with it. <br/><br/>So I don't have a really informed perspective on the ecosystem. But I will say that I don't have any concerns about the fitness for Clojure as a tool to solve problems going forward. Don't, yeah, no misgivings about that. And anytime there is a big new thing that comes out that I am following, when Core Async and spec and everything, anytime stuff like that comes out, I'm like, yeah, this is a great community of smart people and I'm really, really excited about the new things they're building that I get to use. <br/><br/>So it's been positive in that sense. Every once in a while, you'll see somebody like, is Clojure dead? I don't know how one assesses that. I mean, there are various metrics out there of like hiring and code-based and this and that, but you have some very large players with very deep pockets that are building, that are fully bought in. <br/><br/>So I mean, I suspect it's the same thing that, Haskell and OCaml communities all deal with, right? Like people who are passionate about it, but limited deployment, but a few really high-end shops where they go. Matter of fact, the guy that I hired first at Mobot, my friend from prior engagements, spoke well of Luis. He actually is only person to leave our team. And that's because he just got the Haskell bug and he went and now he works for Haskell shop. I still love him. He's a great human.<br/><br/>I think Clojure is still very fit, but I may not be the most plugged into the community. I don't have a strong opinion on where things are going. I will say, like, I checked in recently on, like, the Luminous to Kit transition, because one of the things I've always really liked about Clojure is actually they tend to askew big heavy frameworks. For example, I really like the programming language, Ruby. It's a nice little language. I don't like Rails. And that's mostly just because it's always felt very opaque to me and unapproachable. I'm somebody who like, I need to grock a paradigm and then I can figure out the way that that translates to a particular problem in front of me. Whereas with Rails, I always felt like, I don't know, there's probably some very long snake named method that will do the one weird thing I need to do and it's all trick ponies and I wasn't very good at understanding it.<br/><br/>In Clojure, we don't have these big monolithic frameworks, right? We just have, you know, like thoughtful aggregations of tools well suited to a thing put together. And I look at the way Luminous transitioned to Kit, and it seems to me to be a very healthy way to approach things, a very stable and mature way. So I feel like there are a few overarching factors that make me feel very comfortable in embedding on Clojure and the community and the ecosystem of tooling.
Artem Barmin
And it's rather common that people don't follow the news about Clojure, its ecosystem, but it's not a problem to build a product in Clojure. And personally, I sometimes use libraries where last commit was eight years ago. And I'm not afraid to use it because I can see the source code, it just solved the task and basically don't need to change anything there.
Jereme Corrado
They're often compact. As you say, you can go evaluate it yourself. The other thing is, you know, when, when thinking about is Clojure a safe choice, there's always, you know, the Java escape hatch, right? Like that interop is a huge, a huge win. And the, and the way that it's, it's bolted in first-class, right? It's not like a, it's not like a dirty secret or, you know, hidden. It's, it's just very pragmatic, I think.
Artem Barmin
Imagine that it's 2024 and you know already everything that's, you know, and you need to start a new product. Would you choose a Clojure as a main technical stack for it?
Jereme Corrado
it very much depends on the thing you're asking me to build, right? So if it is just good enough hack-and-slash 80% engineering, push it out the door, projects I don't really want to generally work on, but I think there's a ton of them out there and there are a lot of really compelling businesses built around them. Not every problem needs a heavyweight solution, but if you have a problem that requires good quality engineering, if you have a problem that can justify the cognitive demands that something like Clojure puts on you, in many ways, it's very freeing. But I, and maybe I'm just not as bright as the average bear, but it's not the easiest solution, right? Like imperative strategies are easy, right? Like get pot, fill with water, turn on heat, add noodles, right? Like it's very easy to work through a recipe. Whereas to just have to come up with a way to transform something progressively to yield the intended output. At least for me, it took a little while to establish those mental pathways. <br/><br/>So Clojure is not always the easiest solution, but once you've come up that curve, it is very easy to work with things. But I think of it as, it the right tool for the job? And when you have a large, complicated system, having paid the price for the required rigor of building a solution that is more considered transformation as versus just this disparate set of mutations, it pays off in the long term. So to answer your question, would I use Clojure again? It depends on the problem, but if it was a problem that required high quality engineering, it would absolutely be the thing I would reach for. No question, no question.
Artem Barmin
Thank you. Thank you. Very experienced answer. Usually the answer sounds like yes, of course. And you also set kind of limitations for the answer. And that's, I really appreciate. And the last, the very last thing actually is the chain of questions that we pass from one guest to another.<br/><br/>Our previous guest, Nathan Martz, he's founder and CEO of Red Planet Labs and creator of Rama platform. Maybe you heard about it. And he left a question for you. What the last time you spent all night working on a Clojure project?
Jereme Corrado
Two nights ago, two nights ago. And it was not intentionally. I have some small children and I do not get to stay up all night. I do not get to stay up all night because I often have to be up early because they wake up at the crack of dawn like farmers. I can say that I grew up on a farm.<br/><br/>So I don't get to stay up all night if I want. But sometimes they wake up in the middle of the night. Somebody needs to go to the bathroom, somebody's blankets all focac'da. My wife and I are basically shift parenting with our youngest who's up all the time. So I had him two nights ago, he woke up in the middle of the night, I finally got him back to sleep. And then I'm laying there and I'm like, I totally can't sleep. What am I gonna do? Well, I'm already laying on my couch in the office right next to that kid's bedroom, so I was like, I'm going to get up and I'm going to write some code. And I just sat at my desk for another two hours and worked on something for fun. It was delightful. And I didn't regret a moment of it until I had to get up three hours later.
Artem Barmin
Thank you. And what kind of projects are you writing?
Jereme Corrado
It's just a fun project for learning. I'm just, I'm actually just re-implementing Tetris just for the funsies of it. I don't have much of a graphics background, so I'm just playing with that.
Vadym Kostiuk
And this is the part of the podcast where you can leave your question to the next guest.
Jereme Corrado
Interesting, that was a way more fun question than I was gonna come up with. I was gonna ask sort of a lame-o question. Now I feel like I can do better.
Artem Barmin
We have different kinds of questions.
Jereme Corrado
Yeah, I'm gonna actually stick with my lame-o question, which I would just love, I just like to hear people talk about their experience leading teams where they intentionally hire people who don't know Clojure and teach them. Because I'm just like a real big believer in just hire the right people and they'll find a way to be useful and contribute. Just like hire smart, good, thoughtful, kind humans that you wanna spend time with and think through hard things with. And if they know Clojure, awesome. If they don't, they'll learn it. And so I've tried to be intentional at Mobot of hiring a few folks who didn't know it. And my question that I would leave for the next person would be, what is it like teaching new people on your team Clojure?<br/><br/>Because it was a really fun experience for us. We actually wound up building a standing meeting called Clojure Learning. it was just once a week we would all meet and just dig into it just very intentionally. So it was good for us and I'd be curious to hear people's experience building teams, Clojure teams when not everybody knows the language up front.
Artem Barmin
Yeah. Actually, we have such experience in FreshCode and most of our Cloujrian team, it's around 40 people, was not Clojurians when they started. So we have a lot of experience of switching people to the Clojure, selling inside the company, gathering kind of internal courses for them and teaching them Clojure.<br/><br/>Later on, some of them, we start hiring already experienced Clojure developers, but maybe first six or seven years, it was purely switching from other languages. And it depends on the curiosity of the person. And he's really into programming, can sit all the night. And that's a very, very important factor. He probably will be good in Clojure because at first, it requires some dedication and some efforts to learn the new concepts, especially immutable data structures. And in the past days when people switched in from Java, it was really hard to explain. Right now, it's more widely spread, the functional programming concepts, immutable data structures, even in JavaScript. But back then, it was harder. But they got it maybe in two weeks, I don't know, and started doing some real life jobs.
Jereme Corrado
Yeah, paradigm shift. I still, I find myself switching back and forth between Clojure and Python a lot for various things. And invariably, the first hour I switched back to Python, I'm always like, damn it, sort did not return this sorted. It just changes it in place. I need sorted and it's just, there's always funny paradigm shifts of getting your head around.
Vadym Kostiuk
I'm wondering about your experience of switching from Clojure to Python, because I'm in the one room with an engineer who is actually like kind of switching from Clojure to Python, and he really doesn't like it. He doesn't like programming in Python. So...
Jereme Corrado
Okay, I'll give you my take on this if you have an extra minute. So I like Python a lot. It's a very nice language. I will never love Python. And I would actually argue that the reason I like it a lot is also the reason that I would never love it. I like it a lot because of its simple… simple character. It's it's simple expressive nature. It's very clear. I used to joke with my team I'm like everybody kind of notes Python, right? Like you just sort of look at it and you're like, yeah, it says do that and that's doing that thing, you know It's just it's very accessible. There's an amazing ecosystem. It just it makes it makes easy things easy It makes hard things approachable.<br/><br/>But that's also kind of why I don't think I'll ever love it it has no to me, and I'm sure I'm going to be lambasted and beaten the next time I run into my Python friends, but it just lacks a certain elegance. And I guess I'll wrap it up and say this. Whenever I have been deeply immersed in Clojure programming and then need to go do some Python programming, I always get this sense that everything is just sort of like willy-nilly and loose and things are just leaking all over the place. And like, I can't keep tabs on it. And I'm like, what the hell's going on? Where'd this go?<br/><br/>But I will also say that there are times when I'm like very into my Python group and I'm just grinding through mutable things and I'm just slashing and chopping and I'm moving arrays in place and I'm incrementing things and it's like clear and clean and quick and dirty and easy. But it doesn't have that same elegance. And while I appreciate that quick, clean, easy, the other side of that is also the lack of assurance and clarity and comfort. I prefer the paradigms of Clojure and Lisp more generally, but Python's great. So I can understand your friend moving from one to the other and feeling like this feels like a step down. Also, the first time you go to do something with Lambda and you're like, I can only use one expression in here or one statement. You're like, this is anemic, but yeah, such is life.
Vadym Kostiuk
Jeremy, it's been a pleasure. Basically, we're at the end of the podcast and thank you very much for today's episode and for joining us. It's been truly an insightful conversation. Thank you very much for that.
Jereme Corrado
Well, thank you guys for having me. I really enjoyed it very much. Thanks.
Vadym Kostiuk
Yeah, and to our audience, if you'd like to learn more about Jeremy and his work and about Mobot, we'll be including links below this video. So yeah, please make sure to check them out.
Artem Barmin
Big thanks to our audience and see you next time on the other episodes and bye bye.
Vadym Kostiuk
Yeah, until next time. Thank you.
In the 8th episode, meet Jereme Corrado, the former CTO of Mobot and a Clojure enthusiast since 2016. Jereme shares his extensive programming journey, emphasizing the importance of software testing and the challenges and rewards of adopting Clojure and ClojureScript in product startups.
Clojure acts as a filter for hiring skilled developers genuinely interested in the language. We discussed a similar idea in the 3rd episode: when interviewing seasoned Clojure engineers, you can always learn something new. This aspect is critical in building a strong engineering team, especially in startup environments.
Jereme describes successful projects he has worked on, how Clojure popped up on his radar, and how he introduced it to the team. He also notes that ClojureScript is "Clojure's killer app," it has delivered on its promises, overcoming initial assumptions that JavaScript or TypeScript would be better choices. Listen to this episode to know why Clojure and ClojureScript matter for startups and what unique strengths and weaknesses each represents.