LegalArgumentException: From Courtrooms to Clojure - Sen

Hello everyone. Uh I want to begin with a question. Uh has this ever happened with you that you are in the middle of your work? Maybe you're doing an important release or fixing a bug or maybe you're part of a sprint planning meeting when a question pops up. Do you truly enjoy what you're doing? Uh do you want to keep doing this for the next 10, 20, 30 years of your life? what ensures that the career that you are currently in is the right one for you? Uh there was a time in my life when I this question would keep coming up to me. Uh back in 2018, I was a financial lawyer at one of India's largest banks. Uh the the work was quite lucrative because I got to work on a number of important deals and I knew that if I stuck around a number of important doors would open for me. But there was a nagging feeling as if something was missing. uh you see I felt like I was a small cog in a large machine which was riddled with a lot of process and procedure and had a feeling like my ability to bring about change was very limited. So when I joined my next organization which was Vidhi center for legal policy this feeling went away. Uh Vidhi is a think tank in the legal ecosystem and I joined their insolveny team. Uh insolveny law essentially answers what to do with companies or persons who go bankrupt and are unable to pay their debts. What do you do with their assets? what do you do with the people who had lend them their money and so on. So my work at VI was quite good because I got a chance to uh do cutting edge legal research. I could I got a chance to read about how insolveny laws work across the globe. I got to work closely with the government to bring about legal change. In fact, a report that I had written about introducing a new type of insolveny for smaller companies ended up changing the law of the land. And that is great, right? change something that you had written on the piece of paper resulting in changing the law of a country as big and as diverse as India but it was around this time that I started asking my qu myself is this it do I want to keep doing this and somehow I didn't know how to answer this question hello everyone namaste I join my name is pronounced oiho but if it's difficult you can call me in short that's what my wife mother calls uh by education I'm a lawyer. In fact as recently as 2021 I used to work as a corporate lawyer in New Delhi but today I work as a closure engineer in Pune India. And this talk is my story of struggle of self-discovery of change. This talk is my story of how a corporate lawyer found his way in the world of closure. Our story begins in the middle of the pandemic. uh everyone had their challenges in the pandemic and so did I. Uh like I was saying I was working at Vidhi and this was somewhere in the middle of 2021 when I suddenly started feeling a sense of disconnect with what I was doing. Initially I thought maybe I was overworked but then I realized that probably it is something deeper than just that. And this was puzzling to me because this was something that I always wanted to do. uh back in my bang days I would do anything to get an opportunity where my work has real world impact and it is true my work did have real world impact but it came at a painfully slow pace remember that report I was talking about that led to the change of the law it took more than two years to come to fruition and that by all accounts is lightning speed in the world of law legal reforms often takes more than a decade to come to fruition so here I was I was working on this project more than two years non-stop without an end in sight and this was the pandemic so I was all alone, disconnected from my colleagues when I suddenly started to feel a sense of burnout creep in. And sadly, this was not something unique in my case. You see, in the legal world, working in your weekends, keeping your birthday for something urgent or prioritizing your work over your physical health are all too normal. In fact, if you see Bloomberg's latest report on the legal industry, you might be surprised to see that nearly 50% of the respondents had said they had felt a sense of burnout in the last one year. So like them, I too was feeling the sense of burnout. Maybe because it was about the amount of work that I was doing. Maybe because I hadn't taken a break for the longest time or maybe it was the long gestation period of the project. But whatever it was, I realized that it was not sustainable to continue like this in the long term. So [snorts] when my current project ended, I decided that it was the opportune time to take a break instead of blindly jumping into the next one because the next project could take you two, three, maybe a decade to complete, right? So here I was having spent 8 years in the legal industry, 5 years as a student, 3 years as a professional. I quit my job without a fall back right in the middle of the pandemic to answer the question, what do you want to do with the rest of your life? And one of the first things I found myself doing as the as my sbatical started was trying my hand at programming. To be honest, this is not entirely a chance encounter. My elder brother is a software engineer who unlike me took the boring route of going to college and getting a degree in computer science. He nudged me to try out try out programming not necessarily as a career path but as something that could be of use in all walks of life in today's world. So I just signed up for a free uh for a basic JavaScript course on free code camp and uh it taught me how a for loop works, what is an if statement and so on. And to my surprise, I really liked it. I really like solving these exercises. It gave me a runner's high. Every time I solved these exercises, it felt like solving a puzzle. It's like playing a game of chess. And as I did this a bit more and I discovered this joy of programming that I felt, I realized a lot had to do with the quick feedback loop of uh programming. Uh you see in the world of law, whenever we are working on a change, we are told that we should be near perfect. We should cover our bases, take care of all the edge cases because of the time it takes to carry out that change. You'll probably not get a second shot. Unlike there, here there's no such expectation. You could ship something which doesn't have all the bells and whistles and that gives you the added advantage of getting feedback on your product early on. You can in fact ship the tiniest change that you have worked on and see that play out in the real world and get that instant gratification and let that motivate you. So I was realizing all of this and I realized I I felt this strong connection to the world of programming and I thought to myself can I take this to the next logical step? Is it possible uh to do something with this bit more seriously? And I asked around, I did my research and it turned out that the world of tech is quite inclusive and there are people who are today software engineers but who used to be something else back in like in a different avatar. So I decided let's do it. Let's try to carve a career out of software engineering for myself. And the day I decided this it became abundantly important as to how I go about this learning journey of teaching myself how to code. Because in today's world uh getting access to information is not a challenge. just not a hurdle but how you consume that information and how you demonstrate it that makes all the difference. So one of the first things that I decided as I embarked on this journey was that I would employ Richard Fineman's technique of learning things. This is how I would go about it. Whenever I would come across a new concept, I would read about it from various sources and I would write about it in my own words as if I was trying to explain that concept back to me. Then I would read what I had written. I would try to identify my gaps. Then I would go back to the drawing board, read about it and fine-tune my uh writing. And I would keep doing this till I was satisfied that what I had written was something that explained the concept to me like a beginner. So once I was once I was satisfied with the piece, I would publish it on my personal blog which is ot.dev which is still live. And in the eight or nine months that was part of this journey, I ended up publishing more than 40 blogs uh from topics ranging from how to convert a string to an integer to my understanding of how the internet works. The other thing that I decided I would do in this learning journey was that I would build projects publicly. Uh when I embarked on this journey, I knew that the end goal would be to apply for a job and when I would do that, I would essentially be competing with someone who has the benefit of a college degree in computer science. uh unlike them, not only would I not have such a degree, I also don't have a peer who could vouch for me or like a former employee who could recommend my name. So my work would have to do all the talking. So I decided that I would be writing projects and building them uh and deploying them publicly and these would form the key milestones of my learning journey. And in the process I started with a simple list interpreter which was inspired by basic closure syntax written in JavaScript. I also built a URL shortening app where you could login as a user, create your short links and use it. I also created a Twitter bot which was inspired by Planet Closure uh which would scan through a number of blogs and would publish new posts uh from time to time. So this went on for quite a few weeks. I was learning new concepts, writing about them, then building projects and I was doing all of this using JavaScript because uh this was a language that everyone was talking about and uh this seems seemed to be the mainstream uh option available and I didn't know any better. But soon enough I realized that I was hitting a few roadblocks. I was finding myself spending quite a lot of time navigating the quirks of the language. One uh grave example was when I was building my URL shortening app. Uh I had a requirement of writing a unit test case and in this uh test I would have to call an API to my service after a few milliseconds. I came across this library function called set timeout and I thought that I need to pass my function to this library function and it would do the work for me. But as it turned out to make this to work I had to understand what is await, what is a async, what is promise, what is call back function, what is call back hell and so on. And in fact this was so complex and not intuitive for me that I had to stop what I was doing and write it about write about it in my blog because that was the only way to explain such disparit concepts back to me. And while I was doing this I kept asking myself this ought not to be this complicated. All I needed was a timer and after the timer was up to execute the next block of code. And when I talked to a few people about this and read about it myself, I realized that in closure this would work exactly like that. After the thread sleep uh was over, you would continue executing the next block of code. So after spending a after encountering a few more such roadblocks and realizing that a language like JavaScript has its own idiosyncrasis and nuances that you have to grapple with, I realized that I needed a programming language which was devoid of such quirks, which was no nonsense. It was just simple to use. And that's when I started trying my hand at Closure. And the very first thing that I liked about Closure is how simple and easy to use it was. It took me a fraction of time to get onboarded to this language. And the fact that the core of the language is so elegant and simple that I I didn't have to worry about boilerplate clauses like public static wide main or annotations or any such thing. I could just get going. And I soon got a sense that if I use a language like Closure, it could help me get to the finish line of building projects and deploying them faster than a language like say Java or JavaScript. And along the way as I was tinkering with the language, I came across the ripple which ended up being a teacher and a friend to me. The very first thing that I liked about the ripple was how easy it was to set it up. I didn't have to worry about a separate IDE. I didn't have to think about uh extensive plugins. I could just fire it up in my own command line and start uh doing what I needed to. And the fact that it gives you instant feedback was very useful for me because whenever I came across a new concept, I could try it out on the ripple and see how it works. In our case, for example, if I needed to see thread sleep would work for my unit test case, I could just try it out and I see that the main thread gets blocked and after 3 seconds the line gets printed. Similarly, if I wanted to wanted to do the same thing but in a background thread, I could use future and that would work too. And soon enough, I found myself writing my projects very differently. I was now writing my functions in the ripple directly. I was trying my function out until I was satisfied that it was doing exactly what I wanted to. I wouldn't add it back to my project. And this was very different from how I was writing my projects before where I would write lines of code and hoping that it would work as I anticipated and then only upon compiling the whole project I would realize that there is probably some kind of a syntax error that broke everything down. Unlike then now my functions were battle tested. Now I was confident that whatever I was adding to my uh project would work in a particular way. So after realizing these I I took a note of this that I needed to ensure that closure forms a formative part of my journey here on fourth because you see the journey of learning yourself something uh which is so very different from uh the domain that you are coming from is already quite difficult and the learning curve is already quite steep. On top of it, if you have to grapple with a promise and a call back function when you are just trying to set up a timer, the imposter syndrome kicks in very quickly and you often you suddenly feel like you don't belong here. And I didn't want to expose myself to that risk. So I decided that I should probably work with a language which didn't come with those surprises and which mostly went out of the way so that you could do what you need needed to do. And I thought that closure should be a part of my journey from here on forth. Uh in November 2021, I applied for the Rick center. Uh the the Rick center is a uh programmer's retreat in New York. Uh it is where programmers at all walk all stages of their career come and work on their personal projects during a sbatical. Uh it also provides a nice uh networking platform and I thought that this was an appropriate place for me to spend some time. So when I was writing my statement of purpose there, one of the first things that I mentioned was that I wanted to learn closure at recursor center and build things with it. uh in December 2021 I got a mail from them saying that I was admitted to their precedious retreat and this was the very first time I got a external validation from an entity and this gave me a lot of uh relief and joy because this told me that I was on the right track and that all the hard work would eventually pay off. So while at Rick center uh while I was tinkering with the language understanding uh the fundamentals of the language I decided that when I would eventually apply for jobs I would focus on companies that have closure in their tech stack. Now fast forwarding fast forwarding a few years uh to the current day uh I'm happy to note uh that uh I I joined Shift Technology in May 2022. Helpshift is a company which provides a platform for end users of apps to communicate with their customer support executives. Uh helpshift is used in over two billion devices and more than 5 million conversations are created every uh month. But the best thing about helpshift is that their backend uh tech stack is almost entirely built out of closure. Uh in the three three and a half years that I've been at Helpshift, I worked on a number of things but today I want to talk about the auto assignment engine. The auto auto assignment engine answers the question. What happens to new tickets uh once they enter our system? Which customer support executive should be handling that ticket? And this question is answered upon taking a number of parameters like whether the customer support executive is online, uh what is their status, what are the number of tickets that they currently working on, uh what is the priority of the ticket and so on. uh just to give you a bit bit of a uh look into what's what's uh underneath the hood. Uh it's an event-driven system which is real time. Because it's realtime system, it has it maintains all the data in it in memory data structures and therefore whenever there's a change in the external world, it consumes Kafka messages to that effect. For example, if an executive goes offline, uh it consumes a Kafka message and ensures that this that executive is never recommended for a ticket from there on. And on the other side of the funnel, it uh emits uh messages uh recommending tickets to customer support executives. So when I was given ownership of this microser, I realized that this is a very old microser with a lot of legacy code. Uh there was very little helpful documentation to help you and the last owner of the repository had long left the company. So this looked very daunting at first. Uh I had never worked on a event-driven system before this. But this turned out to be less of a challenge partly because of how elegantly it was written and partly and mostly because of the fact that I had the closure to my disposal and I could use it to answer all the questions that I had. Uh so in the few months that I've been working on this uh microser I have had the opportunity to bring about a lot of foundational changes in the system. For example uh we had to introduce the concept of workspaces in our system. Workspaces are essentially partitioning of your session into multiple subsessions. Kind of like how on Gmail you have multiple profiles. So how it would work is that a customer support executive could be part of one or more such workspaces and the auto assignment logic would have to work as before. Uh to make this to work, we had to re-engineer fundamentally how the auto assignment engine was built because it was never supposed to work with this concept of workspaces. And while I was working on this uh I realized that the auto assignment engine emits a large number of logs because it's an event- driven system. These logs are the only thing that we have to reason about why a particular decision was taken. And because it handles a large number of tickets and because it's internally multi-threaded, there are a lot of logs with overlapping timestamps. And it so turned out that the logs often did not have all the important information. So it was impossible to filter out all the logs that are there in a given event cycle. So uh I implemented end to end distributed tracing and structured logging uh into this microser. And while it might feel like it's a big change, it was not. It took only a few weeks to implement uh because all I needed to do was to implement a logging macro uh which would do all the work for me adding the necessary trace ids and the missing uh uh data into the logs. Uh I also got a chance to work on a new feature which would require a new type of ticket live ticket to be routed to live custom support executives without touching the rest of the flow. And all of this uh foundational changes I could do in a matter of seven or eight months while also getting married on the side. And I think all of closure and the ripple has a lot to do with the speed with which this was achievable. uh when I look back uh 3 to four years back when I was just a corporate lawyer I didn't know the difference between for loop and eels statements and uh from then to now being an owner of a deeply distributed system and making foundational changes on top of it might feel like this was uh to a person who has not had the luxury of going to college and getting a degree of computer science it might feel like a miracle in fact if you had told me this could have been one of the outcomes when I started this journey I would have also said that this was probably too good to be true. But the fact that I'm here today, the fact that I'm sharing a platform with industry stalls like Richiki, the fact that all of you fine people have come here to listen me talk proves you that it is possible. And I'm not here trying to say that the journey is easy. The struggle is real. I remember many a late nights where I spent looking at the looking at my screen trying to reason about an error statement when the imposter syndrome would kick in and a voice at the back of my head would tell me that I don't belong here. In fact, when I was working on the uh unit test case and trying to work with the timer and I had to understand what a promise was, I was this close at quitting. But I didn't quit and that is why I'm here. So to all the people who are coming from a world that is so very different and trying to break into the world of tech, find a friend, find an ally who will keep these imposters away. In my case, that friend was my elder brother who has been a source of constant motivation and struggle and direction. Uh to me the friend was also the rebel. Uh too many of us have been left behind in this journey not because they lacked a sense of drive but because they didn't have the access to the right support and the right tools. So in case if you're wondering if you can make it, yes, you can. And the fact that I'm here is because anyone can. And in any case, I'll always be there to lend a year. You can always walk up, talk to me. We can all use a friend in this rather solitary and long journey of becoming a software engineer from something else. And as for me, after the changes that I've been through, uh do I still think this is it? Well, I can say that the lambs have stopped screaming. I no longer ask myself this question. Uh because I know this is it. And I come here in passion and in peace to tell you that if I could do it, so can you. Uh this was my story. Thank you for listening. If there are any questions, I'll I can answer them. >> Yeah, if there are any questions, feel free to walk up to this mic right here and ask OT some questions. I'm sure he'd be happy to answer. >> Quick question. Um what is your brother programming in and have you tried to uh indoctrinate him to closure? >> Uh my brother currently is working in uh Java. I think he's at booking.com but he's also a closure enthusiast. So he plugged the planted the small seeds of closure all along the way. Uh so yeah. Hey, um you talked a little bit about the um struggles in the journey, but like what was some of the most joyous like parts of um your story today? >> Yeah, I externally I think getting admitted to the Ricker center and getting your first job as a programmer were the highs because they were kind of like something which someone I didn't have anything to do with telling me that I belong here. But internally every time I could see a change that was there that I made and I could see it on the browser or wherever the platform was gave me that sense of motivation and elevation that yes I something that I was trying to do is working exactly how I intended to seeing my change in the real world in other words has always been the constant source of uh joy and motivation. Yeah. is do you have any plans to uh contribute back to the the legal world because it seems like your profile is is um sufficiently different than the other programmers around you and that what you have to offer is is probably could be really significant in that field. >> Yeah. So, uh it it's a it's a very open-ended question. So, I'll try to answer this. Uh so in the world of law uh like I always argue that the two worlds are not so very different in both the worlds whether you're writing a contract or whether you're drafting a statute they're fundamentally based on logic and when you're it's just the way you are expressing that logic. So if any any of you are reading a privacy statement it might look like a gibberish right but equally if a lawyer is reading a closure code that might seem very terrifying but it's just that how you express that logic in a particular semantics is just that the semantics is different so to coming back to it I think uh I feel from my experience uh as a lawyer in India uh the at least this is slightly dated because this is 2021 but the adoption of tech in the workflow setup is not that high so people are still using tools like Microsoft Office or Excel. Whereas you could have specific tools created for the for the workflow specifically for for example drafting a contract or there's something called due diligence report where you look up company books and say if everything's okay. So maybe we could build something around that to make their lives easier because these are very painstaking and repetitive tasks. So but this is a very open and questions from the top of my head. So, >> any other questions? >> I'll ask from the formal spot because I have a question. Yeah. >> Um, was there a particular community or other group of people like besides your brother that >> uh that you could collaborate with or helped you stay accountable uh when you were learning uh closure or when you were learning just programming in general and then closure specifically? >> Yeah. So I at the outset this was a very solitary journey because of the context of the fact that I came from a world where where there was almost no intersection between law and tech and the fact that it was the uh middle of the pandemic. So my exposure of going out there and meeting people physically was limited. But uh there were various forums like I think there was a slack channel uh closures closure I think where I had asked a question. There was a Reddit channel also I had asked a question and uh there were people who had reached out to me to help for example uh another person who comes from a different background Aditya Atal who uses the handle Adi in our uh discord group. So he when when he came to know that I was doing this and was applying for center he just spent more than an hour trying to explain to me how closure works and there was a workshop that he had prepared. So he was giving me a workshop uh walk through and that was really nice. another person who help who was also so I when I joined recur center I looked up the people who are joining and I saw that there was one person from India who is joining in the next batch and that person was also a closure enthusiast and that person has been like it's much much senior to me and I just reached out his name is Vedang and he just again took time out and just gave me a walkthrough of how he uses his very cool setup which looked very daunting to me at that time but it was very cool and uh that inspired me that yes this is how you write closure it's not that you have to manage parenthesis so difficult like this is how it works so there have been individuals along the way who have come and just helped me without any sort of returning and uh that is helped me come here >> awesome do we have any other questions >> all right well join me in giving one more round of applause for 13. Thank you.

What does legal reasoning have in common with functional programming? More than you might think. This talk is an experience report from a lawyer who transitioned into a career as a backend Clojure engineer, moving from drafting contracts to designing and deploying features for mission-critical distributed systems. Attendees will learn about the surprising parallels between legal analysis and writing clean, functional code, and how a background in the humanities can be a strength in software engineering. We will explore a practical, repeatable learning framework modeled on a tool we all know and love: the REPL. This Read-Eval-Print-Loop methodology breaks down daunting tasks—whether learning a new language or refactoring a complex event-driven system—into manageable, iterative cycles. You will leave with not just an inspiring story, but with concrete strategies for approaching your own learning, mentoring others, and a deeper appreciation for the simple, powerful feedback loops that Clojure provides for both our programs and our careers. Biography Oitihjya Sen (Otee) is a backend Clojure Engineer at Helpshift Technology, specializing in event-driven distributed systems. He currently leads the effort to enhance the performance and observability of the company's core ticket assignment service. Before his career in tech, Otee was a corporate lawyer. In a self-directed career pivot, he taught himself software engineering, building a portfolio of projects including a Twitter bot and a URL shortener. He believes in learning through teaching, having documented his process in over 40 blog posts on https://otee.dev and the Helpshift Engineering Blog. An alumnus of the Recurse Center, Otee is passionate about bridging the gap between unconventional backgrounds and the world of functional programming. Recorded Nov 13, 2025 at Clojure/Conj 2025 in Charlotte, NC.