Ben Ilegbodu (Stitch Fix)
Today we talk to Ben Ilegbodu, Principal Frontend Engineer at Stitch Fix, about how he manages to stay close to the code at a senior level. We hear how he arrived at Stitch Fix and what his first tasks were to identify the pain points in customer teams. From getting the IC’s on his side to learning the importance of marketing your ideas to upper management, Ben talks us through his exciting career. He describes how he handles urgent tasks, and why it’s crucial to do the important tasks first. We hear how giving an honest answer to where in the priorities list a task falls is key to inter-team efficiency, and why it’s so important to keep communicating throughout long-term projects. Tune in to find out Ben’s approach to mentorship, and how he plans on motivating high-school students to take the steps to become a developer. Don’t miss out on this must-hear episode filled with practical advice on being a Staff+ engineer.
Links
Listen#
Transcript#
Note: This transcript was generated using automated transcription and may contain errors.
David: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that set staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel Romos and I’m joined joined by my co host Alex Kessinger. We’re both staffplus engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest.
Alex: Yeah, Ben Alegbadu is a principal engineer at Stitch Fix, focusing on the front end platform. Ben has been working on the front end for more than 15 years and it shows, especially when we talk about encouraging alignment among other engineers. This is a great episode, so let’s get into it.
David: Ben, thank you very much for taking the time to join us today. I’m looking forward to chatting with you. Could you please tell us who you are?
Ben: Sure. Thank you for having me as well. So my name is Ben Alegbadu. I’m currently a principal front end engineer at Stitch Fix. I’ve been doing front end development software development for almost 20 years now, but I’ve been focusing mostly on the front end side. And before working at Stitch Fix I worked at eventbrite for almost 5 years or so working on there now front end platform team and before that I was at a startup called Zazzle that does custom T shirts and stuff like that. And that’s kind of where I got into the industry basically. So I was there for nine years or so as well and started off on feature development and realized I liked platform development. That’s kind of where I realized that that’s kind of where my niche has been. So now it’s this fix joined our general platform team which then broke up into different pieces and now I’m on specifically our front end platform team currently.
Alex: Nice. So this is a fun question for me to ask because I actually work with Ben on one of those assistor teams. So from your perspective, what does a staff or a staff plus engineer do at Stitch Fix?
Ben: At Stitch Fix, it depends. So every time with staff plus engineers it’s always a different flavor. Right. So I can speak for myself specifically in that I have a pretty much an equal mix between I guess what I would just call software development, like actually writing code versus not writing code, I guess getting to work with people on various different ways. So there’s lots of code review, there is lots of, hey, I am Trying to figure this thing out. Can you help me? Or oh, we’re about to plan this project. Can you give advice? Or oh, we’re about to plan this project. Let me stop you from doing that gently, of course. Right. So there’s, there’s lots of that and then there’s meetings and all sorts of things around planning and things like that. So I am really interested in staying close to the code. Like I still enjoy it. I still think I have a lot of value to offer there. So I’ve really been trying to position my career so that I don’t all of a sudden find myself, you know, with 10% time coding as opposed to 50%. So I even block off my afternoon. So from 1 to 5:30, I block them off so that no one can schedule meetings during those times. So I have like focus time. Sometimes it’s not development, it’s sometimes it’s I have to do something but usually it’s. That’s the time that I have free to do development time.
Alex: That’s really interesting. What do you think the value you derive from staying close to the code is as you become a more senior individual contributor?
Ben: Yeah, I think the value I have is that I’m still in the code so I am able to understand folks problems in terms of actual development. Like take a specific case. I focus more on react. So I’m having this problem maintaining state in my reaction application. Like I won’t be speaking from theoretical like oh, this is what you kind of have to do. It’s like oh well let’s jump in the code, let’s look at it. You know, I was just working on something like that two days ago, so let’s figure it out. So it allows me to, instead of just being a technical resource that knows things, it’s like I am a coding resource that can specifically pair and help folks with. And then also it allows me, since I’m on the platform team to create capabilities to help others in their development. So I’m able to actually feel the pain as well myself so that I can build proper things for it prevents me from being, you know, get into an ivory tower syndrome and stuff like that.
David: Yep, yep, fair enough. Can you describe just to sort of make it concrete for the listeners, what are some examples of like projects or initiatives that you would have worked on in the past little while?
Ben: Yeah, so at Stitch Fix and as well as Eventbrite, one of the big projects was our design system or component library depending on how you define the term. So the project is kind of this long running, never ending project. And I think the key component is that what gets worked on wasn’t decided by a PM because I didn’t have one or even my manager. It’s like very self driven or team driven. So a big difference is like myself having to figure out either from talking to people or just intuition, like what are the next things that are important to work on, scoping my time to make sure that I get it done properly and the time that folks need it and things like that. So it’s very different than a typical feature development process where there are designers and PMs that come through and figure out what exactly is going to be built and then that gets scoped out and then now I just have to do the implementation. It’s kind of like the whole process of it to make it happen.
David: Since I’ve got you, I’m going to go on a little bit of a tangent here, but one of the things that I find interesting about design systems is managing versions or like updating design systems. Right. Because you’re potentially changing a whole bunch of UI across an entire company or whatever. How do you think about that? How do you approach that? What are like some of the. I realize that this is a little bit. Yeah, it’s a little bit getting into the weeds, but I’m curious to hear your thoughts.
Ben: Yeah, yeah, it goes into the architecture aspect and this is things that I’ve learned over time from making mistakes in the past and running into issues and such. So the double edged sword of a design system is that, oh, you make a change and everybody gets it. Yes. But then you also make a change and everyone gets it and that can also be a problem. Right. So we try to do a lot of things backwards compatible so that you know, they’re not breaking changes as we make changes. Try to have the design changes usually are the ones that are okay. It’s like, oh, we changed the color of this or move these things around and such. But when it comes into functionality of things, that’s when problems are arise. So the benefit though is that by having a component library that’s versioned and having teams use specific versions that they want, then at least it’s an opt in when they want to move up and then be able to make the decision that, okay, I want version 2 of this component and how it works and I’ll take the time to fix my tests and make sure it integrates with my application correctly. So that way teams aren’t getting their apps broken without them realizing, which is Great for stability. But the flip side, the double edged sword is that now teams have to manually go in and make those changes. So if there’s something like, hey, we want to change the button color to be blue instead of red everywhere on the site, just like that, it becomes a multi team effort because we have to now get all the teams to update their apps at a certain time in order to get that to happen consistently. So still trying to figure out exactly what the right balance is of that. Consistency versus stability. Yeah.
David: You also mentioned that like you don’t have a product manager so you’re kind of responsible for understanding how to prioritize what I’m sure is a long backlog.
Ben: Yeah. And growing.
David: Yeah, exactly.
Ben: What’s your approach there for figuring out what to prioritize?
David: Yeah, exactly.
Ben: Yeah. So it, there’s this kind of matrix that I keep in my head of what is prioritized. So I try to do what’s most important and most urgent first. So usually folks will let me know if it’s urgent. You know, you can tell by the Slack messages or the number of Slack messages and such. And then importance is like, what is the feature gonna be for how many people need it, et cetera, et cetera. So I try to do important first, then do urgent next. So lots of people think their thing is urgent. Right. Everybody wants their stuff done. But what I’ve realized over time is that someone can have something urgent and it’s urgent right now, but then four days later, like they never come back to me with the request anymore. And it’s like a month later and I was like, what happened with that thing that you need? So I’ve learned the kind of art of okay, I hear what you’re saying, I’m going to write this down to take care of next week. And if they never come back or never say anything, then I realized it actually wasn’t as urgent and okay, I can work on the other thing that I wanted to work on. So figuring that process out, you know, not trying to dismiss anybody or anything like that, but realizing that if I just jumped on everything that someone said, I would just always be working on the next thing and not completing things. So it’s most important than urgent, then I do the most important thing after that and then if time allows, which it really ever does, then I do the rest of the backlog. So. Nice.
Alex: Working on a platform team, we often have to sort of make decisions for a large group of people and we’re trying to always focus on like, what does the Organization need, What do the folks need? And I’m curious, what is your approach to making sure that when you’re doing the work, the important work, that it’s aligned with what the organization needs?
Ben: Yeah, so the thing about the platform is that our customers are the other developers. So it’s important to stay in tuned with what’s going on with everyone else. So if I’m helping everyone else solve their problems, then I’m helping the business basically. And that’s usually the type of projects that I end up working on. So at Stitch Fix in specific, like we have this front end working group, we call it so because we’re organized in based on domains, I guess, or features that teams are working on, all of the front end engineers, for instance, aren’t on the same team. So we have to have some way to kind of share knowledge between each other. So those sorts of meetings where people present things they’re working on, demo things they’re working on, challenges they’re facing are when my antenna go up to try to see, okay, what’s going on and people, I’ve realized now, unless it’s like really, really terrible, they won’t speak up and say, oh, this is a problem. I have to kind of read between the lines like, oh, wait a second, you have to do this and this and this to solve the problem. Okay. You know, that’s an opportunity to have some leverage to speed things up or to make it easier. And then also what I did when I started at Stitch Fix, which was really helpful for multiple reasons, was that I did a rotation between different teams to just sit with them and work on their projects, basically to get an idea of the domain they’re working in. So I can understand the business, but also try to understand the different problems that the teams have and build relationships. So now as a result, people will come to me with suggestions of small things or small problems they’re running into as well. So it’s really just having my tentacles and everywhere, I guess, to make sure that I’m understanding the needs and the problems of other developers so that myself and the rest of the team can solve their problems.
Alex: That’s really interesting. So a lot of the efforts that you talked about, it sort of seems like one part of it is like going into the organization and trying to offer help in general. So creating the FE working group, doing a rotation with teams, but if I’m hearing you right, that’s also like the tool that you use to make sure that things are going well and making sure that you’re solving problems that people actually have.
Ben: Yeah, exactly. So the rotation especially was mutually beneficial because I was able to come in, offer code review, offer my expertise in any way I can. But then I was also learning a ton about the business and then also about the needs and a lot of those things end up becoming backlog tickets like, oh, we need to make it easier to configure all the different front end tooling and such so that teams don’t spend time, every time they update their dependencies fighting the tools and such because that was stuff that people were doing and not really complaining about because they just assumed, oh, this is the way things have to be. But it turns out it doesn’t have to be that way and we can do things to make that better so that teams can focus on the business logic and you know, their specific domain. So yeah, just trying to be as connected as possible I think makes platform work more effective and also more beneficial because the worst thing about a platform work is doing something and then no one uses it. Right. So I want to make sure that everything that I use is in high demand and very useful.
Alex: Nice. So once you’ve sort of figured out what the organization needs, how do you sort of carry that through to make sure that the all the organization, not just the end users, but sort of like leadership management, they are on board with. You’re like, this is the problem I need to solve. I’m going to go do it now.
Ben: Yeah. So I would say everything. Being a staff plus engineer, upward communication has been my biggest challenge and I’m very good at communicating with all of the other ICs and oh look, he here’s this cool thing you can use in order to solve your problem. But communicating the value of those things to upper management has always been something that’s just challenging to me. Not that I can’t speak to them or even speak in a way that they would understand it. It’s just like I’m so focused on delivering the thing that is and it just makes sense to all the ICs that I forget that I have to, oh yeah, managers, this thing is important because of this. So please give your reports time to work on it and to exercise this capability or director, if we can prioritize this, this is what it will unlock and let me try to figure out a way to quantify the value that you’re going to get out of it. Like all those things just seem like work that takes me away from my actual work, you know, so I don’t naturally want to do it. That’s where having someone like a technical PM or even a technical manager, I wish they would go in and, you know, do those sorts of things and tackle it. But as we get up, as I’m learning, is that that’s kind of part of the responsibility as well. It’s not just delivering the quality product, it’s also marketing it, for lack of a better term. So that’s still a work in progress for me, trying to figure out exactly how to do that best.
Alex: Is there any lessons that you’ve learned that you feel like that really helped you when you’re communicating up, so to speak?
Ben: Yeah, I think just keeping folks aware of what’s going on and the value is really important, especially for something that’s going to take more than a couple of months. Right. So working on a design system, for instance, in the beginning, there’s not enough stuff in it for folks to use. So you really have to take some time in order to make it full enough for applications to be able to leverage it. Well, in that time, it’s all investment. It’s not being realized, I guess, the work. So being able to communicate the value, this is what it’s going to do. And things early on I think will really help leadership get on board and advocate for it and understand the value. Because when I haven’t done that in the past, then it’s like, wait, what are you working on? Is it as important as this thing that’s now on fire? Is it yes or no? And then I’m trying to fight and defend the work and stuff like that. So I’ve learned that in retrospect that communication helps the most. But I will say on a downside, what’s happened is that as I try to share, oh, this is what’s coming, this is this great thing. Now people are excited about it because it is a great thing and they want to use it a month before I actually want them to use it. And now it’s like this negotiation, like, please, no, wait, it’s going to be great. If you use it now, it may not be as great. And that dance is like, once I put it out there, then people want it yesterday. And it’s hard to find that balance of the right timing of it. But I guess I’d rather people be excited about it than not.
David: I was just going to say that sounds like not the worst problem to have.
Ben: Yeah, there are definitely worse problems that are worse than that.
David: Yeah. You mentioned that getting buy in from sort of ICs around you is something that’s, that’s been like easier for you historically.
Ben: Yeah.
David: And that’s interesting because that’s, that’s not always easy either. So do you have any thoughts on sort of like how you approach that? What steps you take to gain buy in from the folks in your team and in the surrounding teams in terms of like getting them bought into what you’re doing?
Ben: Yeah, yeah. I think the advantage is because I tend to focus. I don’t know if this is myself forcing it or this just happens to be the projects I work on. I tend to focus on things bottom up. So it’s like, oh, you have this problem, you have this problem and you have this problem. Well, let’s make something that helps solve that problem. So then there’s like no fighting for it. The fighting is actually, can I get this thing earlier than when you’re ready? Not that I don’t want to do this. Like everybody wants to not have to deal with some things that are a pain point. So if all of our projects are around solving pain points, then once I present like, oh, this is the thing, this is how it solves these five pain points you have, ICs are on board. As opposed to sitting back and saying, you know, we should work on this project because we want to, let’s say, make the site five times faster. And if we do things this way, it’s five times faster than this way. But it’s going to have maybe a slightly negative developer experience or a little be a little bit worse. So it’s going to be five times greater for the client, half times worse for the developer. Then that’s when the negotiation starts to happen because it’s like, it’s great for the client and it’s going to be great for the business, but then it makes our lives a little bit more challenging or even it’s just something different than the way I’m doing it now. That’s when it requires more negotiation. But I typically haven’t worked on those types of projects as much. The cases where I have are. One specific project was we were trying to add instrumentation to our apps to be able to know the impact of the client performance. So folks weren’t really all that interested in taking the time to put that in. And that’s where advocating upwards to management to let them know that this kind of information is important so we can know and make business decisions. So please allow your team members the time to do this. And that’s where it becomes more of the pulling teeth kind of experience.
David: So you mentioned that, like, a lot of your sort of planning inputs are coming from people around you. ICs basically are telling you about problems that they’re having. And you also mentioned that, like, the challenge then is basically like a timing one. How do you resolve sort of like, I don’t know if this is happening or not, but have there ever been cases where, like, multiple people are experiencing pain points that they think are urgent and you have to sort of convince them that you can only work on one urgent problem at a time?
Ben: Yeah, yeah, that happens all the time, actually, a lot of it. If I use the design system as an example, the it’s like, okay, we want to have this new experience and this new component, let’s say, and they want it for their app. So what makes the most sense is that our team builds that component, makes sure it’s accessible, it’s high performance, it’s consistent from design, et cetera, et cetera. That’s like platform work and there’s platform thinking that’s required for that. And then now the feature team can use that to solve their business case. But if that component doesn’t exist now, we’re in a conundrum like, does the feature team go and build it themselves and go on a tangent and have to solve it, or do my team stop doing what we’re doing to build that thing for them so that they can again focus on their feature team work? So sometimes the answer is, we’ll stop what we’re doing because this thing is urgent or it is really complicated and it doesn’t make sense for you all to work on it. Sometimes it’s like, well, we can’t do it this month, but we will do it next month. Like, you can plan on that of us have it done next month, so then you can do your work, plan your work around that. And then other times it’s like, we don’t know when we’re going to get to it. You’re going to have to do it. So the thing I’ve learned is just clear communication, just be upfront and honest, like, yes, I can do it. No, I can’t do it. And if it’s the no and like, the no is unacceptable, then I will hear from my manager or from director, like, hey, this thing is really important. You got to prioritize it over this other thing you’re working on, and that’s fine. It’s like, if that’s the case, then it’s good to know that and share it. But do that instead of just like, oh, yeah, Maybe we’ll get to it and then we don’t, and then they’re kind of stuck for weeks on end. So a lot of it is just communication. Communication. Communication, yeah.
Alex: I’m curious. Something I’ve noticed sometimes about platform work is that you see so many different problems from different perspectives and over time you start to realize like, okay, I’m solving the problem, I’m solving the problem. But you’re sort of like approaching what some might call like a local maximum.
Ben: Right.
Alex: Where you’re like, I’ve solved the problem my best that I can with the tools that we have at hand.
Ben: Yeah.
Alex: But I think if we go over here and we try something a little bit farther afield, I might be able to solve people’s problems and then also make a really big impact on the business.
Ben: Yeah.
Alex: But sometimes making that choice is a little scary for an organization. I’m curious, have you seen a problem like that and like, how. What’s your approach to sort of like moving folks towards this thing that could be a little scary, but could have a really big impact?
Ben: Yeah, yeah, totally. We’re working on a project like that right now, which I’m sure is fine to share. So the way that we build front end apps now is we build them through Rails. So Rails is like our deploy mechanism to our production site so that we have operational excellence around deploying Rails apps and such. But all of our front ends basically are React apps now. So in a sense, our Rails apps are just shells around what really is a React app that we’re delivering. So we have done lots of different things to make that process easy and smooth from a front end development standpoint and having shared configurations for your React app and such. But we’re hitting that local maxima. Like you’re saying we only can deliver a certain type of front end application. So any kind of static app or the like is much more difficult to deliver now. And we’re wanting to have better performance and be able to more easily link between pages without having to hit the server. Like all of these different things, optimizations. We were wanting to build, but we’re having to do it manually. So there are other tools, React frameworks that exist that solve this next JS being one of them. And we believe that if we can build apps on that platform, the types of apps we will build will be easier to develop and be easier to build, features that we believe will be better for our end users as well as SEO and things like that. But going from an app that is a Rails wrapper Around a react app to a completely front end app only is a huge jump, right? And it’s a scary jump. And right when I got to stitch fix, folks were talking about like, why do we need to deliver stuff with Rails? Can we just do front end? And at the time I was like, whoa, we have bigger fish to fry. Like, we can improve what we’ve got now because that is a huge undertaking. We’re gonna have to completely change how we deploy things and all that stuff. But then, Alex, like, your point is, like, we kind of got to as far as we could. So now it’s like we got to take this big leap. So that’s where talking to upper management and pitching the idea and saying, well, this is the value we’ll get, not only will it improve developer experience, but it should improve our site reliability because we’re not going to be hitting web servers, it’ll just be static assets to serve the apps and stuff like that. So we did a whole. Myself and another principal engineer did a whole presentation about why we think it’ll be useful, the value behind it, and pitched it to all of the other ICs. They were on board with it, had a small working group to figure out, okay, what are the 50 different things we need to solve in order to make this possible? And just did a whole lot of due diligence because it’s like, once we tip over to, oh, we’re doing this, we’re signing ourselves up for nine months to a year of work. And that’s a huge investment for the company. So we got to make sure that it’s worthwhile. So I was really against it at first because of the amount of work that it would take, but then realizing that the huge jump we would get and that we could actually piggyback on some existing technology I think pushed me over. And now we’re working towards it and trying to get it up so that teams can use it. And to my point earlier where I said that teams want to use it yesterday, we pitched it to upper management two weeks ago. Last week someone was like, hey, can I be an early adopter of this thing? Like, I really want to use this now. We’re like, ah, I’m glad you do. Like, we were looking for people to use it, but just give us like one more month, please, so we can make sure that it can be successful for you as well. So, yeah, it’s challenging, but I think that’s also how we show our value, is delivering on those big things and having them be successful.
Alex: That’s really cool. Just speaking from my own experience. I don’t often get to use the tools that you build because I work on the backend. But I can tell that you and your team have built a very strong communication tool and I can tell that all the front end engineers feel informed of what you’re doing. And it’s something I aim for in the work that I do to try and create the same experience.
Ben: Yeah, I think if we can have the ICs on board, then they’ll advocate for their managers to have it and such. So it’s not this thing where, oh, this team is making us do this thing. Like that’s what I’m trying to avoid.
Alex: The most, switching topics a little bit. I’m curious, do you have like a specific approach to things like sponsoring, mentoring or leadership? Is that something that you do specifically? You know, and if so, like, what’s your approach?
Ben: So I don’t do it as explicitly as I did before. Like, I used to speak. This is when we could go places physically. I used to speak at boot camps a lot and try to get connected to them and share my experience and things like that and be a resource that way. Now I mostly have one on ones with folks and it’s actually one on ones with more senior individuals. So I guess if you, I don’t want to call it staff minus, but you know, whatever is right below staff. Like folks trying to get to the position where I’m at kind of informal mentoring. So I’ve had people reach out to me and say, hey, can you be my mentor? I’m like, okay, sure. What are you trying to get out of this? Right? Like assuming that I’m just going to be this teacher that’s going to have all these assignments for them to do and things like that, that just doesn’t work. So I think what has worked best for me in terms of how I learn and then also how I share information is just like we’re working next to each other and we get to absorb information from each other. I think that works the best. Unless there’s something specific you want to learn or pick up, then I can guide you to different resources and things like that. So a lot of the way that I share is in our working group or front end working group. I like to present different things I’m working on or things I’ve learned that way. That’s more of the broad lots of people get influenced way. And then I do a lot of code review as well. And that’s how I can Maybe one on one, give advice about how different things in JavaScript work or react work, et cetera. And then in the times where folks want to pair on something and try to figure something out, then that’s also another opportunity there. Cool.
Alex: Maybe we can call them staff, almost.
David: Yeah.
Ben: Soon to be staff, maybe.
Alex: Yeah.
Ben: Yeah.
Alex: Awesome. And so is that something that you do, you know, where you work and outside of where you work, or is it just. I was unclear.
Ben: Yeah. So right now it’s mostly through work, the mentoring and guidance and such. I think once there’s an opportunity to be in person with folks again, I’ll try to pick up meeting with others and such. So one thing I really want to get more involved in is the next generation of developers. So we’re talking about high school, maybe, and really focusing on minorities as well. Getting involved in coding because it’s a lot easier to think you can do something if you see somebody else like you doing it. Right. Even if I’m not specifically a mentor, just speaking at places and showing people that, oh, hey, someone like me, from my background can do this, has done this. Like, I think it can be encouraging. I know it has been for me when I’ve had those opportunities. So plan is to be more involved outside, but currently within helping those that I can.
David: So switching gears a little bit, we’re coming close to time. There’s two questions that we kind of ask everybody. You alluded to the answer to one of them earlier, but we’ll dig into that in a second. But the first question we always ask is, are there any resources that you would point folks toward who are sort of looking to improve their capabilities as a staff engineer, as an aspiring staff engineer.
Ben: So this has actually been something that’s been challenging for me. It’s like. Which I’m glad this podcast exists and things. It’s like trying to see other folks who have been successful in this role who maybe are a step or two in front of me, right? It’s like, I know I don’t want to be a manager right now, and I know I don’t want to be, for lack of a better term, like a technical wrangler, right? It’s like, oh, there’s these projects going on, and I want to make sure that they are successful, right? I don’t want to be that. So it’s like, I know I want to stay close to the code, but who’s doing that at a higher level, you know, than myself? So I hadn’t really had that many experiences of people who were in those positions until the staff plus live conference that happened by. I forget the organization now, was it lead dev? Yeah, lead dev, exactly. Yeah. And that really just opened my eyes up to like other opportunities, what people have been doing and things like that. So if anybody’s looking for resources, I’m not sure if the videos are online for everybody to watch maybe. So I would highly suggest going through all of the talks and watching those because I learned lots of things that I’m already applying in my job right now. One of the main ones that jumped out to me was somebody, I don’t even remember who was saying that as you go up higher, the idea of that’s not my responsibility, like goes away. It’s like in theory anything can be your responsibility. Like even if it’s not in my domain of front end development, like it can still be my responsibility to try to at least get the right people in the room or what have you to get this problem solved and such. So I’ve been looking at it more from a technical standpoint, like maybe solving the fact that our mobile development always lags behind our web development. Like in theory that’s a mobile problem, but really it’s all of our problem and I can help solve that with maybe technology or rearranging people or whatever the case may be. So that understanding kind of has unlocked more opportunities for myself, even though there’s not necessarily hands on coding and such. So I would highly suggest yes. StaffPlus live conference checking out those videos.
Alex: Awesome. So our last question, it’s tongue in cheek. It’s supposed to be fun. How much time do you spend coding nowadays?
Ben: Yeah, so that is the part I’m excited about is I still get to spend probably 50% of my time coding. Coding is still kind of my litmus test of did I get any work done today? Right. So today is actually going to be, I’m in meetings today from 9 until 4. So it’s like, oh, I’m not going to get any work done today, but I still get to. And that’s kind of one of my requirements of whatever it is, that role that I take on is that I still get to do development because I find it still to be rewarding and such. So I try not to take on objectives that would pull me away from it. Even if, so to speak, it’s going to be what will get me to the next level or get me promoted. It’s like I’m all about job satisfaction and enjoying what I’m doing and staying close to the code is still what I enjoy doing so that I’m excited about. Still awesome.
David: Well, Ben, thank you so much for taking the time to chat with us today. This has been a lot of fun.
Ben: Yeah, thank you for having me. I appreciate it. That’s it.
David: Thanks so much for listening to Staff Eng. If you enjoyed today’s show, please consider adding a review on itunes, Spotify, or your podcast or of choice. It helps others find the show and is a really useful signal to us that folks are finding value in this so that we keep doing it.
Alex: You can find the notes from today’s episode at our website, podcast.staffenge.com the website also has our contact info. Please don’t be shy..