An inside look at Jane Street's tech internship with Jeanne Van Briesen, Matt Else, and Grace Zhang

Welcome to Signals and Threads, in-depth conversations about every layer of the text back from Jane Street. I'm Ron Minsky. So this time we're going to do something a little different than our usual episode, instead of digging in deep with one person, talking on one focused technical topic we have a few people here today, and the topic is a general one, which is we're going to talk about Jane Street's internship. And so we have three people who know a lot about it. They've all gone through the internship before, Grace Yang, Gene Van Breason, and Matt Ells. And we're going to talk with them about what their experience was like, both at the time of the internship and also how that transitioned to being a full-timer here, how that worked. So to start with, let's have you guys all introduce yourselves and tell us a little bit about where you're from and where you guys are now. Yeah, of course. I'm Grace. I just graduated from Harvard this past May. I studied CS and Statistics at school, and I just joined Jane Street full-time pretty soon after graduation. I am a software developer on RISTEV, which is also a team that I interned on last summer. So I am back in the Jane Street New York office full-time and excited to be back since I'm also from New York originally. Although these days not quite the same notion of office as we used to have. That's right. Perhaps you don't really get the feel of the difference between the New York and London offices so much these days. Yeah, I'm Matt Ells. I work in the London office and I graduated from Cambridge in 2019 and started as a full-timer around September 2019 after interning in the summer of 2018. I now work in a team in trading systems where I've worked since I started as a full-timer. And I'm Jean. I graduated from Carnegie Mellon about a year ago. I interned two years ago now, and I currently work on a team called RFQ Dev. So Jean, how did you hear about Jane Street? I heard about Jane Street through Carnegie Mellon's functional programming class. People would always ask questions, like, oh, when is functional programming going to be useful? And then they would say, oh, but don't say Jane Street because we know they're the only one who uses functional programming. It sounded like you said Carnegie Mellon's functional programming class as opposed to Carnegie Mellon's functional programming cult. Well, the functional programming cult sort of originates from the functional programming class maybe. Yeah. CMU has quite a big programming languages group and quite a few functional programming classes. And there's a lot of hype for functional programming there. I was one of those people who both bought into the hype and was perpetuating the hype. Rebecca, you literally taught a class called hype for types, if I remember correctly. This is right. Yeah. That class is still going on now. So there have been three generations of instructors now, so still going strong. So yeah, so applying to Jane Street was really a no-brainer for me. It was a place that was known for doing functional programming. Okay. Great. You act as an effective representative of a small, but important set of people who applied to Jane Street because of an unhealthy interest in functional programming. Grace, how about you? So Harvard also has a functional programming class, but we just have one. That was definitely like, I think a good start to spark my interest in functional programming. And Ronald also came to give like a short talk on using OCaml in the real world, which was actually pretty cool because that was certainly a question a lot of us had coming into the course. I eventually got to know Jane Street through insight, which is Jane Street's program for women in STEM. They're different tracks. So I did the dev track at insight, and it's pretty cool because I think it gave you a good sense of what it's like to work at Jane Street and work with the people at Jane Street. Insight is like a week long program where they bring you to the Jane Street New York office, and you go through something like an OCaml bootcamp where you do different exercises to kind of learn about OCaml and get a taste of the kind of work that we do here at Jane Street. And I thought that was really cool. I really enjoyed working with the people at insight. And I felt like I got to see a lot of the culture at Jane Street, which was really exciting. I fly to Jane Street to be an intern last summer, and I'm now back full time. But now that you're here full time, have you gotten involved in insight from the other side? Yeah, that's pretty cool. So insight, I think, is during January, so we haven't quite done it yet. But I will be helping out with Infocus, and I've also helped out with some of the other programs. So it's pretty exciting to be on the other side of things, because I think these programs are really important and really help spark an interest. When you say these programs, these are various kinds of outreach programs, essentially. Insight is aiming for reaching out to women. There are some that are aimed for trying to get at various non-core schools. We have overrepresented from like a small number of schools where we get a lot of people and trying to branch out, and there's some programs we're working on for underrepresented minorities. There are a lot of different efforts in different directions there. Yeah. Yeah. Really excited to be part of it. Great. Man, how about you? Yeah. So similar to both Jean and Grace, I'd done a little bit of functional programming at university, and I guess unlike Jean, the cult of Okamal doesn't stretch quite so widely at Cambridge, but I was certainly something that I'd come across and kind of enjoyed. But the main reason I applied for an internship at Jane Street was because a friend of mine who at the time was a visiting student from MIT had done the internship. The summer before told me all about it, told me how much fun it was and how interesting it was, and generally just kind of made me want to apply as well. And as it turns out, we're now both full-timers here at Jane Street. That's great. So one thing that immediately strikes me from these stories is that you guys are a little unrepresentative in that you've all had functional programming experience. And maybe all programs specifically in Okamal before coming here, whereas I think in reality if you sample incoming interns a quite solid majority, I think haven't done any functional programming at all, which is actually a pretty big change from what recruiting was like 12 years ago or something, where I think at that point we leaned pretty heavily on, hey, we program in this interesting functional programming language, so maybe you want to come work here. And now we have lots of other ways of attracting people, and so the functional programming part is much less of the thing that brings people in the door. And indeed, I think people often think to come work here, they have to already know Okamal, which is totally not true. And in fact, people sometimes think they should interview in Okamal, which is also almost always the wrong idea, because there's really a very small slice of people for whom Okamal is the language that they can best show what they're good at. And people who choose to use Okamal to please us often discover that it is not a very effective technique. Anyway, so I was wondering if you guys could say a little bit more about how the internship worked. What's the basic structure of the internship? I guess I can talk about it first since it's perhaps a little bit fresher on my mind than for Gina Matt. So I interned last summer, and I think I really enjoyed Jane Street's internship structure actually. I think that was one of the first things that I think I was pretty excited about, which is Jane Street's dev internship is structured so that you can work on two different teams, and oftentimes there are like two teams that are spread across the farm. That was really nice. So for example, I worked on the larger trading systems team and also post-trade, and I thought that was pretty cool. It kind of gives you a better sense of firm as a whole, and it kind of gives you a little bit more exposure there. It was really nice to have been able to intern on two teams. Also, the internship is structured like Ron mentioned before, so that doesn't assume that anyone comes in with any Okamon knowledge. The first week or so of the internship, we did an Okamon boot camp, which is a way to help people learn the kinds of tools and the language that we use at Jane Street, which I think is pretty exciting. It was really cool because the internship class does it as a whole, and so it was nice to start off your internship with the rest of your class and all go through this together. That's a lovely thing about the internship that I think wasn't clear to me until it just kind of happened is how nice the community of people who come in all at the same time, all knowing nothing about the organization and about the technology, and just come to be friends with each other. And that's, I think, been a very positive experience for lots of people over the years. For sure. That was a great way to introduce us to each other and build this internship community. I think that's definitely one of my favorite parts as well, because once you finish your Okamon boot camp, all the interns sit next to their teams and mentors, and so you kind of more spread out, but it was really nice, like I sat close to a few different interns, and sometimes when you're super caught up in the code you're writing, you might forget that you have like an intern event coming up or something, so we always grabbed each other to go to the events, which is great because otherwise I think some of us may not have made it to them. And yeah, I think Okamon boot camp in general is also really a great start to the program because your first mentor is the one who's reviewing your code and who's kind of working with you. And you go through like the code review patterns that you would go through once you start on your project, and so it gives you a good way to get settled in your new team. How hard did you guys find it to acclimate to the tools? Like a side effect of the fact that Jean Street uses a comically obscure programming language is that we have also invented a comically large number of idiosyncratic tools for working with that programming language. And I'm curious how you guys found it to acclimate to a bunch of tools that you hadn't used before. Personally, I'd certainly found it kind of a challenge. It was one of the more challenging things of first starting was getting used to all of the tools and to some extent kind of dealing with all of this institutional knowledge that is kind of in people's heads that may or may not be written down and can be sometimes quite challenging to access. But once you get over this initial hurdle of figuring out these tools and figuring out how to find out more information about these tools, it wasn't too bad. And you kind of adjust to it fairly quickly. I don't know what you guys thought about it. I also thought the classes that they do for interns, like the tech classes that are about our code review tool or some of the libraries with a steeper learning curve really helped us get on board better than maybe just doing our projects would have. Yeah, I think over time we've realized that we needed to build more of a kind of formal education program. It's one of these things where we built out formal education programs in stages. I think the first one we built, the program that was called Okamel Bootcamp was initially designed primarily for traders who needed to learn how to get comfortable with technology that the tech side had been building. And then we repurposed that material and started using it for teaching interns and started developing more material for that purpose. And now we use some of those same materials and in fact a bunch of other stuff that we've been developing as part of a longer-term teaching program for people who start full-time. In that as the organization grows you come to realize there's more specialized knowledge that becomes valuable to share between people and across teams and so it just makes more sense over time to build up more of that. I guess the other thing that you have to come to grips with with you guys haven't talked about yet is the whole finance side of things. How well did the program prepare you for having to deal with projects which are about a subject matter that you presumably had no experience with before? We had lots of classes which I think was really helpful and we had for example like some traders give an overview of finance and economics things like that so I think that was really helpful to paint kind of broad strokes but I think what was most helpful was just that we worked very closely with our mentor and the teams that were on and I think my mentor's both did a really great job of providing the context to help me understand where my project fits in and how it's useful for the firm and I think that was very valuable and helped me understand the motivation for my project and also just think about how I would want to design it and work on it. So maybe this is a good time to talk about actual projects and can you tell us about one of the projects that you worked on as an intern? Yeah of course one of the projects I worked on was Jane Streets Manual Order Entry System. It allows traders to manually enter orders into the market and has lots of different risk limits which is important because you know you need to think about the risk of just actually sending trades out to a market. For example like a risk limit might be something like you know we can't fill more than say X dollars in a day and these risk limits are at different scopes so it could be at the user level but it can also be at the system level and so the state of the world before my project was that traders could easily adjust their user limits very quickly during the trading day but we were not able to adjust our example system level limits very quickly during the trading day which is important and something that people had been asking for because during a busy trading day you might need to increase your risk limits during the day and in general you want to do things quickly but especially during like a busy or trading day. Okay so that raises something that's maybe worth explaining which is this whole idea that traders might just like go and directly up their own limits seems kind of odd. On the face of you think if a trader has a limit then they wouldn't be authorized to just go past that limit but it turns out the way we have our risk system set up there are multiple different kinds of limits and some of them are hard limits that you know when you bump up against it that's it and you have to get someone else to authorize and increase if it increases necessary but there are other limits that have a pre-configured number of times that a trader is allowed to essentially bump their limits so this kind of limit acts more like a speed bump than like an absolute barrier on further trading and as you said when you hit one of those limits it's really important to be able to move past it quickly because the time when that's likely to happen is exactly when trading is busy and therefore when trading is at its most valuable. Yeah exactly you're able to increase your limits like a configurable number of times and we wanted this kind of same behavior or limits at other scopes. And prior to you doing this work what did the process look like when you did need to increase those system-wide limits. Prior to this some of them need to go in and actually make a change the way we've configured our limits and actually go through a process that is basically code review so they would need to update the limits they need to get it code reviewed by someone else they need it then like release and apply this actual change which is like a slightly slower process. Amusingly our process for changing risk limits is exactly the same process that we use for modifying code which is not obviously the natural thing to do but I think over time we came to realize that it was in fact more or less the same thing and that we have a bunch of configuration which is a big technical document with precise technical meaning that people need to make changes to and many years ago the way we did this is when different people wanted to propose limit changes they would literally like an old traditional Linux developer they would generate a patch representing the change that they wanted to make and send that to the trade support people who would then manually apply that patch to the code based acting kind of like a human version control system and then multiple people would do it at around the same time because things were busy and lots of people want to do it and if it sounds like a nightmare it's because it kind of was so now we have this much more organized process that looks a lot like the code review process which I think makes sense for changing the core risk limits but you obviously you say you want to have some fast path for simple changes and that's exactly the thing that you worked on and it was pretty exciting because when I came back full-time I realized that my old mentor had emailed me basically like my first or second day and forwarding me an email that where a trader was like today we had a really busy day of trading and I needed to increase our risk limits quickly and I was really excited to be able to do so using the project that I worked on and that was just super nice my mentor was like you know yeah my intern worked on it I'll be sure to forward it to her when she joins full time and it was just great to see and great to hear from my mentor when I got back full-time so a very warm welcome back to Jane Street right and this highlights I think a lovely thing about a lot of the intern projects which is interns get to work on real things right and a lot of those projects actually land not all of them but a lot of those projects end up landing in production and I guess this one didn't yeah it was super exciting always good to see people are using and benefiting from your work Matt how about you can you tell us about one of the projects that you worked on for the first half of my internship I worked in a team called RFQ Dev which you might remember from Jean talking earlier she now works in there as a full-timer so when people think about trading shares and ETFs and securities in general you probably think about sending at order to an exchange like the New York Stock Exchange or the London Stock Exchange but there are other ways of trading that are preferable maybe for really large trades or for technical reasons where you might want to trade directly with a company such as Jane Street and so historically the way that this would happen is you would pick up the phone and call Jane Street and say I want to buy Apple let's say and Jane Street would say well I'm willing to sell you Apple for this amount of money it would be some sort of back and forth and maybe the trade would happen or maybe it wouldn't and over time people gradually realized that oh it would be kind of useful to be able to automate a system and so there was this thing called RFQs that were developed which is an automated way of someone saying I want to buy this thing and then sending this request for quotes to a whole bunch of different market makers and seeing what price they were willing to trade for and so Jane Street developed a way of interacting with this automated system that at first involved another person at Jane Street responding to these quotes and then gradually developed into a more automated system with risk checks similar to what Grace described with her project. I think this all highlights the fact that trading is way more manual than I think people often think about especially people who know about Jane Street by paying attention to the technical side of their work imagine that the entire place is just a bunch of people built some algorithms and there are people like thinking hard about the algorithms during the day and looking at the results of week-long experiments and then on their way out the door they check like oh how much money did we make today and like oh my god it is not like that at all there's a huge amount of human judgment and intervention and also just stuff that's manual like we have manual order entries you just go and directly type in exactly what price and size you would like to trade at the human just makes it so directly and we have lots of things that have human involvement and communication and then we do a lot of work to automate various aspects of this but it's not like we want to completely get rid of the human element the human element and the judgment that comes in there is actually incredibly important to how we operate. Yeah definitely this is something I probably didn't realize before I started at Jane Street was the amount of human interaction that's involved you still have lots of people making trades over the phone especially for big trades and you have people all making manual trades and making tiny manual adjustments to trading systems throughout the day but anyway so we have all of this automated infrastructure for doing this trading directly with counterparties but still a lot of this trading happens over the phone and so we built all of this automated infrastructure so we at some point decided that we were going to add a way that a sales trader who's on the phone with the counterparty could ping our automated system and say right how much would we normally trade this for if it was on the automated system and then they have a number that they can face their trade on. Right it's actually a chat system almost which lets the sales trader understand where the automated systems are willing to buy and sell and use that to inform their own trading. Yeah exactly and so there's a sort of implicit risk check here that you have a human interacting with the trade in the middle but this didn't use the same automated risk checks that we had for the automated trading just because there was kind of no need to because we have a human who is thinking about this trade in the middle. But at some point we realized that it seems kind of silly to have all of these risk checks and then not use them for this one weird case and so the project that I was doing was to make these manual requests to the system behave more like automated requests so they were coming from a counterparty of some automated system. As a result we would get all of these fancy risk checks for free. So basically what we're doing is taking the system which had two different kinds of requests one fully automated one that was just kind of providing information to a sales trader and take the risk system that apply to just part of it and apply it to the whole thing. In some sense that sounds relatively simple I'm curious what were the interesting and challenging parts of that as a project. I think for me getting my head around all of this complex infrastructure that took me like five minutes to just describe after I've spent a year working here and kind of have some background. It was getting my head around all of this financing stuff in the space of a few weeks because you spend two weeks learning a camel and then immediately you are working on this project about something that's completely opaque to you. And this was a pretty big challenge to me. And I took a lot of input and discussions with my mentor who was really helpful and really willing to answer questions for me to just get my head around what on earth are these things called RFQs and why do I care about them effectively? Why does Jane Street care about them, I suppose? And so what have a technical difficulties I had were kind of dwarfed by just getting my head around the basic concept of what I was working on? The other thing that strikes me about actually both your and Grace's project is that they're both working on risk systems which could make you a little nervous to like, you know, have a couple of no offense, no nothing kids out of school who are coming and working on. Oh, that's an understatement. Yeah. You're right, working on some pretty core things that are really important to the safe workings of the business. And I think in part, this is just a story about the approach that we have towards essentially the kind of quality control aspects of how we build software, which is there's this very intense code review process where the people who are reading and approving the code, the process involves them really deeply understanding what's going on. It's not like you throw up a patch and they're like, looks good to me and approve it. No, they are reading through carefully, often rewriting various pieces of it, giving detailed feedback and various parts to the point where the person who reviews the code often feels like a second author rather than being just someone who kind of looked it over and checked it was okay. A nice advantage of this system is it gives you a way of taking people who don't have that much context and don't have that much experience and letting them work on a wide variety of different places, including places that are quite critical. Yeah, this is something I've particularly noticed since I've been a full-timer that this code review process where someone is effectively co-authoring your patch for a particular library or particular application can teach you quite a lot in the process of doing code review, which I found really useful. Yeah, I think of this as one of the key advantages that a company like ours has over academic institutions in terms of teaching people a technological concept, which is this kind of intense, high investment thing that you do where an experienced person works with a more junior person and works very closely with them and gives them this very detailed feedback. It's a kind of thing that from a cost structure point of you can't do in an academic context, but it totally makes sense because the people who come and join are very close to being very useful, and so it's really rewards your investment in them, and you can teach people stuff really fast. I think that teaching works well when you have someone who's very new to the organization, but actually is a way that as time continues and you hear for longer, you continue to learn a lot from people through the process of code review, at least that's been my experience. So, Gene, we haven't gotten to you yet. Can you tell us something that you worked on while you were in intern? Yeah, so for my second project of the summer, I worked on the Tools and Compilers team working on a library called Inkerdom, which is Gene Street's library for building dynamic web apps in OCaml. So, Gene Street doesn't have a ton of external facing websites, but we use web apps as a lot of user interfaces for various trading systems, and one of the things that's very important for web apps in general, but also especially for trading system interfaces, is that if something changes on your web page, you don't want to have to re-render the entire web page. You imagine you have like a million cells of various bits of information for your trading system, you don't want to be re-rendering that every time something updates, because that would be incredibly slow. So, Inkerdom is built on top of Gene Street's incremental library, which is a library that handles computations that you set up once, and then when their inputs change, they only recompute the thing that they need to in order to get a new output. So, in this way, we managed to avoid doing any extra computation that we shouldn't do in order to render the view on a web page. When I started my internship, the way Inkerdom was set up was it had two different types of interfaces. One was a relatively simple interface that most web apps used that didn't sort of take advantage of the full power of incrementality that you could get out of this incremental library. So, you could sort of compute some things incrementally, but not everything. The other was a very complicated interface, sort of an advanced interface that could take advantage of sort of the full power of incrementality, but was more complicated to use, and at least in my impression, you only used it if you really had to. So, my project was to take these two interfaces and combine them into one more usable interface that still allowed you to have just as much expressive power as the more complicated interface. Full disclosure, I was the mentor for this project, so I kind of know an unusual amount about this one in particular, but I'm still curious about some aspects of it. So, one thing that strikes me about your description is it's very design-y, right? You're like, "Oh, there are two APIs. One of them is bad in this way, one of them bad is the other way. Come up with one. That's good." I'm wondering how you found the process of going from this fairly high-level complaint about it to coming up with an actual concrete design that made sense. It was very tricky and also very educational. I think I had never thought about any sort of API design before that project, maybe like very small things at college, but really, it was just not something I had learned. So, it was really very much a learning process trying to understand how you should design an interface, like what actually makes a good interface. It was not what I expected to be doing as an intern project. I think I sort of expected to be told to write some code and then to write some code, but I actually got to think a lot about how this was designed. So, that was way more freedom than I expected. And I want to be clear, when we gave you the project, I did not know what the right answer was. It was not like, "Oh, yeah, we wanted to look like this and please, Jean, go ahead and make it look like this." It was like, "Oh, this is kind of terrible. We have some ideas, but we don't really know if they're right." And I think I had ideas that I thought were pretty likely to work out and they mostly didn't, and you ended up doing something pretty different from the original direction I was imagining we'd go. Okay, so you got to do a bunch of this API design work. I guess another aspect of your project I remember is you got to also work on a PPX. Can you talk a little bit about what a PPX is and how that fit into the project? So, OCaml has this thing called PPX, which essentially allows you to extend OCaml's syntax. There are these little tags you can put in the code, and then you can write some code that will take one piece of syntax and transform it into another piece of syntax before compilation happens. And so, the particular PPX that I got to write was one that made it a lot easier to use like a particular commonly used idiom in Incardom. It was previously done in a pretty gross way that involved raising exceptions and stuff like that, and the PPX allowed you to write it in a way that was much more nice and took advantage of some of OCaml's good features. I think of PPX is basically a kind of simple form of language extension, and we have a bunch of PPXs, some of them for doing things like auto-generating comparison functions or hash functions for standard data types, but the kind of PPX you were working on are PPXs that basically almost add primitives for making certain kind of embedded domain-specific languages fit more easily and naturally into the language that kind of looks more like OCaml with a few extra special magic annotations indicating what's the special thing that you're doing in this case, and you basically added some new magic invocations that extended the set of idioms that were expressable in this domain-specific language. So what was the process of working on this more compiler-like part of the system? It was actually surprisingly smooth. There's some very good libraries out there that make it very easy to do transformations on OCaml syntax, and so I learned how to use those, and I had worked with abstract syntax trees before, so I sort of knew a little bit of what was going on, but there were definitely some tricky things like getting the source code positions to match up properly between like the old tree and the new tree and stuff like that. Yeah, and what you're talking about here is essentially one of the complexities of adding a new syntactic construct to a language in this way, which is to say there's some new bit of syntax, some syntactic sugar you want to add to the language, and you do that by writing a desugaring function, something that takes the new syntactic construct, and desugher it translates it into some existing syntax in the language. But the tricky bit is then when you have an error in the desugared version of the code, you need to translate that error back to the original, so say your editor can point at the right place when you have a compilation error, and it's all too easy to mess up the locations in the course of writing the desugaring. Anyway, I'm curious, what was the process of like of taking all this work that you did and trying to land it in production? After I wrote the interface and all the code behind it and everything like that, I then did a big tree smash on all of the projects that currently use this library to convert them to use the new interface. I basically went through our whole repo found every instance where this was used and changed it to use the new thing. So I got to dive into a little bit of every single web app that was currently in use and change it up so that it used the new interface. And yeah, it's actually still in use today. There's a couple of successors to it that are sort of built on top of the interface that I designed, but it's still alive and going even now. So you guys were all interns and now you're all work full-time. I'd be interested in hearing a little bit more about what that transition was like. Yeah, I guess the transition was pretty recent for me, though I did learn that a year is long and I have forgotten much. The project that I'd worked on during my internship was an options pricing app. So it prices options for different scenarios. So for example, like if you know Apple were to go up by like X percent, what would the price of this option on Apple be? And so over my internship, I worked on a bunch of different features and I am back on the team that I interned on. So it's been a lot of time reviewing the code. It was very interesting when I was was like, oh I wonder who wrote this and then did a quick late. and realized I wrote it and I was like, "Well, I have no recollection of this at all." - Yeah, this is the process by which you learned how important it is to carefully document your code and make it really clean. 'Cause sometimes there's a, some annoying person later is gonna come by and have to understand it. And that annoying person might be you. - This is true. - After you've forgotten all the details. - For sure. - It feels like your experiences are really good controlled experiment and that you work as an intern on a project and then you work on that same exact project as a full-timer. So how does that transition to what's different about being an intern versus being a full-timer? How do those experiences compare? - I think in some ways, honestly, like an internship is very representative of what it would be like if you were to work full-time at Jane Street. I mean, that's something that I liked a lot about the internship at Jane Street, which was that, you know, you don't necessarily feel like you're an intern. You know, I think it's always really nice to feel like you're part of the team and you're actively contributing and that, you know, your ideas are valued. And I think that really came through in the internship. Interim projects feel much more scooped out. Your mentor probably has a pretty good sense of how long these things might take and a good direction in the probably a sense that, you know, you we can get there eventually. I think as a full-timer, you have more time. So things you're working on can have a longer timeline than they often can be more open and did. And I think that's definitely come through. - Yeah, this sort of highlights that actually picking intern projects is actually quite hard because you want to pick something you legitimately want, something that we haven't done yet. And something that I guess the way I like to say that it has a favorable surface area to volume ratio, which is to say you don't have to dig into a billion other systems just to figure out the part that you want to write. You want to be a relatively meaty piece of code that can be written by someone who's pretty new to the organization. And these different properties fight against each other. If we want it and it's well-scoped out and it's not incredibly hard to do, we've probably already done it. So you need to in some ways look pretty hard to find things. And I feel like this sometimes leans in the direction of intern projects that are a little bit more ambitious. It's a little more speculative and we think it's a good idea, but it's not quite to the top of our priority stacks or we're not totally sure that we want it. - For sure. - I'm curious for Gene and Matt, how did you find that same transition? - I can definitely agree with what Grace said about getting back as a full timer and being like, wow, that's a lot of things that I've forgotten that I thought I knew. Just like relearning all of these tools that you got used to as an intern and suddenly that kind of all foreign and completely new to you again is kind of weird and a little bit unsettling when you first come back as a full timer 'cause you think, oh, I did all of this when I was an intern, it's gonna be easy. Then you come back and it's just like, everything I have some muscle memory for some EMAC shortcuts that I can remember from when I was an intern, but that's about it. - Also, we've been helped by changing a bunch of things in the intervening year. - Oh yeah, that's super helpful. They are usually better when we change them. - That is true, that is true. - A funny thing, I didn't come back to the team that I interned on. I did come back to the team that Matt interned on though. - Oh yeah, I didn't go back to the team that I interned on either. So I guess we just kind of shuffled around. - But yeah, I'm actually currently rolling Matt's intern project into production. - That's amazing. - So I guess this is also a thing that- - It's been so long. - It's a little bit of a tricky thing to roll into production 'cause it requires coordination between a lot of groups and things like that. So it's not surprising that it's taken so long. - And I think it does connect to the fact that intern projects, for the reason that I mentioned before, are often chosen to be things that are not super, super urgent. Because if it was really, really urgent, you probably would have done it already. - Have any of you guys been involved in picking projects for interns now? - It definitely gave me a lot of respect for the people who picked my intern project. I went through multiple different projects trying to find something that was both interesting enough, didn't require a lot of context and wasn't super urgent and also wasn't a web UI. 'Cause I guess those aren't allowed for interns. - Wait, that's a funny thing. Why aren't web UIs allowed for interns? - I guess interns don't enjoy writing them. So we're not allowed to propose web UI projects, which was my first project proposal. So I had to go then pick another project. - I didn't know we'd gotten quite to the point of like not allowed to propose, but there's this funny bias that I think people come in with where they think UI work is somehow low class and not interesting. And I think this is totally insane. I think web UIs are actually super interesting. There's often lots of beautiful questions around API design and around how to appropriately build something that both does the task it needs to do and presents a useful UI, but also does it in a way where the code itself is easy to understand and extend and not likely to have bugs. - I think in the outside world, there's a feeling of, oh yeah, we'll just treat this as a low class problem. And if there's someone who doesn't know anything, we'll throw them in a web UI and they can't really get anything wrong there anyway. I do not understand why the world has the set of views about web UIs, but it seems to you and I think interns often come in. They don't always say it because people are nice, but people are often like disappointed when they're asked to work on this part of the infrastructure. - Yeah, it's not like your intern project at Jane Street is gonna be like adjusting the padding between these two buttons. - That's right. - Web UI, right? It's gonna be something we'll conquer. - If your whole project is modifying CSS, I could see why you'd be pretty sad about it. (laughing) So what did you end up finding? - One of the things that we do when we receive an RFQ is we do a whole bunch of validation on it to make sure that like the message we received is well formed, it has all of the right fields, we have enough information to know how to quote it and things like that. And if we find something slightly off about it, one thing we'll do is we'll freeze it. So we won't try to quote it until a trader acknowledges that like yes, this is safe to quote. - Going back to the importance of human involvement in decision making around trading. - So one of the things we wanted to do is we wanted to get more information into our UI to show to traders when they made the decision on whether or not to unfreeze these RFQs and actually allow us to quote. So one of the things in particular, we wanted them to be able to see was what we would quote if they allowed us to quote it. And this required a whole bunch of changes to a couple different systems to sort of reroute things and allow us to actually see these quotes. And so that was going to be the interns project. It didn't end up happening because of COVID and I ended up doing the project, but. (laughing) - So you didn't get to the end to end quite how it worked out. Well, I guess to be clear, COVID caused us not to end our internship program, but to rearrange it pretty seriously. And this year we ended up instead of having every intern go through two teams or mostly because of time constraints, we ended up having interns stay in one team the entire summer in this odd circumstance where everyone was totally remote. - In this case, it was our spring internship where they only did one project and then COVID hit. So then we sent them home. So I had an intern for one day. - I bet at the end of having scope to get out as an intern project, you had a much better idea how to actually get it done. - Yeah, it was great. I'd already thought through the whole thing. - I also wonder how being a full-time or feels different in terms of the kind of decisions that you end up making, right? I think as an intern, a plate is set for you. We figure out what's the thing that you're going to work on and why it's important. And as a full-timer, you end up having more to do and deciding what's important and actually making choices about the systems that you're working on. - It is true that you are often making a lot of maybe perhaps larger decisions as a full-timer, but I also want to say, even as an intern, I think you also have a lot of voice in what you're doing and what you're working on and how you want to design it. I think this is something I really liked about Jane Street's culture, which is that it's super open-minded and it's very collaborative. And I think people are always interested in what you're thinking about and always open to a conversation about if you think something should be changed or if you think something might work differently. This is definitely true full-time. I think this was particularly apparent for me recently because I'm working on a larger project to help deal with the load that we're experiencing. My previous mentor was the one who knows a lot about it and so he's already written up a design doc for this and it's interesting because as a new hire, you're paired up with a navigator who is usually someone on a different team just to kind of get another perspective on life at Jane Street and to feel any questions you might have and to share their experiences. And I was talking to my navigator. He mentioned his intern was working on some supporting client-side caching for Redis. He was saying, "Maybe you can consider using this." I was like, "That sounds cool." And I think this is also kind of an example of the cross-team collaboration that we have at Jane Street. It's always really cool to talk to people and learn about things that you didn't really know were available for and we had already scoped out the previous library we were going to use and we had a sense of it's very well supported at Jane Street, but it did seem like Redis was actually a better choice for our use case and once I had convinced myself of that, I brought it up to our team that we actually have this available as a library now and it was really cool because everyone was super supportive. They were like, "Oh, I didn't know this was available. It sounds really cool." And there are lots of questions that come up especially with newer libraries, but they were pretty excited about it. It actually worked out really well and I think this is actually the final version we're going with. It's kind of like open-mindedness and like collaboration is something that I really, really like about Jane Street. - It's super important to have a culture where you basically can talk about technical decisions in a way where you can propose new ideas and disagree with people and that's a positive experience rather than one that feels like negative and combative. - So how did you guys end up choosing the teams that you're on? What was the whole process of, when you come in as an intern, I think you don't have a lot of choice about where you end up. You kind of find like a good spot for you. But then when you go from that to full-time, I'm curious what the process look like for you figuring out where you're going to be. - I think I actually just got an email from someone in the London office saying, "This is the team we think that you would suit quite well. Here's some details about it and here's a tech talk that Simone gave a few years ago about it. Let us know whether or not you think this would see, 'cause I didn't end up working in either the teams that I worked in as a team. as a full timer, partly because one of the teams is quite small and I don't really know why I didn't end up in the other team, but I guess whatever reason I made sense to put me in the team that I'm in now and I've really enjoyed it. I get to work with you Ron, so I can't complain about that, can I? Yeah, it's very similar for me, except for they also said, "Oh, and we can also set up meetings with a couple of different teams if you want to explore other options," so I ended up doing that and talking to a couple of different teams and then settling on the team that they originally suggested to me. I feel like J3 after an internship does have a good sense of what you enjoy working on and so the recommendations are usually pretty on point there. I had a very similar experience to Jean, so they talked about a few different teams. I really liked both teams that I'd worked on and so definitely it was just in general a hard decision, but I talked to a few different teams and the biggest thing perhaps was just that when people on my old team kind of popped up on my screen, this was after I did this team thing, talked to different teams after COVID hit, so we did this. The fully remote team matching process. Exactly. The fully remote exactly process, and so when they popped up on my screen, I was like really excited to see them and I think a little bit more excited than I thought I would be, and so I think that was really nice. I feel like a big part of the team you're on is kind of the people you're working with and I think I was really excited to see them, really excited to hear what they've been working on, what kinds of projects they have available. So I am back on the same team. These days it's very common for people to do a lot of internships, so I imagine you guys have all worked at some other technical places. I'm curious if you have a feel for how the Jean Street experience of being an intern was different from what you'd seen in other spots before. I guess my previous experience was kind of maybe a little bit unusual because I worked at the same place for multiple summers in a row, even before I went to uni, I worked there and then worked there after my first and second years of uni and so I guess I'd got very used to one particular place and so I wasn't necessarily all that plugged into like the other interns that were doing internships at the same time as me and I guess the big difference for me was being part of this like big formalized internship program where there were events organized and you got to know all of the other interns and for me this was really enjoyable and kind of showed me that it was kind of nice to also find out about different teams in the organization, the place that I had interned at before I ended up working in the same place over and over again just because I knew the people and enjoyed it but getting a broader opportunity to learn about the company was also super cool. Yeah, I interended a pretty big company, extremely big company before coming to Jean Street and I think there's a very large difference in terms of just the size of the code base that you work on as an intern here versus at my other internships. But Jean Street code base is very small, does a mere 20 million line code or something like that? I never knew whether to think of that as small or big as a pen time here at perspective. It seems enormous to me kind of terrifyingly large on some level. Yeah, I guess only small by comparison. But also a lot smaller. Yeah, I guess one thing that I had never done at my previous internships was start writing code in a blank file that was just something that never happened. I was just editing lots and lots of pre-existing systems because there was just so much code that already existed. So getting to start writing something from scratch was pretty cool. I would like to think that if Jean Street's code base grows again by, you know, another factor of 10, that it would still be the case that people would not so rarely start brand new files and write brand new things like there's something about like the kind of modular approach to building things. There's something quite lovely about being able to write a program with a very small number of dependencies, it's like small and easy to think about, and then you take those small easy to think about things and compose them into larger systems. But I wonder if that's purely about size or if there's something else going on about maybe like the nature of the projects or the nature of the kind of work in the different spots. At least I hope as we grow, we don't end up into a world where one never opens a blank file and writes something from scratch. Yeah, I wonder if it was just the types of projects I had there versus here. There seemed to be a lot more freedom to the projects at Jean Street than at my previous internship. I think the need to build completely new things continues on and is a pretty big part of work. So like Matt, for example, maybe it's worth talking a little bit about the zero product project that you're working on. Now that's like an interesting example of like a totally brand new thing. Yeah, basically the goal of zero product fundamentally, it's a way of specifying protocols that you might use to talk between two different apps. So some of it's a how you might use up your seats basically. A good example for someone from not our world like things like protobuffs. It's similar to protobuffs. It's very heavily inspired by cap and proto, which is solving slightly different problems. Yeah, cap and proto is a system for representing messages that was written by the guy who wrote at Google one of the earlier versions of protobuffs. So the guy named Kenton Varda, if I remember correctly. That sounds right. Yeah. So basically, I think, yeah, the easy way for people to think about this is to think about protobuffs, which is probably the thing that people are most likely to have come across. And so the goal of zero product is to solve this problem of have two different applications. Maybe they're running the same version. Maybe they're running different versions. And I would like them still to be able to talk to each other without too much fath of kind of converting between different versions or like a lot of bookkeeping or maybe a lot of runtime code to move things around and figure out what data should have been there. And so it solves this problem of having two apps that maybe have different ideas of what a protocol looks like, maybe because you've added a field to something or maybe you've added another message to your RPC. And it also wants to do this in an efficient way that lets us represent really complicated structures in a way that is still fast to use specifically in our camel. But I think most of the performance improvements made by zero prop would also kind of be applicable in other programming languages. And there are a whole bunch of like clever things that I can't claim credit for that basically allow us to do this process of adding new fields to a message and maintaining backwards compatibility. And I've been here at Jane Street for a year and a month or so now. I've gradually been able to get more and more involved in this project to the point that now I'm the main person working on most of the new functionality that we need to get this project out into the world of Jane Street and used more widely, which is really cool. Yeah, and it's a project that exemplifies some of the things that Grace was talking about about connections between teams, right, because there's a lot of problems you need to solve this effectively. You need an efficient way of representing messages on the wire and nice APIs for interacting with those messages. And so that's involved a lot of collaboration with the market data team with a system they have for generating nice APIs for efficiently dealing with messages of various different layouts. There's lots of brand new pieces of code to write, following what Jane said. So for example, writing brand new pieces of code, one of the things that you did when you started was you wrote the PPX, this kind of syntactic level language extension to make it nice and easy to specify in Okamal messages in this format. There's also other interesting technical challenges around having the specification language of how messages work and being able to do compatibility checks between different layers. So lots and lots of brand new stuff that needs to be written. And at the same time, you also want to take this thing and then integrate it into real live existing software code basis. So it's not like everything is writing brand new pieces of code. There's also lots of work learning how to live inside of large complex code bases. So it's almost like there are kind of two separate challenges. There's this challenge of writing a ton of code in the first place, and it's also like making that live kind of nicely in this broader ecosystem of things that already exist and integrating it into things that we want to use in. This is my challenge for what I'm currently working on in the next few months, I suppose. I think one of the interesting differences between those two kinds of work of building new things and working on extending existing things is that there's a different kind of problem of integrating with other people. For new things, you have to figure out how to convince people to use your shiny new thing and how to solve the problems that they don't even necessarily know that they have yet. And with existing things, there's a lot of work that you need to do to go out and talk to people and gather their understanding of the world and what they think is important and prioritize the 60 million different things that they want from you and figure out from that enormous list the three things you actually have time to do is always a painful difference between how much people want and how much you can actually provide. Yeah, and also we want to make sure that we're not just writing this code really quickly and then we're going to need to go back and change it in three months or something, because we realized we've done it wrong. So we're putting a lot of effort into thinking about the APIs and thinking about the code that we write to make sure that we kind of get it at least mostly right the first time, especially because we're the protocol format. We maybe can't go back and change it in the future because the whole point is that it's backwards compatible. And so we need to be quite careful about that. Yeah, yeah. Versioning is a surprisingly tricky corner of the world. How much experience do you guys have interacting with people in non-developer teams and kind of trying to understand what their needs are, like be it traders or people in operations or compliance or whatever. I talk to traders every day. We have several group chats going on, constant things. What are you talking to them about, like what's the, what's the, what are you trying to achieve with all of that communication? Oftentimes they'll message, oh, I'm confused about why this particular thing happened with this RFQ. Can you explain what went wrong or if anything went wrong? So sometimes it's things like that, sometimes it's like small feature requests. So, you know, can you add this confirmation dialogue to the UI in setting up new systems oftentimes will need to talk to traders a lot to say, hey, can you help us test this out? can you tell us what you want in this particular system? So I also do a lot of that kind of talking. So yeah, so it varies widely. - Sounds like some of that is essentially day-to-day support. And some of that is this process of trying to understand what's actually important. How important do you think the communication with traders is for figuring out that kind of bigger picture question of like what's the next thing that you're supposed to be working on? - Yeah, I think it's definitely impossible to figure out what the next thing we're supposed to be working on is without talking to traders a lot. Because our app is used for trading, we sort of need to understand what the priorities of different desks are because our app is used by a lot of different groups. So we need to understand sort of what they all want, what sorts of new trades that they want to do that we might need to be able to set up and then to sort of figure out how to prioritize the different needs of everyone and then actually start doing them. - I always found prioritization to be kind of like an interesting question. So I'd actually asked my navigator about this and it sounds pretty similar. Like he works on the options desk and I think they work very closely with the traders and he described it as kind of like a nice mix between balancing the priorities of our users and also like having the devs think about what are we in the best position to do? And so I think it's a nice mix of creating a shared context between the two to like figure out how our priorities work out eventually. - I feel like one of the things that is super hard is all this questions of balance, right? On some level you want to provide the stream of features that your users want and figure out what's important to them and to the organization and to the business and move things forward there. You also want to work on things that make you more efficient in the short term. So places where you can clean up technical debt improve the architecture of that piece of the code base. And then the third thing which I think can get easily get lost between those two is sometimes you need to think big about large changes you can make to how the overall system works, whether it be something like, oh, we want to, you know, change completely the tooling that we're using underneath from, you know, we used to be using, you know, we were going to use some internal tool and now we're going to switch to using Redis. That's one kind of bigger change. Or we want to build some completely new architectural piece like Matt's talking about and finding the time and space to do those larger things that impact not just your team sometimes, but lots of different teams is another thing that's kind of challenging to find time for. And I think people who are helping organizing manage the work, I think one of the key things is figuring out how to build an appropriate balance between those different requirements. And I think it's one of the reasons why it's good to have different teams that are kind of focused on different areas and in different parts of the organization. There's all sorts of teams that are attached to this or that infrastructure group or attached to a particular trading desk. And then there are free floating developer teams that are serving more broadly large swaths of the organization. And I think that causes people to kind of pay attention to like different areas of the stack. And it lets people focus on prioritizing smaller scopes of the world where it's easier to think about what's going on. - So like we also work very closely with the infrastructure group risk because they have big ideas about what the big pushes we want to do are. And I think those are always, those meetings are always really helpful 'cause they kind of set like the broader goal that we're working towards. And it's really nice to have these conversations because especially during remote work because our team at least we're oftentimes working on like coordinated efforts towards like a larger goal. And it's really nice to be able to kind of sync up on what everyone is working on and how we're all working towards this one bigger push. And also to hear from risk about the infrastructure side of things and like you know the motivation behind this and also like you know how the different pieces fit together. - So you guys have mostly only said nice things about working here. Are there any things that you found either as an intern or as a full-timer that were like challenging that you wish could be made easier? Maybe things about the intern program that now that you are on the other side of the scale that you're interested in seeing if you can make better or easier? - One funny thing about the internship is that there is just so much going on and we start coding and then we're like, oh no, now there's a class or there's a, yeah, there's like a social, there's like a game like kind of sometimes made it difficult to find like a huge chunk of time to like just be coding. - Do you think we should do it differently? Should there be a little less? - This is like a personal opinion. I think maybe some things we could do is like kind of chunk it up so that it's like in all, together in one block during the day or something like that. I don't know, because it was pretty spread out 'cause I think like you need people to kind of run these classes. So you know, they're very busy. They're schedules, it's hard to schedule every button in. I think like it could be nice to have like, I don't know, like just be always always, it's always, the classes are always before lunch or like something like that. I think it just helps us kind of gain some sense of like, you know, consistency throughout the day. - Right, 'cause like focus is hard and important and having stuff scouted all around can make that difficult. - But we got very good at context switching. So no worries. Lesson learned in the internship. - Honestly, I felt totally the opposite. I really liked all the like scattered breaks throughout the day where you'd go and change it up and do something else. Like I really liked the variety. - I think I really liked the programming too. I think it's just sometimes when you're like, really into the code, then you're like, "Oh, that's when it hits you. "I am late to this intern event." (laughs) - Yeah, I guess I'm gonna complete it and be somewhere in the middle. Like there are some days where it's really nice to have little breaks from work and there are other days where you're like, we're just really wanna do this code. Let me like, I don't wanna have to wait. - I have to say I feel that way way more as a full timer than I ever did as an intern. Now I'm like, please give me a block of time to code. Whereas before I was like, "Oh, there's so many things, it's so exciting." - Do you feel like it's hard to find a block of time to code now that like as a full timer is that, is there too much in the way of distraction of various kinds? - I think it depends on the day. - If I'm doing like phone into you or something, then that's kind of fine, but it's like a phone into you then 15 minutes and some other random thing and then an hour and then another thing it can kind of be kind of annoying. But it's not, it doesn't happen too often, let's say. - To what degree are your days full of little meetings of various kinds that kind of interrupt the flow of work? - We have meetings sprinkled throughout the day, also like I think with remote work, it's just a lot harder to have the spontaneous conversations that might happen in the office. We have like an opt-in kind of social every day in the morning to like see the other people on your router team. But it's like very opt-in, right? So if you're in the middle of something and you don't want to break that flow, you don't have to go to that. - Personally, I got actually a pretty big fan of having meetings 'cause I think it's always interesting to hear about like what other people are working on and things and to talk about kind of larger goals. But I think it's not the worst. I do think that we are actually pretty good at context switching, especially with remote work. I think there's just less distraction going on. You don't hear all the noises in the office. - I really enjoy the noises in the office. - Yes, same. (laughing) - I missed the, I missed the- - Oh, 100% I think it becomes very apparent, especially now that there's like nothing going on at home. But I think because of that, I think you wind up actually kind of just like sitting there and not realizing you've been coding for a really long time, a lot more than if you were in the office. Actually, especially now, I think the meetings that break up the day are kind of nice. I like it to be the case like, you know, when I finish like a particular thing, like come to a larger whole like stop, I would like reassess what I've done. And then that's when I like, you know, check to see if someone's reviewed my code or something, you know, these smaller breaks in the day are actually kind of nice to have too. - The hardest thing for me is not necessarily around meetings, but just around like, oh, suddenly a trader has message and I need to do some support thing now and context switching between those I think is much more tricky because they're random and not planned. So that makes it harder to like plan things out. - That's a good point. - That kind of distraction varies a lot between teams and roles, right? There are roles where there's like a kind of constant overhead of interaction and it's good and bad, right? 'Cause it gives you this kind of very concrete way of hooking into the people who are using your software and you learn a lot from that. And that can be both fun and motivating and you learn a lot about what's going on in the business. And the downside is it can make certain kinds of focused work harder to get done. So you need to balance your day and find time for both of those. - Yeah, it doesn't help that I really enjoy doing those tasks. So then I just drop everything and go do them. - So is there anything else about the internship that you guys feel like you would wanna make better? - Sounds like we just had a great time. (laughing) - Yeah, you guys are clearly too nice. I've clearly stacked the interview with nice people. (laughing) - I think one thing that I would have liked, especially early on in the internship was like, I don't know if it's more feedback or more encouragement or something like that. But I was very unsure about like whether I was doing my project fast enough and stuff like that. And there was like a designated feedback meeting at some point. But I felt like it would have been helpful to like have more periodic updates or something. Maybe I should have just asked for them. But I didn't think to do that. So. - Yeah, and I feel like at the scale of the internship, there are almost no problems to which the solution is. The interns should just ask for the things that they need. Because people's needs are actually really quite commonly shared. And I think this is actually a thing we're constantly struggling to get better at with interns and also with full-timers, just of like giving people enough feedback. Like I think one of the downsides of the friendly and collegial environment is that it takes a real kind of effort of will for people to think, oh, I am managing someone's experience here and I need to think about their growth and their progress and the fact that they might be anxious about the work that they're doing and try and give them feedback and concretely help them along. I think people are generically very helpful, but especially as we grow having people take the role of managing other people as like a serious and first class part of the job and the internship is among other things, a large organization scale management problem. And you know, as we've grown, we try and get better at, but it's like many of the technical things we do. It's like a real hard thing that takes experience to do well. - Yeah, this is something I've kind of found hard base in the internship. and as a full timer is like working with lots of smart people who seem to really know what they're doing and feeling like you know nothing which is kind of reasonable because you only just started right but like you feel as though you should know everything and this is like this is kind of stressful I imagine it's kind of similar to what you you might have at university where everyone seems like they're really on top of everything and in the workplace it's it's kind of similar I guess and it kind of takes some getting used to and it's almost something like I've kind of had to remind myself every so often that like learning new stuff is good and important and it's not like something to be ashamed of yeah imposter syndrome is a real thing and it's one of things that has surprised me over time how poorly these feelings are correlated to how well people are doing like I do not think it is the case that I think the people who are doing awesome are just as often like worried and concerned about other doing as people who are struggling and I think it's a lot of people who have been here for a while and are responsible for many other people just make this mistake of thinking that person's doing great I've said some nice things to them and so presumably they're fine and that is just not how human psychology works right you can even you can say the occasional nice thing to someone about their work and feel positively about it and it doesn't necessarily translate and you really need to take the time and try and get a feeling for where people are because even if you're just saying nice things people will often think oh you're just saying that yeah I don't know how to solve them I think knowing about imposter syndrome doesn't make imposter syndrome go away you just believe you're the only real imposter everyone else just thinks they're an imposter I really like yeah in case you're wondering none of your imposters I can just give you it's just being nice I'm gonna win among us yeah he's I was getting a longer survived two I'm glad I'm not the only one yeah this was something that I spoke to my navigator about similar to what Grace mentioned and he was like oh yeah yeah it's everyone gets this it doesn't help but it's it's nice to know that other people are doing all right well this has been incredibly fun thank you guys for joining me yeah thanks Ron yeah this was super fun thanks for having us yeah thanks Ron you can find a full transcript of the episode along with a glossary and links to some of the topics we discussed at signals and threads.com this is our last episode of the season and we hope you enjoyed these conversations half as much as we did we don't know what's coming next for signals and threads we've got lots of ideas brewing and if you have any ideas you want to share with us you can reach us at signals and threads at jnshoot.com so one last time thanks for joining us