Hello, world! Happy New Year! Join us as we talk about what this developer experience thing is all about. For this episode, we're joined by Shanea, Co-founder and CEO at Codesee. We talk about how we shouldn't be relying on our memories when it comes to coding, how visualisation can help make coding more accessible to everyone, the importance of continuous learning and onboarding.
The hosts ▻
Our guests ▻
Things mentioned ▻
Let's chat some more! ▻
Hello, world! Happy New Year! Join us as we talk about what this developer experience thing is all about. For this episode, we're joined by Shanea, Co-founder and CEO at Codesee. We talk about how we shouldn't be relying on our memories when it comes to coding, how visualisation can help make coding more accessible to everyone, the importance of continuous learning and onboarding.
The hosts ▻
Our guests ▻
Things mentioned ▻
Let's chat some more! ▻
Hello. You're listening to the dev X podcast, the place to learn all about developer experience hosted by me, Pauline Narvas.
Mike:And me Mike Nicholas from good pod. It's great to have you join us. We'll be doing a deep dive on defects along with industry experts, asking questions, like what even is Stef ex what is good defects? What is bad defects? And most importantly, why should we care about developer experience?
Pauline:The aim of this podcast is to answer those burning questions and hopefully get you as excited as us about this growing developer experience space. Let's learn together to help bring back joy and speed to our developer workflows and get the job done. Let's do this. Hi, Shanea. Thank you so much for joining us at DevXPod.
Shanea:Thank you. I'm so happy to be here.
Pauline:Could you tell us a little bit about yourself for those who don't know you?
Shanea:Yeah, absolutely. I've been in developer tools for about 10 years. I've been in all kinds of developer focused companies but most recently I started a developer tool myself called Codesee, and we help to visualize. codebases. we do that to allow the developer to quickly understand and master large complex code bases. Not only just for onboarding, but also for code reviews, planning, documentation, et cetera.
Pauline:I wish that was a tool I had when I first started developing. In all of the jobs that I've had in tech as an engineer. I've always been like, there must be an easier way to understand our code base. Cause it's just way too complicated, you know? And I'm a visual learner as well. So this makes sense. Yeah, it does. we're both excited to speak to you today. I tuned into your talk at DevX Conf where you talked about internal developer experience. Excited to deep dive into that.
Mike:I think what do we want to start with is kind of figure out how you got started with developer experience and also what is developer experience to you personally?
Shanea:I think how you get started with developer experience is making sure, it starts actually with empathy of a developer, right? As we've reached this inflection point of kind of development of one, our code bases are like starting to be more complex than ever before. And we all know this because we deal with them every day. But in reality, we're entering into this kind of big code era where we are actually managing a hundred times more code than we did 10 years ago. And at this exact same time the developers are having to have more responsibility put on them than just writing code. The day to day anxieties of getting a feature out the door or writing that thing so that sales could sell it or whatever they have to do. Plus it needs to be secure by design plus it has to be clean and it has to be beautiful and has to be easily readable and maintainable, et cetera, et cetera. All of those things are now being placed on the developer. While our code basis themselves are getting incredibly complex. I think one of our customers has 16,000 microservices, which is absolutely insane. Some code bases are billions and billions of lines of code, and we're expected to know all of the intricacies and complexities and being able to make a meaningful contribution to that code base while it's also clean and secure. So we're just, we've just reached this inflection point where building a developer experience is having empathy for that problem and what it feels like, the anxiety that comes with all of those things coming together of like, Hey, if I don't do something right, I can bring the entire system down. I can had this vulnerability that can bring a company to its knees. And so having empathy for that is I think in my opinion, where do you get started. What developer experience means to me is the the experience, the tooling, the knowledge, the data, having all of the things available to you, the right things when you need it at the right time is developer experience to me. Can you find that one obscure sentence of why something is written this way when you need it. And you know exactly where to look for it. And it's written in clear language for you to actually understand all the complexities that kind of went behind that decision. That's just one example, but that's what developer experience means to me.
Mike:I think it equally applies to people starting with a new project, but also somebody who been at a company maybe for a year or two, or like you're talking about, you know, thousands of microservices. I think even if you spend a couple of years at that company, you'll still every week experience something new that you've never known before and never seen it.
Shanea:Yeah, and I think that's a common misconception because people think so we solve the onboarding problem onboarding to code basis. And that's a common misconception that people think that they're only onboarding for the first two weeks, three weeks at a company. Wholly not true particularly now. We have thought about onboarding as continuous onboarding and made our tool to provide, continuous understanding because that's what you're trying to do. Some team, some upstream team might've made a change. You've worked at that company for five years or 10 years, and you have no idea what this other team has done, but it totally affects your part of the code base. It's still an understanding that you need to have regardless of when you joined or not. I can go on about my theories of like just-in-time understanding or continuous understanding, but I digress.
Mike:It's funny because it even applies to just individual people working on their own little code, because I see with myself a couple of weeks after I write something, I look at it and I'm like."What is this, where does that come from?" And having something that helps me, you know, get that train of thought back quicker. That definitely makes it huge difference.
Shanea:Oh, my gosh. I've heard that from so many people. You have no idea. You're not the only one on this end, the exact same way. I've talked to lots of open source maintainers. We love the open source community and want to be able to support them. The moment you start like doing something else. Now your context has completely switched. And maybe you've even taken a break for a weekend. You'll come back to your project and be like, wait, what was I doing? Why was I doing this again? Or the moment you hit that second person that you're trying to onboard into your code base. Now you've got this issue. Hey, what, why did I do that? Six months ago? Life happens, right? And so we're all human beings that have to remember a lot of things. That's the inherent problem of development. We keep these things in our heads, right? Our mental models of how and why we build code, the intricacies, all of that is the mental models. We create this visualization in our heads and then when you're on a company, that mental model kind of walks out the door with you, but you as a developer keeps all of that database of all the experiences that you've seen. And that's one of the main reasons why the developer experience has been so bad so far. Am I allowed to say that? Because we were keeping all of these things in our heads and that experience hasn't changed in like 50 years.
Pauline:This is all the things that I feel like I've thought of. I've been like, Hey, this isn't fun for me as a new joiner, this isn't fun for me. Just for context, my first ever tech job was at a large telecommunications company that has been running for 30 years. I was thrown into a tech team. They're very thankful for the experience, but I remember feeling that anxiety, the stress of trying to onboard myself, I'm trying to understand how this service relates to this service. If I'm constantly like banging my head against the wall, because I can't figure something out or something doesn't work and I'm constantly blocked, I'm not feeling good about myself. I don't feel good enough to get into flow states. And it's just not a good experience overall. So everything you said that just like really, it started to click for me and it's yeah, of course we should make this more visual. We should make it more accessible for everybody. what you were talking about, like it's not just onboarding, but throughout the whole. If something changes and tech always changes. But that happened to me over the weekend. I was like working on one of my projects that I felt like I wrote with a lot of intention for my future self to remember things, but then I've looked at it after six months. I'm like, I have no idea what I'm talking about. I have to spend, like a good hour. I actually live stream. So I had to spend like a good hour before the livestream. Cause I didn't feel ready to be like, Hey, I did this few months ago and I don't know why it's about, so I spent like a good hour beforehand, just like relearning my code base again. I think what you're doing with Codesee is very interesting.
Shanea:Here's the thing, like I thought a lot about this and my journey to like creating Codesee was just like, anything else. We were trying to launch this feature. We worked on it for like six months and the company that I was working for. We had a bug two days before the launch. And unfortunately the company had a lot of attrition and the developers who were most familiar with that part of the code base, obviously it was a part of the code base that everything touched obviously. All of those developers were no longer at the company and obviously they didn't leave any documentation. There was nothing, it was just completely blank. We kind of went into a panic. There were a lot of obscenity thrown around and I just like, why do we not understand our code? I just kind of yelled it out in desperation. This happens all the time. It wasn't the first or the second or the third or the fourth time that it happened. It was just the most visceral reaction I'd ever heard. Because we're trying to get this really important feature out and then needed we didn't launch it. We'd worked on it for six months and it didn't go out the door. And then what ended up happening later after I left the company, they rebuilt the whole thing all over again from scratch. Like all the codes just gone, they just went, I don't even know that you even wiped it out, but they rebuilt the whole thing again. That happens every single day, all the time. It's sucks and we keep not solving that problem. And I think the thing is that we wear this as a badge of honor that like, oh, keeping all of this in your head, like, that's just the way it's always been done. And if you think about it, other industries, like I try to use this analogy with architecture. It's kind of like if your job was to build uh, building a skyscraper. And the only thing you had is this giant book of sentences that say, Walk one step, take this board, put it here, take one nail and hit it 10 times. And you're just supposed to imagine what the skyscraper is supposed to look like. Why do we do that? It doesn't make any sense to me. That's why we're so dedicated to solving this problem because we're the only industry that doesn't do things without like blueprints or visuals or anything. It's crazy.
Pauline:Yeah, you're so right. You're sort of blowing my mind.
Mike:I would love to answer your question, but I'm still trying to imagine the skyscraper at the moment.
Shanea:I'm also a very visual learner. I studied CS and learn to code and it was excruciating to kind of force your mind, to use the skill spatial reasoning, to visualize all the things in your mind's eye. I cried every day. Every day for months. My growth as an engineer was like, how little I cried that day just because it was so But now, like when you have visuals that's what the diagrams that we make are, they're just the mental model that you're building your head. We just give them to you. The code is the ultimate mental model. It should tell you how it looks. You know, the notion of like your code should be easily readable because you shouldn't comment, but that's a whole, I digress that's I believe that, but it's a whole thing. It's a whole, the whole thing, but like your code should tell you how it looks and what it's connected to you, et cetera. And it should show you a visual of how. Just the same way we expect it to be easily readable and maintain.
Pauline:And that actually takes us quite well into my next question, which is, why should we even care about developer experience?
Shanea:A couple of things we should care because our lives, our entire planet at this point is being run by code tools and the people who make them. It goes beyond just a, to do app or like our favorite game. It goes beyond that. Like our healthcare systems, our billing systems, our finance systems, our economies, all of these things have some intricacy with code or are being disrupted by code in some way, shape or form. And the people making these tools have the experience that I just described. You've no idea what's connected to it or how, or if you've missed a security vulnerability, or there is some file that you missed or some key that you missed run by a third party system that then could be taken down by hackers. All of those things. We're not giving developers the tools to make these tools that then run our lake human existence. That's just like one problem of why we should care. There's all of this, not to mention, you know, social and economical industry that can help more people make more money, change their entire families. These things are really important. They're not enough engineers. And we should make that barrier to entry a lot lower for people with different backgrounds and different experiences to be able to get into development. That's more work for our current engineers, if we don't bring in more engineers to do it. All right. I think that as our world changes, as we, you know, our machines get smarter and smarter and smarter, we need to be able to supercharge how people learn to code. The way that we onboard to code hasn't changed in 50 years. Like since IBM and push cards, machines, right? But we can like detect cancer and we can do all this crazy things, but it just like the way that we onboard to code base is exactly the same. And it sucks. It's always sucked. We just kind of bare knuckles. And we should, we've got a lot of other things to care about. Let's not waste our time onboarding to new code bases. We've got like a planet to save and like that's not spend six months learning this code base so that we can leave in a year.
Pauline:I really deeply care about lowering the barriers entry in tech, because like you said, this is not enough engineers we could use with a lot more to help us like move society forward. If we don't change the bad developer experience and make it more difficult for everyone.
Shanea:I think about the developer experience as this kind of like lock and key into this group of people who have this amazing skill, you know, to create and like that thing functions and has a function. And so that group of people in my head is like a force multiplier. Like you give them the tool, right? You give them the resource and then they can use that to like exponentially create something of value for millions, billions of people. That's really amazing. Because our tooling we've made things so complicated and our code bases are not getting any simpler.
Pauline:That's it? That's it. Isn't it. Yeah. It's only going to get more complicated. We should be, we should have DevX at the forefront of our minds when we build new tools, as everything gets a bit more complex. Absolutely.
Shanea:From a company standpoint, as a developer, when you go to these companies, like that's going to be one of the perks and benefits. And like the things that a developer is ultimately going to look for, like, how do you make my life? I'm going to make your life better. I'm going to ship this thing. I'm going to let you create business value. Like my work directly connects to your business. So how do you make my job easier? In my opinion, in the future, like where we're going, that's going to be a benefit to like the companies will have to abide by, we'll have to make the developer experience better because they're the ones creating the thing that people are using.
Mike:We talked a lot about people new to the industry or learning it is a complete nightmare to start, but I've been doing that for many years. And even for me, when I joined the company, I think having these same struggles again and again, it just gets more and more tiring. The longer I do it. And there are thoughts of like, okay, what do I do? Do I want to change into a product manager role or people like that, just making it worse, for the people who stay in the industry as a developer, because then there's, again, fewer people around that have the experience and the knowledge to be in a position to sit down and say, look, I'm going to change this. For the better instead of just running away and changing your role. So I think what you just touched on is totally on board with that. It's a very important.
Shanea:As someone who's been a product manager, it doesn't get easier on that side because as a product manager or eventually product leader. It's not built into your job description to spend six months getting onboarded to the code base. And so now you've got this one additional level of abstraction that you didn't have time to sit and read the code and make those visuals in your head. So you have no idea why things are the way that they are, but you have to make all of these decisions. And then you have to be able to like direct kind of, and work with your engineering team to like Have them make other decisions based on your decisions. It doesn't get any easier. Even if you switched roles, it's still this, what I call root cause problem. It just trickles out from engineering into other roles. It just gets more and more, abstracted away and it just gets harder and harder to do your job. Kind of how this has happened in my opinion? We've treated code as like this big black box, right? It's a black box. We know it's a black box. If we've got six months to, understand it, part of it. Great. If not like we just jump in and start figuring it out. And we'll learn it over time, but then we've built this entire industry around this black box. Is it happy if it's not happy? Does it send us an alert? Can we poke the black box of give us the information that we want? How do we like turn it around to observe it, right? We built an entire industry or tools around this big black box and what we just need to do. It's cracked the black box open and understand what's going on. And then a whole host of other things and other decisions can be created and a whole host of other actions that we were no longer able to take. Other assumptions that we previously had will just go away. couple of examples, like how many times have you heard? Well, we can only hire so many engineers. At the same time, because you need to onboard them. You need to have that senior engineer to pair with them and tell them all the reasons why do that knowledge transfer? If you had a tool to onboard them, hire as many people as you want, they can move around to different teams. If you find your passion on a different part of the code base, you can quickly get onboarded over there. Cause you have something to help you understand what's going on. It doesn't matter if that team upstream changed something because you can just see how it connects to your part. And before in theory, hopefully they'll see how it connects downstream so that they didn't write it poorly in the first place. Maybe those sorts of things can actually start to happen. And our coding and our products would just get better general.
Mike:Yeah, I think this a long way to go, but I think we're on the right track to crack a box and started looking inside. I'm excited to see what's coming down the pipeline. I think. Many too many years that we've struggled with the same thing. Totally. I think we've covered quite a bit in terms of the challenges and what we can do better. What I'm curious about as well. What is some of the best developer experience that you've experienced, whether that's maybe a recent or a long time ago, that something that you cannot forget, but talk about the opposite of what we've talked so far. What's amazing at this point that you've seen?
Shanea:There's a couple of education tools that I really love and they have a great development experience. There's this platform called code HS. It's like learning to code for high school students. And why I picked that one is because we get this like weird gap of learning to code. There's like coding when you're five or eight, seven. And then you hop into this, like your college level of like, Now, you've got this super dry, really crazy, ridiculous, like texts that you're just trying to read. And it's like 20 years old and like a college textbook. If you studied CS, or you've got the kind of MOOC platform where everyone wants to start you out making a variable. And there's like, Place all of those things together so that you can actually get a well-rounded experience. So you can walk into your first job and actually make a meaningful contribution. Code HS target audience is actually high school students, non five-year-olds, but not college. They really do an amazing job of letting you know play around. They do a lot of videos. They do a lot of really clear, clean, concise explanations. They've made this whole playground that kind of brings together the pieces of all of the parts that you would need to feel confident in all of the areas they've got like crypto and they've got how computers are made and all of the basis, all the way up and around. And, they've got security. I would love to bring that experience to every other part of coding.
Pauline:I started coding when I was like eight and I picked up some books and was I had unlimited access to my parents' computer. So I was just playing around on there. And then when I went to school, then started learning, I did a computing course. And then when I got to university, I didn't study CS. I actually studied biomed, but when I got to university and I was like talking to my CS friends and considering if I should have done that instead and seeing the massive jump, I was like, wow, like, yeah, you have to teach yourself. But the gap just because. Yeah. Otherwise you're just lost you. There's just a massive gap. So yeah, I'm going to check out Code HS and see if I can recommend some people that I know that community.
Shanea:There's a couple of gaps like that, that I've seen. One is kind of just what you mentioned, like getting. Getting from five-year-olds coming to college. There's that gap. But then if you're in college, or, you're learning programming on your own, which I totally did before I went to school. The other gaps after you're done, where like, "Hey, I build a couple sample apps. I build a couple projects." none of those projects have a million people using them and none of those projects are scaled. How do I take that sample project? And then like walk into a big tech company and then like got. Like what's that gap. That's another huge gap that we just leave people in to struggle through.
Pauline:You just reminded me when I graduated from university after four years of biomed, I then went into my first tech job and I was trying to get myself all up to speed. I was self-taught most of the time. I was really excited to start contributing. I joined the team and I was just like, oh my God. I'm helping build a website that is being touched by millions of users because we sell phones. There was like the iPhone launches. Like I just, there's a massive gap trying to understand why. Yeah, the differences. So I'm like coding by yourself or doing small projects to then going into tech. Oh, I have a period of my life where I was just like, this is nothing like coding by myself
Shanea:in my room. And honestly, this is seriously way that we do it today. Like it, like everybody goes through the same thing. And what ends up happening is you either muscle your way through it. And then, you feel like you can wear this badge of honor after, because you also have crossed the chasm of knowledge or you just leave. Because it's so rough and we don't help anybody else. And I think where we're evolving to is that's no longer okay. That we, that you can wear it as a badge of honor, or you just leave the industry at those two gaps. We need fill those and provide again, a better developer experience even on the education side, but it's a constant education, right? It's constantly learning your code base is changing from under you as you're writing the code. It's a constant understanding. It's from the moment you decide, I want to learn to code. Let me check out this thing that everybody's talking about of like programming whenever, however old you are, whenever you start. Like from there, we need to provide a continuous understanding experience, making sure that we fill in all the gaps and that can continue all the way up to your day-to-day professional engineering life.
Mike:It's been very interesting, a few listening along in like two to both of you and sharing your story service very similar. When I grew up in Switzerland, the way education works there is that you go to school until 16 and then you make a decision and you start doing like an apprentice of whatever you want to do. And I was lucky enough at that time that there was an apprentice for software engineers. So I had the opportunity of going to a workplace for a couple of days a week and school for a couple days a week. And I get both experience now after four years of doing that guess where I learned more like everything I learned at my workplace just supported me to get through school. I mean, let's not kid anybody, right. The other way around, like the stuff I learned in school. Algorithms data structures, all that, I guess it came in handy once in a while, but I could have easily just looked that up online or at that time in a book, that's how old I am. It really showed listening to you about how you had that gap between the theory and the actual practices. It's very interesting. There is ways to do it properly, but it's just not very widespread at this point. That's super sad because it would help so many people to have a better experience.
Shanea:I a hundred percent agree. At least the way that like it is in the states, there's another gap of there's like the old school programmers and they're not really old, but there's like a space and time of like the early two thousands programmers versus today. Everyone has their own methodologies and thoughts. It's like one of those things where as we evolve, as our industry evolves our tooling and the types of people and the assumptions that they have needs to evolve. Everyone coding is sometimes very subjective in some patterns. Even if you learn a certain way, then like you have this opinion, but then you'd go to another place and you've got that opinion and just like a whole thing. I'm so excited that you had an apprenticeship. I totally think that we should expand that in other places. I think w at one of my previous roles, I was good friends with the engineering experiences kind of recruiter. They did like a bunch of developer events. And we actually were thinking about doing an apprenticeship program, particularly for exactly that reason.
Mike:I think this is such an interesting situation and time to be in and see how this is going forward. Lots of potential as we already touched on. So I think the other kind of thing we want to talk about is what it's more like a fun thing that you see, or some shout out that you want to give to a person, a tool, like you mentioned, code HS. Anything else that, that like recently popped into your mind? And you're like, I need to tell the world about that this is a good place to do that.
Shanea:Yeah. So in the same education space there's this other education platform called an https://educative.io/. That I also really love. They're cutting to fame was like grokking the system design interview. So I use that, not just not because like I needed to do system design and base, but like I used that early on to get an understanding of how far skills systems work. How does Uber put together their platform? What does all of these things look like? How do you scale something? I thought that the way that they do it, there's a bunch of texts. There's a bunch of videos and diagrams and they mix all of these different ways of learning together. I thought that their approach was also really interesting.
Mike:This is completely unscripted and you and I did not talk it beforehand, but I actually launched a course on educator last year. As you said, it's the reason I launched it there is because it was very different to any other platform where you would have a video course or a blog post, that interactive part: quizzes and things like that. I felt this was a really good place and this whole I learn and I figured, you know, that that's a good place. Yeah. You mentioned that. Yeah. It's
Pauline:funny. Small world. There you go. I was going to say, like, we actually touched on this in our previous episode where we talked about how sometimes, when you're playing a game and you go through the tutorial and stuff where you learn how to ride a horse or whatever, and then after that you can start swimming and climbing or collecting swords or something. And now you know how to do it. And I think that is for me anyway, the best way to learn if the best developer experience, when you gradually feed the key learnings for them, for you to then advance upon.
Shanea:I think I read somewhere that some people are like better audit, like are like normal convention is like, some people are better like reading and some people are better auditory and like, some people are better like visual or like experimenting and playing. What's actually true is what we are all good at is having a mix. If we had a mix whether it's note taking or whether it's like watching a video or hearing it and seeing the transcript next to it or whatever. We are all good at that. Having a mix of types. It's one of those things where like we just have to evolve what we are like previous assumptions of how people worked and how particularly how people learn. That's really what all of this is. Continuous understanding. You're constantly learning things are constantly changing. And now you need to constantly update your mental model of how that thing worked or is working particularly, or will work in future,
Pauline:I'm looking forward to seeing how this all evolves in the future. It's going to be super exciting. What time to be alive? Mike, I actually wanted to flip the question to you. Do you want to shout-out anything fun that you are learning that you learned this week or anything you want to share?
Mike:That's totally spontaneous because we talked about education quite a bit in the episode so far, but there's a tool that a friend of mine put together it's called code road. And what it basically does is it's interactive coding tutorials in VS Code.. So imagine you start up the editor. And then on the right side, you have the tutorials. It's like step one, write this function. And then if you don't know how to do it, you click a button and it pre-fills the editor for you, but you could also do it yourself. And then when you're done, you can run tests against that function to make sure it's correct. Code Road really changes how you can learn. And because we talked about so much of it, about dedication, That's a good one to shout out if you want to get some hands on experience while you're learning something.
Pauline:Yeah, absolutely. That sounds really cool and for me, I'll just quickly share my fun thing of the week and something I learned, and that is the completely not education-related, but the prefers color scheme, CSS media feature, I learned over the weekend I wanted it to be more minimalist and I wanted the user to be at the center of it. I want them to have a good experience. And so if they already have dock mode on their computer and on the iPad and iPhone, I was like, why would they blast their eyes with light mode? So I learned that's prefers color scheme, CSS media feature is a thing that you can add to your project. And it automatically understands your user's preference. And I just blew my mind and I learned that over the weekend and I've put it in every single project I've ever created since.So yeah, I found that really cool. That wraps up this incredible episode. Thank you so much, Shanea. For everything you shared with us today, Honestly mind blown. And I'm really excited to share this episode cause I just learned so much. I've feel like I've just opened my mind a little bit. I'm also going to check out code. See, cause it feels like this is the product that was that I needed.
Shanea:Thank you so much for having me. It was super fun.
Pauline:Thank you for listening to this episode. Do you want to chat some more about developer experience? Why not jump over to our community discord server at gitpod.io/chat. We have a dedicated channel there for us to talk all about developers. And just to make sure that you don't miss the next episode, make sure that you follow us on your favorite podcast platform or subscribe to our newsletter at DevX Digest.
Mike:You can also find out more about Gitpod on start a workspace and tell us about your developer experience. See you in the next episode.