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

Artem Barmin

Don't you miss coding in Clojure?

Alexander Johannes

I'm always a little bit hesitant in doing change for changes sake.

Artem Barmin

Correct me if I'm wrong, but you were the person that brought Clojure into the company?<br/><br/>How can I sell these skills on the job market later on?

Alexander Johannes

I can solve all the current issues on this, but it's not the most rewarding job in a certain way.<br/><br/>The JVM was basically a main driver for our decision.<br/><br/>Everything else you need to build yourself down to cryptographic functions and what-not.<br/><br/>And that will lead to maybe Clojure being squeezed out from the company.

Artem Barmin

So how people tend to overcomplicate things in a Clojure code?

Alexander Johannes

And now you are in an open field. You have no boundaries, but you need those boundaries again, in order to do meaningful work. You end up with, I would say, a mess.

Vadym Kostiuk

To be honest, it’s the first time I hear about this advantage for the business.

Artmen Barmin

Hey everyone, welcome to the ninth episode of our podcast, “Clojure in Product. Would You Do It Again?”

Vadym Kostiuk

Today we’re excited to have Alexander Johannes from Jena, Germany, joining us. He’s a head of development and a software architect at the company called JustOn.

Artem Barmin

JustOn team automates the financial processes on the SalesForce platform. Their core product offers automated billing, invoicing, e-invoicing and accounting, worldwide and for any business model.

Vadym Kostiuk

And we have a question from our previous guest, Jereme Corado, ex-CTO at Mobot. The question passed to Alexander is the next: “Have you tried to hire people who don’t know Clojure and teach them? Please share your general experience teaching new members Clojure”.

Artem Barmin

So let’s begin map over questions and macro-expand them into the real-life Clojure experience.

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

Vadym Kostiuk 

Hello Alexander, thanks for joining us on our ninth episode of “Clojuring products. Would you do it again?”

Alexander Johannes 

Yeah, thanks, Vadym and Adam. Thanks for having me on your podcast “Clojure in Product”.

Artem Barmin 

It's great to have you here. And we can start from your experience and can you tell a bit about your background and about JustOn, the company where you work in right now.

Alexander Johannes 

Yeah, mean, I need to start way back in the beginning and way back I mean, it's like, think today, 14 years ago, we're approaching the 15th year of the company. So it's already going on for a long time with JustOn and also with me because initially I joined JustOn those many years back as a working student. And so I really was growing together with the company. And so, yeah.<br/><br/>I am intrinsically in the roof with the history of the company. Maybe I tell you a little bit about this. So my background, my personal background is I studied computer sciences here in Jena, also JustOn is located. And JustOn was founded by the current also CEO, which is Marco Flieger. And he founded the company and kind of made me his first hire.<br/><br/>And we embarked together on this journey. I mean, you see it a little bit in the background what we're doing today. We're doing Clojure and we're doing like invoicing, payment and plannings and accounting stuff. But it was really a long way to arrive there. So what did we do in the beginning? We took a look at the Salesforce platform, so the Salesforce platform is a CRM in the first place. And we figured out that we can build software on top of the Salesforce platform. So they have like their own ecosystem and they allow you to kind of build custom software products on top of their platform. And this is like a very, I would say low code approach because they have like many things figured out for you. So you do not need to do like security. You do not need to do databases and stuff like that.<br/><br/>You're just using their frameworks, building software on their platform, interfacing with their data model. And then you're able to quickly craft a solution for the customers. And the first thing that we did on this SalesForce platform was the billing module for occurrence of first tech. So this was the first thing which we were doing. And then we were growing from there. So we acquired customers for that and built a lot of more modules to the billing system, like dining, like payment, like accounting stuff, and accrue the company from there. And this took us about, like, I would say, five to six years. So it was like five to six years, really crunch time, building on a custom platform, building in a niche. So because this is a topic for Clojure, I would guess that it's always like building in a niche, trying to attract developers for the things you're doing. You're a small company. You're trying to find developers who are willing to work for a small company. You're trying to find developers who are willing to do work in, I would say, a closed ecosystem with not so many references, with maybe not a clear career path, because when I'm learning all the custom Salesforce stuff. What does it do any good for my career? What do I gain from this? Where do I develop myself as a developer? And that's like an issue we had like the day one in what we're doing because we are on a closed ecosystem. <br/><br/>Fast forward a couple of years, when we now take a look at what we have done on the platform, we kind of max it out. So we really came to the boundaries of the Salesforce platform with what we are doing. And our development team was asking, OK, what can we do here? So how can we build some new features the customers are requiring, which are basically impossible to do on the native platform? And that's where our idea, our first idea came from, building our own platform. It was not the seed for using Clojure as the main language for this, but it was like, let's think about this. Let's try to figure out what we want to do. How do we embark from our current position into this new journey? How do we figure out what we want to do? Where do we want to do this? How do we integrate it with what we have already done? Stuff like that. <br/><br/>And it was then like the exciting part, which started around about, I would say four years ago or five years now. Losing a little bit of track of time. But yeah. And then we kind of started our personal journey in terms of getting to know Clojure and yeah, doing something with Clojure.

Artem Barmin

Correct me if I'm wrong, but you were the person that brought Clojure into the company.

Alexander Johannes 

Not entirely. during our Salesforce only days, we already had one developer on board and he was toying around as a hobbyist with Clojure. And then we needed something for the Salesforce platform. They have very limited tooling and we were experienced some issues with writing proper tests for the platform. And he was able to use Clojure in order to create a mockup classes for real classes. And so we had now like the small seed, a Clojure project, which was able to create from this proprietary language on Salesforce, which is called Apex. It's like Java, a little bit Java like. And he was able to kind of build a parser and read in this source code and spit out a ready-made file, which we can then could use for testing purposes. And we use it a lot. We're still using this little project. And this was so to say a deceit for everything Clojure in Juston. <br/><br/>So it was just coming from a hobbyist approach and something like, okay, I'm interested in this. This is a cool problem. Also like I'm rooted in a little bit of computer science. So like building parsers, building all this cool stuff and being able to do this in Clojure. And so this was the seed for everything which we're doing with Clojure right now or today.

Artem Barmin

Interesting, very interesting. And can you tell, is this project was your first encounter with Clojure or you had experience before?

Alexander Johannes

I personally did not have any experience with Clojure before. So my developer here, yeah, he had experience, little bit more experience with Clojure, but it was all on a hobbyist level. So we were not like doing a professional product with Clojure or anything, or we have never had someone who has worked in a different company, which who are using Clojure in a productive environment or something like this.<br/><br/>And he was really influenced by the talks of Fratiky for instance. And also he was like finding, I would say like a ball for something like this in order to do something else besides the normal Salesforce ecosystem, which we were coding in. Because when you're doing software development on such a proprietary platform, and you're maxing it out, you're reaching the boundaries of this, this makes it pretty creative, but it also shows you day in, day out, all the, all the deficits of the platforms or things you cannot do, things which force you to write maybe unnecessary boilerplate code, stuff like that, where you just say, okay, it's okay, I can solve all the current issues on this, but it's not the most rewarding job in a certain way.<br/><br/>And so that was maybe his main driver to kind of introduce stuff like that and not say, okay, yeah, we can do it in Python or we can do it in Java or whatever. But he really shows something which kind of also satisfied his curiosity here. And then he introduced it back to the team. I had a little bit of experience with functional programming. was doing a lot of stuff in Haskell back in the day. And so, yeah. They are not the same, a little bit similar from concepts and stuff like that, the functional patterns. But yeah, syntax is way different and also some kind of things how you do software development or how you do certain aspects in Haskell are quite different than you're doing it in Clojure. And so that was the seed for what we were doing.

Vadym Kostiuk

I’m wondering, so have you had any concerns or maybe challenges you anticipated because of Clojure, specifically because of Clojure at that early days?

Alexander Johannes

I mean, the thing is, once we decided to kind of build our own platform, we did a lot of prototyping. So we kind of said, OK, when we would like to do this, we have a certain set of requirements, what the platform must do. And also, we as developers have certain requirements in order to be more happy in what we are doing. So, different set of requirements, but still, pretty valid, I would say. <br/><br/>And so the first thing which we were doing were like programming challenges. So we had our requirements, then we thought about a certain problem we would like to solve in a prototype. And then each and every developer got a different programming language. So one was using Python, one was using Clojure, one was using Java. Then we had Scala, we also like toyed around with Scala, for instance. And then we tried to solve this issue. All not very experienced in those other programming languages. But anyways, let's do this. Let's see how this feels, how approachable is the documentation, how approachable is the community for the particular programming language. How easy was it to grasp the concepts? How easy was it to write the code? How easy was it to write the tests? Stuff like that. <br/><br/>And then we kind of put it all together and then we gave like points in the end in order to see, okay, yeah, this is cool with Python, but this is not so cool with Python, for instance. This is working in Clojure, but this is like a downside of Clojure. Then we tried to make an “informed decision” – You can never make informed decisions on basis of something like this. But we, as a development team, felt a lot better about this, having not only looked at one language and said, OK, seems to be legit, let's go with this. But we really took a deep look in our ecosystems and other languages as well in order to see, OK, maybe this is a good fit. The last language I forgot was Go so over touring around with Go, which was like very hip during the days.<br/><br/>And then we arrived at the decision, at the decision point. And yeah, you know, one of the main driving factors for choosing Clojure was then, okay, we have one person who's mightily experienced in Clojure. So he knows his way around. He followed the ecosystem. He is able to teach the rest of us. So that was the first decision factor. And that was better than the other languages because we had no patent expert. We also had no go expert in the, in the team. And so this was like a driving factor. <br/><br/>The next factor was, it's running on the, on the JVM. So that was a main decision factor for us because it always was like, okay, even if we decide to ditch Clojure in the future, we still have the other platforms or everything which we're doing integration wise and so on does not need to be rebuilt if we decide that the language is not right for our problems, we will need to solve on that. And so the JVM was basically a main driver for our decision. Also, when you take a look at the whole ecosystem, you can think about Java what you want, but you have a ton of libraries out there, a ton of support for even esoteric use cases, and you have a great interop between Clojure and Java. And so it was like a no-brainer, especially when you take a look at younger programming languages like Go. You know, prospectifies when you're doing software development on a closed ecosystem like Salesforce, basically you get what you, or you can use what you get from them, but that's about it. Everything else you need to build yourself down to cryptographic functions and whatnot. <br/><br/>So it was like opening a whole world for us to say, okay, we don't need to build everything from scratch, which is not supported by the original platform. You can just go down hunting. Okay. Is there like a good library with a good reputation, with a good track record, which you can just bring into your system as a dependency. So we had basically on Salesforce, or we're having basically on Salesforce zero dependencies, which is very unusual for big projects.<br/><br/>And we're still hesitant to bring in dependencies in our Clojure system or in our Clojure platform. But it opened up the possibilities to do stuff like that. And that was like a game changer for us in order to kind of be better in your time management, be faster, and deliver something. So that was a huge driver for us as well in order to select Clojure as a language for the platform. <br/><br/>From there, it goes like always, you start with a small team and you're doing something new. And basically you don't know what you're doing because yeah, on the one hand, you have specific problems to solve. So you have like a specific scenario. So we had like our existing software stack. We said, okay, what we would like to do is on the Clojure platform at first, we would like to build functionality there, which is impossible on the main product. We needed to figure out how to interface with both. Also, in our specific case, we are building the software on the platform and it's a software as a service. So we had like a multi-tenant architecture running on Salesforce. How to do this in a proper way, how to separate all your customers on your single platform, stuff like that. Prototyping and then architectural discussions and decisions to be made in the first place in order to see how can we use this? What is the best way to use this? Which is very complicated in the beginning. <br/><br/>I mean, when you take a look at this, the first thing is you come from a close context where you know your boundaries and the boundaries make you creative in order to achieve the thing you would like to achieve. And now you are in like, like on an open field. You have no boundaries, but you need those boundaries again, in order to do meaningful work. <br/><br/>I would say in the beginning for me, a very stressful time because it was like, yeah, we couldn't do it like this. We can do it like that. But maybe this is a better way. And you know, once you decide and make a decision, let's do it like this, then you kill a lot of options. And then the thinking goes, okay, have I killed the wrong options? Or have I decided for the right thing? Does this hold for the foreseeable future? Can I solve the problems I have in five years on this platform if I'm now making this decision? So this was a very stressful time for me back in the day. But anyways, you need to decide in order to move on with stuff. And some decisions were not very clever and we needed to rectify them later. So for instance, to give you a practical example.<br/><br/>When you have your, your, whole users are working on Salesforce and they have only the Salesforce user interface and they have the data in Salesforce. And the beginning we made like the decision, okay, it's cool to have like a Postgres database. And then we were like toying around. So how do we do this? Do we know fetch the data from Salesforce, put it in the local Postgres database, do processing on top of this, and then put it back there. It's like a data protection nightmare in the end. It's like… It seems to be cool because now you have like a full-fledged database. Maybe you can do stuff not only in code, you can do it with like proper as a circle queries or whatever, SQL queries, whatever. But in the end, was like a wrong decision to kind of trying to put data in your platform. Just leave it where it is, fetch it for processing, push it back to the system. Stuff like that we needed to figure out and sometimes learn it as we developed features in order to see what's the best fit. We were like building our own new platform and we were really on our own in my perspective or from my perspective. So there was not so much reference material out there which could be used as blueprint. So where you can say, okay, okay, someone did it like this. As if it's exactly our use case, let's do it the same way. This was never the case for us. We read resources, but we only could use bits and pieces in order to figure out what to do exactly. <br/><br/>That's one with regard to platform building, but on the other hand, also like the Clojure project structuring. So how do you set up a Clojure project which will become huge? You already know this because the company is going well. You're building a lot of features in there. You have a roadmap which can feed the team for the next 10 years or something like this. How do you build the code? How do you structure your Clojure project so that it fits the bill? Zero experience there in the beginning. 

Artem Barmin

Can you maybe name some challenges specific to Clojure? Because you told about this decision about Postgres and two-way synchronization of databases, but that's more about, you know, architectural decision. It was quite hard to navigate the ecosystem and to understand the best practices, how you should structure the project, what libraries should you use and that's a good part and also the bad part of the Clojure that you can use snippets, not libraries. <br/><br/>For example, yesterday I found the gist on GitHub and I just put it in my project and it worked. So that's not even a library or something like this. That's not even a repository, but it works. And maybe you have, maybe you name this one challenge that you faced for the five years of development?

Alexander Johannes

I think the first big question for us was really how to structure the project. So what to put in which namespace to make it really, really plant here because you have like infrastructure, you have business logic, you have side effects, have interfaces to other systems, stuff like that. So we really weren't able to find a good project template for this. So how do you structure your Clojure project? This is an essential question in my opinion. <br/><br/>And we kind of came up with a structure. And then we had like a rushing phase where we implemented a lot on the platform. And in the end, we figured out, how have the developers also some new hires, some developers who were not so experienced in Clojure were understanding it wrong and putting the code all over the place. So you started with the best intentions and then you end up with like, I would say a mess and you need to kind of find a solution for this thing. And so that was like a hard challenge. <br/><br/>It's still like a challenge for us and still a source of lot of discussion in the dev team, in the current dev team, how to structure this, how to do this in a proper way, because you need to think about testability, maintainability, and so on, and also reusability of the code. And this is something which is really hard and which is nobody, in my opinion, teaching right at the moment, especially when you're just looking at snippets and gists and stuff like that. They don't teach you that. They don't tell you how to build a big project with a lot of different concerns, a lot of different modules and so on. <br/><br/>So this is something which is missing in my opinion or was missing back in the day because I mean, once you figure this out and you have like a clear plan also to kind of rework the old code and then to do it better, then you never look left or right because then you have your own plan and you don't go hunting down is there any template for us? So that doesn't make sense in a way. But that would be really helpful in the beginning to kind of, what is it? I would say, what is the enterprise architecture for Clojure? Something like this.

Artem Barmin

Aha, very interesting.

Vadym Kostiuk

And where have you found your answer? Just try it and gain the knowledge or ask someone.

Alexander Johannes

In my opinion, too much discussion with the team because it takes a lot of time in order to come to a common ground and then to do the right thing. Yeah, that's basically the answer to that. <br/><br/>The second concern is, I would say with regard to testing, especially in our case, we always have a concern which is on different platforms. So we always have code which is interfacing with a different platform, in that case Salesforce. This is always our concern, cross-platform code. And this is something which we have not been able to solve with pure Clojure because, yeah, you need to mock everything which is not in your direct reach. But we have figured out to do, like, I would say system tests, which are able to spin up like a system on Salesforce and then doing like end to end testing, which was also a huge pain point in the beginning, but we figured it out how to do this properly. You cannot run those tests all this time, but there's a way to automate and really see if what you have built is really, is really running. But that's more or less like maybe a problem of our architecture and how we need to build our software and not so much a problem of Clojure.<br/><br/>Pure Clojure testing or pure testing in Clojure without any side effects would not be practical for us. Or it's not practical for us.

Vadym Kostiuk

I see. it's always wondering me to ask about the team behind every product. But to start with, I'd to ask, what are your role and responsibilities as a head of development at JustOn? And if you could tell us how personally you are involved in the coding process day to day.

Alexander Johannes

Originally I was a software developer here at JustOn. So I doing all the development together with a small team on the Salesforce platform. And yeah, was basically heading the development team there. And once we built the larger team, my role changed. That's for sure.<br/><br/>I remember one day very lively where I said, okay, I quit my old job and I starting a new one because I need to kind of no longer concentrate on coding and I need to concentrate on different things. When you take a look at my day-to-day business or what I do from day to day, would say 50 % of my work is motivation. So really talking to people, see where they are struggling with helping them with the job in order to do a good thing. And 50 % is currently coming up with good business requirements. <br/><br/>So I'm really deep into writing down stuff that should be built in the software from a business user perspective. And this is sometimes like months ahead of development. So I'm really like strategizing on how to make our products better and what we need to do in the products. And I'm not doing it like only from a business perspective but I'm doing it really like I would say virtually integrated. <br/><br/>So for instance, a hot topic right now in our industry is e-invoicing. So it's all over the place. So there are regulations all in Europe to kind of force everyone to use e-invoices, to send them, to receive them, stuff like that. And I'm currently working with an e-invoice provider in order to figure out how to integrate their system. And what I'm doing is I'm describing it from the business user perspective, but I'm also toying around with Postman in order to figure out their API, see how their API is behaving and talking to their support team in order to figure out if we have understood it right in order to prepare our development team to implement it correctly in the first place and to give them like a head start. And so that's basically my role day in, day out to, yeah, move things forward here.<br/><br/>I'm still a little bit concerned with or a little bit involved in architectural concerns, but most of it is currently delegated from my perspective. But still, yeah, for some, I would say things which are very hard to achieve or where we need a lot of discussion, I'm always brought in by the team. So that's basically describing what I'm doing currently day in, day out. And this is something where you're as a developer can evolve to. So it was not like a role which was given by anyone to me, but this was where I was needed most or where I'm currently needed most in the company in order to do the best work here. 

Vadym Kostiuk

It's actually very common for engineers who who move from engineer to head of engineering or to VP of engineering to CTO when you have to like leave your day-to-day code and do some more organizational-level stuff and strategic level stuff and also people questions within the team. So it's very common. Most of our speakers who has been in to our podcasts, they mentioned the same thing.

Alexander Johannes

And I think the only important thing here is that you for yourself make this decision, okay, I'm no longer a developer. This was very important for me to kind of set a cutting point and say, okay, I still could write code and I could still like participate in what you are doing as developers day in, day out. But it kind of blocks me from doing this other stuff, which is also needed. And it's way more needed than my small contributions to the code base.<br/><br/>You need to like flip a switch here in order to make it real also for the others, because it's not only for my mindset, it's also for the mindset of everyone else who's working in the company. Okay. This person is in a new role and we can approach this person on a different level or with different questions and different concerns. That's very important.

Artem Barmin

Don't you miss coding in Clojure?

Alexander Johannes

Yeah, for sure. But, not so much because, you know, I was, I was like writing code for so, so long time and, coding is not at all fun. not, everything in coding is fun. Maybe to, put it like this, because, yeah, there are the funny parts where you're coming up with a cool solution where you kind of find something, which really satisfies you. But there's also, typically this grind of coding. like coming up with software tests and all the boring stuff, also is coding. And yeah, so I miss the creative part, but I don't miss the grind from coding. That's true.

Artem Barmin

I see. Why I asked? Because a lot of people that are in positions of CTOs, head of engineering, VP of engineering are still doing coding in Clojure because just they like it. They hear the stories a lot.

Alexander Johannes 

I have not so much on my side right now, but this also is like, yeah, you have only so much time. I mean, we have a lot of products and, but in the end we have like 25 to 30 people here. And you really need to see who can do what and where it is needed best. So it would be like a luxury for me to kind of pick up a ticket from the board and do the small implementation. So to really be a luxury right now. So that would then delegate the coding to like private endeavors. So like doing it in my free time, but you know, I have a family, not so much coding in the free time either.

Artem Barmin

Yeah, I see. And another question about team that we always ask, it's about scaling your engineering team. How do you find right people that can match your culture, your technical stack? Because sometimes people are hesitating to switch into Clojure because it's not very popular on the market. And as you said about Salesforce, “How can I sell these skills on the job market later on? Will it increase my salary or not?” And I'm curious how do you find the right people?

Alexander Johannes

We already had this problem when we were a Salesforce-only company. So you're in a niche market, how do you attract people? It was, for the Salesforce technology stack, it's way harder to find developers than for Clojure. So that's our experience at first. So I would say on the ratio from one to five or one to ten, so you're getting like an application from one Salesforce developer and from five to 10 Clojure developers, not necessarily experienced Clojure developers. So we need to differentiate a little bit, but from people who are eager to try this out either, or are fed up with their current way of doing coding. So the most arguments I hear in all those hiring processes always like, don't want to manage my state. I want, I'm curious about, yeah, the functional part of development. I'm already doing it in my current job with the current language, but it's not so much a good support and stuff like that. And that are the most arguments I'm hearing.<br/><br/>Yeah, we have like a healthy mix now in our team. So people who had no experience with functional programming. So basically we trained them in order to become Clojure developers. We also have like, I would say, side tracks or whatever. So one person for instance, was I think coding in Elixir or something like this, and was then like the move over to Clojure and stuff like that. So it's like a, like a healthy mix right now where people are novices in Clojure, but eager to learn and they have an intrinsic motivation to learn Clojure or to do something in Clojure. <br/><br/>This doesn't necessarily translate to good code or something like this, because that's then something of a different level where you really need to take care within the team to kind of train everyone, to make the right decisions and to adhere to the standards which we have set so that it is acceptable what they are doing. But from what we have seen here is when you hire someone who has no prior experience in functional programming or in Clojure, the person's most often need like half a year in order to come to an acceptable performance, I would say. And like another year in order to come to a decent performance where you don't need that much hand holding anymore and get like decent results. Maybe with regard to the other part of the question, I mean, we're sitting in Germany and we have no people sitting currently in other countries. So we have no secret Clojure development team and some like, like, she wages country or whatever. So, you're really forced to find people who are the first place also located in Germany are available and are willing to do this. And, Clojure helps in a way because it's attractive for, for a certain kind of persons. It's attractive and, and they would like to, to work with us. and so this.<br/><br/>It is going well up until today. So if I want to hire some Clojure developer, then I am positive that I can find someone who is willing to do this and hopefully fits the bill in the end. Yeah, but we are, we have experimented with persons in different countries, but it's only going so well because of maybe cultural differences also in terms of like, they are always like only visible on the screen. They are not real persons in the room, especially when you have a core development team, which is always together, which is always here in the office. They're working together. You can just stand up, go over to the next desk, talk to your colleague, think about the problem. This is, this is really good here. And so this forces us to hire locally because we want to keep the spirit alive and really bring the team together also in terms of real contacts and not doing so much remote work.

Artem Barmin

Having people in the same place are very important part of effective work, especially in Clojure, from what I've seen. That's why sometimes we, you know, not work on person-based, but we build teams for another companies and we work as a team and we just deliver the results.<br/><br/>I'm curious to hear your opinion and your experience. You've mentioned already the freedom that gives Clojure and its ecosystem, Java ecosystem, and with combination of the people that are not really familiar with Clojure. So you basically build team from ground up. Sometimes this mix gives a lot of strange technical decisions, over-engineering. When people first time see the macros, they want to use it everywhere. They want to use to build the main specific languages and such kind of things. And we faced this several times and this parts of the system requires refactoring. Can you tell a bit more about your experience? Have you faced over-engineering on some or some strange technical decisions?

Alexander Johannes

Yeah, definitely. So we already have like a lot of, lot of legacy code. So you would never build this again in that same fashion. But I think it's true for every software project because you're always gaining experience. And my old joke in the Salesforce days was like, had my code I wrote like two weeks ago and yeah, that that's, that's true in a certain, in a certain way, guess. So the question is, can you live with it? Because what I always tell to my developers at first is, we need to change it because it earns money? Why do we need to change it just for the sake of changing it? Or because we need to change it in order to make it better integratable with a new feature, we need to expand it or whatever. And so I'm always a little bit hesitant in doing change for changes sake. So that's the first thing. Let’s touch this only if we need to touch this and then do it right. So that's the first thing. <br/><br/>But yeah, of course we have done a lot of weird stuff in the system where you kind of scratch at and think about it. So why did we do it like this? And why did we make this decision here? And sometimes it's just, most often it's just lack of experience or in some rare cases also like we rushed things because when you're rushing things and then you're getting something which you could also call a prototype but later on it will bite you and then you need to rework it or accept that it is just a better prototype and that it should never have been put into production or something like this but it's like always you need to to kind of find a proper balance for doing things right and bringing things out to the customer. <br/><br/>We are not so much building against tight deadlines here, but still we would like to have a proper pace of new functionality in the software in order to make the customers happy, also like bug fixes and stuff like that. And you always need to kind of make decision, how much time do I have for putting in a certain thing into the software. And then you need to also bring the software out to the customer. So the customers are the last instance who decide, is this workable or is this not workable? Not the developer decides, okay, it's looking nice to me or it's not looking so nice to me. I need to refactor it once again in order to make it looking nicer. So this is like waste of time. <br/><br/>Then I need to kind of embark a little bit on the route on development processes here, because in my experience, you need to build it into your development process to enable the developers to do good work. And this is something which we are intensively working right now on to kind of give the developers ample of time in order to figure out how to do this technically. So they're getting like the business requirements. So this is what we want from a business side in the software. They're getting the business requirements and now their task is not writing code. Their task is maybe doing prototypes and doing a deep technical analysis of the existing code in order to figure out what do we need to do exactly in order to make this thing happen? Do we have something already in the software? Do we need to refactor something? Do we need to rewrite something in order to make this work? <br/><br/>And this is something which eventually become proper technical requirements. And we really have like a document which shows the developers, okay, how do you write proper technical requirements for what you're trying to do? And once they have proper technical requirements, then they are allowed to implement this stuff. So the whole thing is like catch things early in order to make it better. So catch them as early as possible in order to see, we have like an underlying issue. have added effort on something and this needs to be discussed because this has a direct influence on how fast can we deliver this feature, also it has an influence on the roadmap. So how many features can deliver? And so we try to catch everything as early as possible in the process by thinking hard about this, by doing prototyping stuff like that, and then doing proper implementation and bring it into the system. And that maybe also answers your other question. Yeah, we are rectifying our issues or our mistakes from the past one by one but it will take a long time until we are getting there. And the question is, is it worth it?

Artem Barmin

Yeah, you know, actually I'm curious about some patterns that you maybe noticed. So how people tend to overcomplicate things in a Clojure code. So maybe some common things and...

Alexander Johannes

The most common pattern here is not being pure functional. So, I mean, that's maybe something which can be attributed to their inexperience in functional programming. But I've seen this a lot in the Clojure code from the beginning that you either have a big let statement and it's like imperative programming. It's pretty funny. Or that you have like, side effects all over the place. Deep down in some business logic, you have a side effect. You're calling the database, you're calling out to, to a different platform. <br/><br/>And, this is something you can do wrong in every programming language, but Clojure is not immune to that. So, just when you say I'm a functional programming language, nobody's forced to, to program in a functional style in Clojure. And that's something you need to discuss with your team and to teach each and everyone and to doing it over and over again in order to get the patterns in the head, in order to get the thinking, how do I do this? How to approach this particular issue? And how do I structure the code in order to make it more functional? So that's the real challenge for Clojure.

Artem Barmin 

Actually, we have this exact question from one of our previous guests. And I'm curious, an you describe the best practices of separating side effects from the pure code? Because sometimes they can be interconnected. But as I understand from your experience, you had experience with Haskell, which has pretty good separation of I own monad and everything else is pure and it's very easy to make this array, the code base very pure in functional things. But how do you teach people to do this in your team?

Alexander Johannes

The cool thing is that we are equally forced on the Salesforce platform as also on our Clojure platform to take this into consideration. know, most of our business logic is like built for mass producing stuff. So it always runs on a huge number of records and the best approach for this is like push side effects to the boundaries. So push everything with regard to data acquirer, for instance, to the beginning. So keep it out of the business logic, put it to the beginning, collect the data, everything, and then put it into the pure functional business functionality. Also everything which needs to be happen after that. like, data persistence, calling out to different systems, push it to the other boundary, push it to the, to, so, to push everything out. <br/><br/>So this is, this is like a good pattern in our opinion and really helps you to, kind of clean your code from side effects. Because when you're thinking about it like this, then you don't need to make the single call to the database in some, some for loop or whatever. You need to push it out and make it at the beginning and thinking about what do I do with it if I have like a thousand of records and I need to make it work on a thousand thousands of records. And that's basically the key to structure the code better and starting on this functional journey because then your business logic is basically pure and pristine and that without any side effects.

Artem Barmin

Can you share, have you gained this understanding from Haskell about this clear separation?

Alexander Johannes 

Not so much. Maybe you will love about this, but, this is also imposed to you by, by, would say, regulations of Salesforce. So they have, this is like insane. So they have like their platform and it's really like, not performing Dell. So they have imposed some limits on their platform. So your code must only run for 10 seconds. You can only do like, 100 database queries, stuff like that. <br/><br/>And this really forces you to think about this and to come to such patterns. And they are basically the same, which also are beneficial in Clojure. So it's like, like experience gained on a limited platform. So it was not so much influenced by the other stuff, but yeah, you learn it the hard way. And back in the day, when we built the billing module, yeah, just create one single invoice, but then we the customer was in like the delivery, a restaurant delivery business. And they were doing like millions of orders on the Salesforce platform. And then you're like forced to, kind of come up with solutions who really perform even on this poor platform. And then you arrive at such patterns and they are good to influence also the Clojure code. They are still hold true and they are still very useful.<br/><br/>Like a funny, funny way of arriving there. but it's like hard, hard earned knowledge. It's not like, okay, I learned it in the university and some kind of test bed or whatever. it's like really hard learned lessons there.

Artem Barmin

Always works well.

Alexander Johannes 

Yeah, yeah, that's the best.

Vadym Kostiuk 

We have seen a few times that Clojure was squeezed out of the code base on different products and different projects. And often it was more like a political decision rather than a technical need for moving forward from Clojure. And in some cases, because of the acquisition of the company, so the company been sold to another company. And then, you know, like if it was a Java shop, they just wanted to distribute Java across all the products. Sometimes because the lead engineer left a team and it was hard to find a substitution. And sometimes just to actually, because of the external pushes from investors. And I just want to hear your opinion. What do you think, are the key top business and technical reasons that might lead moving forward, like moving away actually from Clojure? What those top reasons in your opinion?

Alexander Johannes

I only know our company, so it's not venture capital backed or whatever. So basically we can do whatever we like. And so we are doing Clojure because we can do whatever we like. So that's a plus for us. But when I think about this, mean, the key thing here is are here key people. So if you are able to kind of hold your key persons who are driving this topic who are really invested in this, who are interested in this topic and can also motivate other people, then it's working well. But if for some reasons you're losing those people, yeah, then maybe you need to do this, this kind of business decision because when you, for instance, need to let go your, your lead Clojure developer and the rest of your developers are only like, like, yeah, you know, developers then maybe it's not going well in the future for your product because they don't know what they are doing and they don't have like a proper lead or something like this. So maybe the best way is to retain your talent in the first place. <br/><br/>Yeah, in terms of being bought by a different firm or when development teams are put together from different cultures and so on, yeah, then it's like a war and someone is winning there and maybe Clojure is not fighting enough or the team which is using Clojure is not fighting enough. But yeah, this can happen. <br/><br/>I don't think it's like about the practicality or the usefulness of Clojure. It's like always political decisions or decisions because of circumstances. And that will lead to maybe Clojure being squeezed out from the company. I mean, it's also like a concern for us to hold our talent here. So we need to find a way to make our developers happy. So they need to be happy day in, day out doing this stuff with Clojure. Otherwise, yeah, we could need to do something else. And so this is what we need to figure out here, what we are figuring out day in, day out to go with the development team, how to make them happy.

Vadym Kostiuk 

That's interesting response. Comparing to the other languages, Clojure been stable for years. There were no major releases, updates, and changes to the core language. And from your experience, do you find it more like a benefit or a drawback for the ecosystem?

Alexander Johannes

I like it a lot to be honest, because yeah, the stability is always good because you know what you can expect. Take a look at the JavaScript ecosystem where you kind of have a new library and a new FET every two months. And so who can keep up with that? So I would like to build a stable product here. I would like to maintain this stuff for the foreseeable future. So we are already in like four years on the Clojure platform and doing it day in day out we're building a ton of stuff on that. So every unwanted change or every introduction of changes where we need to also change our staff is impractical for us because I need to allot time to this. I need to allot resources to this. So the more stability, the better. So I really like this approach.

Artem Barmin

Maybe you can name some specific advantages that make Clojure a competitive choice in 2024.

Alexander Johannes

In 2024, that's a good question because I only know my own little terfium. So that's a little bit hard to answer because I mean, to be honest, we also have talked about this at in past, we still have this problem that we don't have many companies who are really doing this on large projects and doing this really in production. So the overall I would say professional Clojure projects is rather low. That also means that we don't have so many experienced developers out there. The biggest issue for the Clojure ecosystem also in 2024, but it was also back then four years ago or five years ago. <br/><br/>How do you attract enough talent and how do you educate enough people and how do you also develop enough people to become real professionals in there, to become seniors in there in order to spread the knowledge, in order to train more persons, in order to train juniors, in order to better software developers in Clojure. So that's like the issue we are still facing in 2024 in my opinion. So as I said before, we can only, from my perspective, as a company in Germany, we are currently hiring Clojure developers who are either like juniors or have never done Clojure but have a high interest in this software. So I would like to see the first senior Clojure developer from outside here not developed in their own company. So that would be very nice for me. They are not out there in huge numbers. And I bet they can select the jobs they would like to choose and work for whoever they want.

Artem Barmin

Have you ever hired a senior Clojure developer from outside? No? That's really interesting.

Alexander Johannes

Nope. It's basically impossible. I wouldn't know how to do this right now.

Artem Barmin

Yeah, yeah, I can totally understand. We have hired because exists, you know, some companies that produce a lot of experienced engineers and we can hire people from them. But I wouldn't say that's an easy task. Yeah.

Alexander Johannes

Yeah, that's for sure. They have hired like senior developers, so they have like a senior status, for instance, on Java or whatever. And they are now becoming Clojure developers, but being a senior Java developer doesn't make you a senior Clojure developer. It's impossible. They have the right mindset and they are faster in learning and seeing patterns easier and stuff like that. So that's really helpful. But they're still on the learning path for Clojure.

Artem Barmin

The last question actually in the whole blog of the podcast, given all these thoughts, all the information that you've told us, your experience, would you choose Clojure as a main technical stack for your products in 2024?

Alexander Johannes 

Hmm. That's a tough one. I would say yes, because we know how it feels to be an underdog. So we're doing it from the beginning to be kind of in a niche. And so I would do it again. Yes. Because being an underdog also makes you not so competitive on the overall job market. <br/><br/>So if I would now doing like Java, for instance, so I'm building a Java platform. Yeah, maybe there are a ton of Java developers out there, but am I attractive for them as a company? Am I doing stuff which they really would like to do? Because in the end, yeah, it's like boring business software. It's like data transformation stuff, whatever. it's like from the outside, it seems to be boring. But now when I'm bringing in like Clojure or when I'm bringing Clojure to the table as a company, I'm attractive again for a certain part of the developers out there. then this makes it easy for me as a small company, as an underdog, so to say, to kind of still get like some attractive candidates in order to choose from them. So from a hiring perspective, the decision for Clojure is pretty much on spot. So that's really working out for us. Otherwise I wouldn't have had the ability to grow the team as I have grown the team. So that is a good thing. <br/><br/>From a technical standpoint, would say as long as it makes the developers happy so that they can do something which they are like and which really is making them happy day in, day out and keeping them happy. I think Clojure is a good compromise for that.

Artem Barmin 

Very interesting perspective about hiring talents. I sometimes hear this thesis that Clojure can work as a filter and it filters people who are really passionate about programming and learning new stuff. And right now you said this can be a competitive advantage to attract really experienced people to work on your platform. And that's really new for me. Thank you.

Alexander Johannes

Yeah. You really get people who are more interested in what they are doing. They're not just developers like nine to five or something like this. They really burn for something. So that is a good thing. Yeah.

Vadym Kostiuk

To be honest, the first time I hear about disadvantage for the business, that's really the first time. It's an interesting point of view. I mean, that Clojure helps actually, it is attracting people and to hire people that's... Well, thanks. That's interesting.

Alexander Johannes

Yeah, at least it's our experience and our small little niche here in Germany. So I can only speak for us. and then what our experience here is and I mean, yeah, that's working out well for us.<br/><br/>What also helps is like giving developers a perspective. So we are a product development company. So most or many of the developer jobs out there are just for like, I would say short work. being in a project on the customer side, doing something for a couple of weeks or a couple of months, and then going over to the next project.<br/><br/>And we are having here a perspective. So when I talk to someone who is willing to work for JustOn, I can say, OK, we're doing this like 14 years. And we know what we’re doing. We're building products. And we are maintaining products for such a long time. And then we are growing our user base and our customer base with those products. And that's really helpful also for a lot of our developers, because they know the pressure in such short-lived projects where you need to deliver stuff, where you have like a tight schedule and you maybe need to make more compromises in your work because you need to rush to the job or you need to finish the job. So in our specific case, it's like a bonus that we are maintaining this over a long time that you kind of can pick up the code you have worked on three years ago and improve the code you have worked on three years ago. This is something which not every developer is able to do or can do. And this is like giving someone a perspective and then giving someone like the ability to think in more prolonged cycles and then to thinking long-term. And this is something which is also sometimes very attractive for people who have been burned in the normal consulting business.<br/><br/>You are more or less in consulting business with FreshCode. And so yeah, it's like a different different perspective. That's that's really the case.

Vadym Kostiuk

Yeah, perspective works both ways, I guess. For some people, when they are working on one project for four years or three years, they would like to try out something new because they get tired of working with the same technology, with the same people, and they would like to maybe to try out, test out some new domain, some new approaches for the development or even new technologies. You're right, you're right. It works both ways. <br/><br/>And we've come to the point actually of our podcast where we'd like to ask you a question passed to you from our previous guest. So on the previous podcast, Jereme Corado, he is a ex-CTO at the company called Mobot. He left you a question to which you partially or already provided the response actually. So the question is, “Have you actually tried to hire people who don't know Clojure and teach them? And what is your experience teaching new members Clojure?”

Alexander Johannes

So the first thing is, yeah, they need to contact us. So if they are interested in Clojure, they are contacting us. So we don't go out there and say, okay, we have Clojure job. So they need to find us at first and have a certain interest in Clojure. And once they are on the job and have basically no Clojure experience, it's like a really tough time for them. So we have like internal, internal training program. So when you're starting here, you are getting like a colleague who is experienced in Clojure and you're doing it like in tandem. So you're starting to read code. You're starting to do some kind of training. There are also some kind of training courses which you can take in order to speed yourself up. <br/><br/>But the most important thing is to learn Clojure is to read Clojure code. And we always encourage new persons are coming to the team to kind of read the code. So kind of see what is currently produced, which stories are currently being built in Clojure, starting to read the code, starting to understand what has been built there, and then also ask the questions. So we're doing a lot of code review. We're doing also a lot of retro's here, we're doing like an internal sessions, is called a hands-on development where we kind of share cool patterns, which we are currently using swathes of a development process, stuff like that. And then we are taking them on the learning journey. <br/><br/>And they are really fast also starting to build their first Clojure code. So like small feature, bug fix, whatever, in order to kind of getting their hands dirty on actual real problems. We don't want to have this like a synthetic thing where they kind of doing training for half a year. They really should jump in head first and doing their first work in this and like receiving proper feedback from the more experienced developers. And that's working well. <br/><br/>So for instance, we have one developer here. He was studying as a working student. And as a working student, he was learning Clojure first and now it's his main language. And eventually when he was graduating, we hired him as a full-time employee. He's still doing Clojure development.  He was like learning it basically at his first professional language. So this is pretty, pretty wild because almost every other person was learning like Java or whatever in their first job. For him it was Clojure. It's pretty cool.

Artem Barmin

Yeah, we also had such cases in our history because we started as a Clojure product. Later on, we switched to the agency model because our products didn't fire well and because we didn't have experience in marketing. But we have a lot of people that learned, it was their first language and they're still working in a company for 10 years and still doing Clojure. So that's...

Alexander Johannes

And I think this speaks for Clojure. So this really speaks for Clojure that people don't get bored of it. So that's, I think, a big strength of this particular programming language.

Artem Barmin 

Okay, Alexander, and now we move into the parts when you can ask the question for the next guest.

Alexander Johannes

I've thought about a question. I was talking a lot about development processes and so on, and also how we have adapted in a way our development process when we introduced our Clojure platform. And my question here is, have you experienced something along those lines? So have you, for instance, had a development team where you were doing development on a certain language, on a certain tech stack, and then you introduced Clojure into your tech stack and onto your team?<br/><br/>And were you forced or did you need to change your development process for this particular team because Clojure made something easier or developers were approaching things during the development a little bit differently? And so were you forced or were you enticed to change your development process?

Artem Barmin

Okay, thank you. We will pass this question and you can find the answer on the YouTube. It was really interesting to hear your perspective and your experience. Thank you for sharing them.

Alexander Johannes

Artem, Vadim, it was a pleasure for me to being invited to this podcast and doing this thing. And yeah, it was a pleasure for me to kind of talk about all things, all things, what Clojure is for JustOn and bringing my own or our own perspective into this thing here. So thanks for having me.

Vadym Kostiuk

Yeah, thank you, Alexander. And also to our audience, if you'd like to learn more about JustOn Team, we'll be including links below this video. So please make sure to check them out.

Artem Barmin 

And once again, thank you, Alexander, and for the audience. See you next time. Bye bye.

Vadym Kostiuk

Until next time, thank you.

Alexander Johannes

Bye.