Console

Developer interviews

Interview with Josh Leven

CTO, CodeSee - A tool for developers to visually map their codebase.

What is CodeSee and why did you build it?

CodeSee the first code visibility platform. What does that mean? The way I think about it, there’s all of this hidden knowledge that we use to do our jobs. Sometimes, it’s stuff that’s hidden in the code. How do these things connect, what’s the data flow through this feature? Things that you can’t see, but you know when you’ve worked in the code long enough. Sometimes it’s stuff that’s in the docs. A lot of times, it’s more subtle things, like how to work with the code like certain patterns you’re supposed to follow, or processes. Whenever you make a migration you have to make sure the code works before and after. You usually want to deploy it separately. There’s all of this stuff you need to know to be an effective worker on the specific codebase you’re working on. What we try to do is get all of that stuff and make it visible, make it available to the engineer when they need it, to help them do their jobs without having to go hunting for stuff.

I’ve been a developer now for almost 20 years. As I was learning to code, I found that there was this ethos that either you were good at reading code, and building up these mental models, and doing everything in your head, or you just weren’t cut out for coding. People who struggled with that, most of the advice you get is, “Just keep trying,” or, “Keep reading the code,” which is really not the most supportive thing. It’s an actual skill that you can learn, and develop, and be trained on, but I don’t think, as an industry, we do a really good job of helping people through that.

A lot of people, they just white knuckle their way through it, and get better and better at building up these mental models over a long period of time. Either you just read through the code for ages, or you go hunting through the docs, or you turn to a senior engineer, or the architect, and you ask.But I think we can do a lot better. With the right tool, it just doesn’t need to be so much hard work to understand the codebase. That’s why we are building CodeSee.

What does “a day in the life” look like?

We start every day with a standup, figure out what everybody’s been doing, and what they plan to do next. Normally in standups, you’ll ask about blockers, but we ask for friction, because we don’t want to just know if you’re blocked, we want to know if there’s anything slowing you down.

Outside standups, my main priority beyond that is making sure to unblock and support the team. Any given day, it’s going to be whatever’s needed to make sure everybody has what they need to be successful. On a good day, there’s very little of that to do, because people are set up for success, and humming along. Any given day, I may be doing some planning ahead, or working with the design team.

The next thing is code reviews, and if all of that is well handled, I do some coding - take a ticket off the backlog, and work my way through it.

What does your team look like?

We’re not too big of a team right now. There’s eight of us on the engineering team, including me. It’s me running the team, and everybody else reporting to me. On any given day, we’re divided up into two to three person teams, working on a particular feature or project, and we cycle people around.

How did you first get into software development?

When I was 15 I started fiddling around with HyperCard and I realized it had a scripting language under it. I started playing around with that. I started building a chess game in it. I tried to build a “Doom” clone in it, at which point my older and wiser sister said, “Josh, it’s time for you to learn a real programming language.” Java had just come out, so I learned Java 1, and started doing that.

I started with Java, and in school I had to learn Perl, but my first job was C++. Java came back up, and some Python in there, too. I used Django, and my first startup was Ruby. There was Elm in the last company I was at where we actually hired the creator of Elm. There was a lot of Elm there! I got my training in functional programming from people who were much smarter and more experienced in functional programming than I’ll ever be. It was an awesome experience. Now, most of what we do at CodeSee is in TypeScript, but it’s heavily influenced by my time doing functional programming.

If starting something from scratch, I would probably use TypeScript, because I’m the strongest at it right now. It’s been a couple of years, that’s mostly what I’ve been using. If I had the time and space to do whatever I wanted, I’d really love to spend some time with Rust. I’ve heard wonderful things about it, it seems very powerful.

What has been the most interesting development challenge building CodeSee?

There’ve been so many interesting challenges, but the most recent one has been the work we’re doing on service maps. That’s combining the worlds of OpenTelemetry and other kinds of distributed tracing, with instrumentation at the code level, and getting code line or function level information, and bridging those gaps. Almost every user that we’ve talked to over the past couple years has had this gap about, “How do my services work? How do I connect that understanding with my code?” It’s been a really interesting and exciting problem to work on.

One of the biggest challenges with JavaScript and TypeScript, or any language for that matter, the place where the network call is initiated, or received, at the endpoint side, is often not the place in the code that you care about. If you look at the stack trace, it’s usually a few up or down from the entry point. The trick is figuring out, which of those is the one that’s interesting? When someone says, “Oh yeah, this is where my endpoint is defined,” they don’t mean in the Express code, and they don’t mean in the middleware. There’s a very particular place which is very different from the code’s understanding of where it’s handled.

The same thing with where web requests are initiated. If you’re using Axios, you don’t want the internals of Axios. You may not even want the first level of your front end code, because you probably have some layer of abstraction, and that’s not very interesting - it’s one layer above that. That’s an interesting problem in and of itself. What makes JavaScript and TypeScript particularly interesting is, with async calls, the stack trace disappears. Fortunately, on the back end with Node, they’ve done the work to maintain that, and it’s not as big a challenge, but on the front end, we actually have to stitch together the stack trace as it goes through those async calls, to be able to figure out where the stack frame that people are interested in, actually was.

What is the most interesting tech tool/product/thing are you playing around with at the moment?

This is a very interesting question, because my first reaction is, “I don’t have time for that anymore.” However, within the job, certainly OpenTelemetry has been a really exciting thing to explore. It’s been great to see the level of adoption that’s had. It’s frustrating to see the companies who have dragged their feet on that, and forced us to find other ways to access the data. ESBuild has also been exciting, we’re working to migrate a Create React app over to ESBuild. We haven’t achieved it yet, but it’s a goal, and we’ve started to see the promise there, which is exciting.

The thing that I use most day to day is a tool called Tabnine. I don’t think it’s particularly new, but I’ve only started using it the last few months. It’s an alternative to GitHub Copilot. When we tried to use Copilot, it seemed like its guesses were a little ambitious. Tabnine, it doesn’t guess quite as far ahead, but I found its accuracy to be a lot higher. There are certain patterns that I’ll find that I barely need to type it all, and it’ll just figure out. It’s an amazing feeling. So much of the boilerplate that I would normally have to type, now, I don’t have to. It’s very cool. It’s a great application of AI into the daily workflow.

Describe your computer hardware setup

I’ve got a MacBook Pro, we managed to have everyone on an Intel for the moment, but there’s no hope of continuing to do that - we’ll be switching over to the M1’s, or maybe the M2s, next time we upgrade or hire anybody. My MacBook is one of three screens that I have going. Then I’ve got two monitors on arms, one in its normal landscape view, and one turned to the side, in portrait view, which I use mostly for Slack, and to-do items.

I have a Kinesis Freestyle pro split keyboard, which I got because I was getting some arm pain, with my mouse being over on the right. Now my mouse is in the center. I have a Zalman gaming mouse that seems to fit my hand well, and the pain has stopped.

Describe your computer software setup

OS: macOS.

Browser: Chrome.

Email: Superhuman.

Chat: Slack.

IDE: VS Code.

Source control: GitHub.

Describe your desk setup

The desk of Josh Leven, CodeSee

I do have a desk that’s called Uplift, that can go up and down. I don’t go into the standing position nearly as much as I should, but I can. I’ve got a nice chair. Again, dealing with the shoulder and back issues. I work from home, sitting here all the time. It’s good to take care of your body, give it the ergonomics it deserves.

When coding

Daytime or nighttime? Day.

Tea or coffee? Tea.

Silence or music? Usually silence, but sometimes music for focusing.

What non-tech activities do you like to do?

I’m definitely a gamer, I play a bunch of video games. I have a weekly D&D session with some friends. I have a bike, I love to go on bike rides. We’ll do the bike ride across the Golden Gate bridge, to Sausalito and back. It’s a nice 11 mile, total round trip, and going over the Golden Gate Bridge really makes you feel like you’re in San Francisco.

Find out more

CodeSee is a tool for developers to visualize their codebase. The beta release was featured in the Console newsletter on 22 Apr 2021. It was also featured as an “Interesting Tool” on 30 Sep 2021 and 25 Aug 2022. This interview was conducted on 22 Aug 2022.