Should Managers Be Doing IC Work And Vibe Coding?

Transcript is auto-generated and may contain errors.

Hey folks, we are going to Experience Dev's subreddit. We're going to be talking about managers being asked to do IC work and this is a sort of an ongoing debate. Like there's obviously different framing and stuff for this. We talked about this on this channel before, but the framing this time is around um AI usage in particular. So um we're not going to be well, we'll see how it goes. I don't imagine I'm going to be too much trying to hyperfocus on I don't know like all these nuances about team size and org size and I don't know like the the state or the yeah like a company I guess like you know if you're at a startup and there's only a few people like odds are you're probably coding kind of thing. I don't think we're going to try to focus on that.

This is um I wanted to talk a little bit more about from the perspective of I think what this post is is really aimed at and to me that's around um like it's kind of called out as like leading by example. So given that a lot of companies are I mean I don't think it's a surprise to anyone there's big push for AI usage for software developers everywhere. Um, I'm sure you've never heard that one before, right? And then so in order to get adoption and get teams using it and stuff, you know, I think there's lots of engineers that are without any push. Everyone like you'll have a lot of people that are give us the tools, let us use the AI, let's go. And then you have others that are very much on the opposite end of the spectrum there going like, hey, like I got the ways that I work.

This works well for me. I've been doing this for a long time and like don't force anything on me. And then of course you have, you know, everyone that's in between those two ends of uh that spectrum and uh I don't have stats to know, you know, how that spread looks. If I had to guess, if I had to guess, I would say there's a lot more uh junior or like aspiring developers where they started learning, you know, over the past couple of years where their like AI adoption was really starting to ramp up more and more as it of course still is. So I had to guess you probably have more people that are new to the industry leaning more heavy on the like give us the AI tools so we can work and again total speculation but my assumption would be that people that have been in industry for a long time statistically you'd probably have more people uh at that end going like hey like don't force anything on me.

Um, but again, I don't know. I think the reality is that there are places where you're going to have AI adoption kind of being more natural in terms of coming from the engineering team being like, we're pushing for this because we want it. We're seeing other places do it or we use it on our our our, you know, home projects and stuff and like we want that like we want the ability to use these types of tools. Um, I think too a lot of motivation comes from hearing and seeing stuff in the media or from talking with people at other companies and and kind of like this fear of well if we're not and they are like am I like basically are we screwed as a company? Are am I screwed in my career because I'm not getting exposure to this kind of thing? And I personally I think that this this last one that I just mentioned is is uh becoming more commonplace uh or at least I'm hearing about it more.

I'm not saying it's necessarily there's been a shift. I think just being exposed to it more where there's this fear of like well if others are doing it and this is the direction everything's going if I'm not actively you know using AI tools in everything I do or building things that are based in AI systems like if I'm not building features using LLM built into them like what's what's this looking like for my career growth so you know there's a whole bunch of different directions on this stuff. But I do think there are places where um perhaps uh even if the engineers are interested maybe the the uptake is is you know air quotes slow here air quotes because slow uh from whose perspective and I I think that there are places where you get a lot of pressure from you know some type of leadership or upper management where it's like I don't know exactly where it comes from.

Maybe it's they have investors, maybe it's whatever. And they need to try and demonstrate like we're we're all in on AI, we need everyone using it, that kind of thing. So, back to this Reddit post, this uh framing in this case seems to be a little bit more of the latter where it's like we are an engineering organization and you know, we're going all in on AI, so we need managers to help lead by example, right? if the uptake isn't happening at the rate we want or maybe we're just starting. I don't know the exact context and I think in in a lot of these videos I try to generalize it a little bit more if I can but it's basically stepping in to say okay as managers like how do we start showing our team like what can be done now I think my personal take is that in general I I do like the idea of leading by example um I think that in terms of like building trust and respect with people.

Um, I think that I think that you can do that over time without necessarily having to like to walk the walk, if that makes sense. So, you know, um, what's a good way to say this? So like there's I think there's people on my on my team that I I do think trust and respect me and they would trust and respect that I can write C code like if I needed to to help the team or something. Um it's just not like part of my role and my responsibilities. So I think that I don't have to show them on a regular basis. Look at me writing C sharp code C like uh I'm proving it to you. C you can trust me. Um but I do think that that kind of stuff helps. So to say that a different way, I think that when you lead by example by walking the walk, you can absolutely help build trust and respect.

But I don't think it is um I don't think it is 100% necessary if that makes sense. So and and the example I was giving with code I think I've been able to at least demonstrate that in other ways right like we can talk about Creat related things and it's not like I'm in the dark. I can be helpful in those conversations uh on code reviews. I can help review C code. uh there's going to be domain specific stuff or like parts of the codebase of course like if I'm not actively coding in I don't know so I'm not leading by example by working on those things but I am able to demonstrate knowledge and experience in other ways so that I can get that trust. Okay. So, in general though, I do really think that it's helpful and can uh I don't know like make a a faster impact, a bigger impact by leading by example.

I say this thing with stuff like uh just like in other situations completely outside of code, right? Like there are times as managers or even as teams uh the example I'm thinking of is like new people starting on the team and we say to them like hey especially if you're remote like hey reach out when you have questions like everyone wants to help you you're never bothering us just just ask right don't let yourself stay blocked just ask for help we're happy to help and that's sort of like saying things um but it's not really like actively leading by example and showing them right so like actions do speak louder than words. I don't think again I don't think that they're uh necessitated, but I do think that they're helpful. So, even in that example, like reaching out to people and showing them like, hey, look, like I'm demonstrating to you that it is okay by taking an action.

I'm reaching out to you, right? To show you that it's okay to like that my time is not uh, you know, restricted from you, so to speak. So do you think that leading by example can help and your actions do speak louder than words? Um so I think like the philosophy around this situation of having engineering managers lead by example for using AI on the surface to me seems like, hey, that's not a bad move, right? I I think I can get behind uh the principle of that. You got to let me into this fast lane. Let's go. Um now how that works in practice I think is maybe a different story and I think that comes back to how that's actually implemented based on this uh this Reddit post and the framing like I said was managers doing IC work right so it's kind of kind of two things happening here one is managers doing IC work and the other and the motivation seems to be getting your team to embrace using AI.

Okay. So it's like one is I think the goal is you know getting your team to embrace AI and um you know as a a general goal and then the mechanism for doing that is supposed to be leading by example but more specifically it seems to be that like therefore the way that you do it is actually by using the AI tools to make like pull requests and contributions to the codebase. So, this is where it starts to break down a little bit for me because I don't actually think that that is uh I don't know like as a general statement I don't think it's necessarily the best approach. I don't think it's an approach that I would recommend in all cases. I think that situationally I think that could be a great thing to do and I think that in other situations it could be a pretty crappy thing to do, right?

Okay, so like here's your typical software engineering answer. Like it depends, right? It always depends. Now, what does it depend on? Let's talk through that. At least from my perspective here, right? I think that um where it can be helpful is like especially if you're already you know doing team contribution where like you're part of a smaller team. Do you have a few direct reports? Especially like earlier stage companies where teams are small or even at a big company if you have a small team and like the service or product or the area that you're working on like you are a smaller nimble team you don't need a manager to be hands off completely from the codebase if you if you have like three direct reports or something right like and it's difficult for me to even generalize that because I don't know what other responsibilities you were tasked with maybe there's a lot of strategy or other things that you're expected to be doing in those situations.

But generally speaking, I think if you only have a couple of direct reports and you know your role is not like entirely forward-looking strategy or things like that, then it probably makes a lot of sense for you to be contributing as well. Why not, right? It's it's kind of like it's like most things when you're when you're small and shit's got to get done like it almost doesn't really matter what hat you're wearing. like you got to switch the hats and you got to if that means jumping into the code, if that means, you know, you're the engineering manager and the your team's CI/CD pipeline is busted and everyone's busy, like cool. Are are you fixing it or are you taking on some of their work to so some, you know, someone else can fix it? You got to jump in, right?

So I think in these types of situations where the manager is already kind of like jumping into things, I think it could be great to uh you know try leaning into some AI and saying like hey look like let me show you that here are ways that we could be using this. Let me show you that by working on like one of these next features. I actually think this could be scoped to AI or there's this bug fix um that we've been stuck on for a while. Can I talk with AI and see if we can get any any other insights? Um, or we've been talking about refactoring this area of the code for a long time and like we haven't really had time to dig into it. Could I run it by AI and see if we can get a bunch of different options here for what a plan could be like to go refactor this?

Right? I think that there are a bunch of different things that you could lean into that would that would be great to try and demonstrate. But I think the reason it it works well is that you're already in a situation where you're doing this kind of stuff. It's just that you're augmenting what you're doing with AI. And so with that said, like the way that I'm thinking about this is like does it need to be the manager? I think No, I think if the manager is someone who's already hands-on, that sure it can be. This could also be one of the senior engineers on the team. This could also be not a senior engineer. It could be someone more junior being like, "Hey, look, I want to rise to the occasion and show like we could do kind of stuff like this." So, I don't think it has to be a manager, but I think what makes it work well is that it's someone who's already sort of in this space like being hands-on.

So, if we flip it, right, and I think to me this is where it kind of falls apart. we flip it and you have someone who is typically hands off in their role. And again, regardless of whether or not you agree with like managers being uh you know, super technical and hands-on or managers being uh mostly hands-off and not as technical uh you know in terms of contributions and stuff like that regardless of your belief okay because I don't want you to be distracted by that. If you are envisioning a manager and in this case it really doesn't matter if it's a manager pick any role that's like hands off not contributing to the codebase. In this case we are talking about a manager.

If you are a manager who is not actively contributing to a codebase and you're saying I'm going to lead by example by by showing you I can do this feature right or I can fix this bug or I'm going to go refactor this code or I'm going to go do this rewrite or whatever it is. If you are not actively doing it, I think that this can backfire like I don't want to say it necessarily like spectacularly, but I think it could. But I think the side effect is that instead of being helpful, it's probably like it's actually probably just more work for your team. So like why, right? Why do I think that? Um, I think that personally that what ends up happening and a lot of us see this when you have AI in your workflows, AI is able to help you move quicker through things, right?

Not always, but like that's the idea. And one of the ways that it does that is by writing code for you, right? And we often see that, and I think most people have had this experience. Again, if you have not or if this changes in the future and you're watching this video and it's old, I don't know. But I think most of us have seen that when we're using AI tools and we say go build this, it's it's usually writing a lot more code than probably is necessary. So yeah, it does it fast because it goes and writes a bunch of code, but I don't know what like the bloat factor is. And I'm a net developer. So by default, like I my my intuition is abstract the out of everything just because that's how my brain works as a C developer like stereotypically. Um but I think that that gets even worse with AI tools.

They're very they're very good at adding more and more and more code and very seems like seemingly bad at by default, you know, cleaning up code to like to keep it concise. it's just like add like slap more stuff in to get it done. So if that's that's the typical case, what ends up happening is you have someone who's not as technical, who's not actively contributing to the codebase. They've now leaned into AI to go get some work done. It produces a bunch of code. This person may or may not fully understand it, but statistically it's unlikely that they're going to understand it as well as another, you know, engineer who's actively contributing to the codebase. So, you've produced a bunch of code. You may not understand it super well. You might see that it's working. You might see there's tests or whatever. Um, and now you're going to go ask your team to review it.

So, so far what you've done is you've created something that is now like a bit of a tax to the team and like sure you you might have like fixed the bug or implemented the feature with AI so it's not like all is lost but you've technically you've technically made more work for people right like you you've just given them something to go review that you don't even necessarily barely fully understand yourself. You should, but you don't even work in the code. So, in my opinion, it's like instead of it being something that's like, look, look, look what I was able to do. You're now kind of creating attacks on people cuz they're like, "Sure, you know, if if Bobby on the team was working in the code and I have to review it." Like yes, that is also a tax I have to pay for Bobby just like I would for any other team member, but at least I have some confidence that Bobby has worked in this space.

And if I had questions for Bobby, like Bobby could answer them and like Bobby and I talked about this ahead of time. Like you're just kind of jumping in producing more code. And I don't necessarily think that that is like tax-free for a team. Okay. So, I don't not implying that it's, you know, guaranteed shitty or guaranteed the worst experience ever for a team. I'm just saying that I can really see this kind of thing backfiring and the intentions are well and maybe the feature of the fix is good, but I don't think that it's necessarily setting people up for the success they're they're hoping for. What is going on in this lane? We got a Oh, we do. There's a very slow person in front of all these cars. Okay. So, I do think the answer's maybe somewhere in the middle.

Um, I figured I have to talk a little bit about like how I'm trying to do some of this and I'll comment on I'll try to show you like both sides that I've been doing and um and that that comes with me acknowledging like maybe some of the things I'm doing are not optimal, right? Like I'm I'm not perfect. I'm not trying to claim to be and I'm always trying to learn and see where I can make improvements. So, um, reverse chronologically. Uh, one of the more recent things I tried to do. Oh my god. I swear this is this is terrible. This person's going under the speed limit in the fast lane. You get to see them. Ready? Let's go. Everyone say hi. Okay, at least they weren't asleep at the wheel. Um, so one of the things I've tried more recently was like a net migration.

And this is still really early, but we had to migrate some stuff before. I say we like people on my team, certainly not me specifically. And we had to go from uh like a donet standard to core or I guess like framework to core. And um so this work is non-trivial for large code bases especially when you have uh complex dependencies and it's a live service that you have to go out across uh tons of machines. Let's say tons of machines. And so, um, doing the work to go from framework to core is probably the heaviest lift, but once you're on core, it's not that it's like bulletproof and it's trivial to go from like one version to the next, but like in theory, in theory, it should be way way way more simple, which is good news.

So now that we're trying to upgrade again because there's always new net versions, I figured hey like let let me try right like otherwise I have to go ask someone on the team to do it and I would would hope to try to do the same thing where it's like can I just ask you know co-pilot like go do this. So I said I might as well try. And so for this case, I actually tried um I'm kind of going against what I was saying, right? I'm not actively contributing to the codebase, right? But I was on over the past couple of years on the poll requests for the other people that were doing the bigger migrations, right? Uh I was on poll requests for people going from six to eight for .NET Core. Um so I know that these poll requests exist. I know that I've seen them before.

I know that there were a bunch of gotchas, but the specifics, no, cuz I never had to do it. So, my strategy was um can I point C-pilot? Oh my goodness. Let me in here. Can I point C-pilot to a lot of these poll requests and basically just give it a lot of context to say, look, like I'm not the expert, but here's a bunch of evidence around how this was done. And so I did. And um I was trying to point out all these things that were gotchas at the time and co-pilot produced this poll request and when I looked at the pull request it was extremely simple and my first reaction was like man I know that there were a bunch of gotchas before and like I I just wanted to help here and seems like now I'm going to be in this

position where I go back to one of one of my sub teams and I'm like sorry like I tried but like you know couldn't couldn't do it someone else is going to have to look at this and um so I said okay before I do that let me ask co-pilot I said hey I I told you about here's a few examples of like things we got to look out for and um it responded back to me and was like I found documentation from another team that has changed some some of how things work for us and and other teams that are doing net migrations that like we don't have to do a lot of that stuff now. And I was like my I'm kind of like taken back like what do you what do you mean like I haven't heard that before. And so I said like where like it was telling me that it read some document or whatever.

I'm like show me like what do you mean it's in some document somewhere? So, it's like here's this web page and I read it and sure enough there was this really big write up that was like hey all of these gotchas like specifically that I was I was talking about it's like you don't have to worry about those now they just aren't a factor anymore because some other team had you know taking care of a bunch of how that stuff works. So now I'm sitting here going, "Okay, I I actually think Copilot figured out that it was like, let me factor in all these gotchas." Oh, wait. I've seen that like it found I don't know how it found this other documentation to be honest. That's the most confusing part for me. And then it's validated against all the gotchas that I called out and pointed it to that they're simply not a factor anymore.

Let's get over couple lanes here. Okay, so I was like pretty shocked by this, right? Because it's a bit of a roller coaster ride for me going, "Hey, I'm going to try to help. Oh, it's all it all sucks. Wait a second. I actually think it worked." And I pinged one of the engineers that had done some of the migration and I kind of gave him some of the evidence around it and I said, "What do you think about that? like does that sound realistic? And he was looking at it going I showed him the document and he was like yeah like if they if they actually address that then I think it really is this simple. So pretty cool because that means the code change is you know maybe I can say okay it's done and we have it documented. someone's still going to have to roll that change out to a fleet of machines, right?

And again, this is going back to that tax idea of like, is that going to be me? Because if it is, that's not a a tax-free thing for the team cuz I'm going to have questions for them cuz I will be like in some cases a new engineer being like, "Hey, what dashboard should I look at? What like what should I be looking at here?" I have some idea but I'd have to follow up with people or I go great I did you know I did the easy part now it's now it's on you so and so on the team you have to go roll this out and monitor it so it's not tax-free no matter how you look at it right if you have seen my other videos where I talk about working at a startup and um prioritization and things you know getting bubbled up and it's like, you know, you do this next, you do this next, and it's randomizing.

Like, this is kind of the same thing except I'm taking something that I'm like, hey, maybe it's lower priority cuz it's simple and I should be able to do it and now I'm in injecting it into the workstream. Yes, I got to do part of it, but So, it's an it's an interesting one, I think. um you know I haven't finished it yet so I can't comment on like overall was this more beneficial don't know but I do think at least the conversation I was having in this case uh with one of the engineers like we've been talking about AI tooling specifically for this kind of stuff and helping out with this so I think at least showing him like hey like maybe we can use this kind of stuff going forward. I think that is a positive conversation getting him thinking, but I don't I don't think that this is an example of the most optimal way to do it.

Going completely to the opposite direction. I talked about this one in some of the other videos recently. Um, and I'm almost at the office here, but instead of contributing to the codebase, I was showing people like, hey, like I can use co-pilot and like vibe code, some some tools that they're not checked into the code that like, you know, we're not shipping it or anything, but if I need some help, you know, investigating things, troubleshooting some stuff with the service, I can use co-pilot on the CLI and I can find this data. I can ask co-pilot questions and it can give me um it's almost like a a poll model instead of like me me searching for the right things. I don't know a good way to say that like if you need to investigate something as an example you need to go see do we have this type of scenario documented.

So we're really good at trying to document things like in terms of covering it but you have to go find it. you have to go see, do we have a document on this? And sometimes keyword search is not as uh helpful as you'd think. Um, so you have to go find it and then you have to go manually carry out the steps that it's it's highlighting in a TSG, like a troubleshooting guide. And that means that like I have to go I'm going to go write a query to pull this data or modify the one in the guide and then it's not working and I have to go ask sometimes ask co-pilot to help me make a better query. And instead of doing that I can use some of these tools now to kind of like selfn the scenarios, right? it can go find the right document for me because it can like do a better job semantically searching for things.

So that's that's super helpful, right? I don't have to know the right keyword. It can say like, hey, there's a few relevant ones and like here's the one I recommend and why. And then it can pull data like it can write the queries for me. I don't have to remember what was that column called or I want to I know how I want to see the data. How do I do that again in this query language? I don't have to think about that. So, it's really cutting out some of the steps that I normally spend time on. So, I was like vibe coding this. And again, like is this the best way to do it? I don't I don't necessarily think so.

But one of the things I was trying to show people on my team was like as someone who doesn't actually contribute to the code base and didn't know, you know, where we get libraries for some of the stuff to access the data and all that, like I could sit here and work with C-Pilot and have it have it answer those questions for me, right? I can use the tools to discover things and then build. Oh man, I can't reach. Um, as someone who isn't an expert, but the I think the the difference here is that I wasn't putting it in front of people saying now you have to go use it. Now you have to go review it. I told them like my expectation isn't like you go adopt this. I said if you like it and you want to, cool. But if anything like I want you to take the concepts and and run with them, right?

If you're like, I think your code sucks, and that's fine. I don't use it. Like, here's here's something I have that is working for me. If you think it's useful, do you want the code? Do you want to see how it's done? Like, what do you want to do with it? Maybe it's literally nothing. And it's an interesting lesson about how something was done, right? You might want to implement it a totally different way. You don't agree with the philosophy of like how some of it works. and at least there's evidence for you to be like, "Cool, now that I've seen that, I I do know that I don't like that way. I'd like to go a different way." So, I'm just trying to provide information. Right? So, um in that example, it was more like here's how we can use tools.

And I did actually get good feedback across different parts of the team where people were saying, "I didn't realize that we could use tools that way." And it's just getting them thinking differently about what what and how they can build. And that's all I want. If they don't want to use the tool I built or whatever, like totally cool. They don't want to use my code, totally cool. I'm just happy that they started thinking about things in different ways. So anyway, that's my take on this stuff. I I don't think that there is a universally right or wrong thing, but I do think that if you are a uh person trying to lead by example and you are usually not a hands-on contributor, be careful because you don't just want to create attacks for people and I think that's what I would kind of highlight here.

So, hope that helps. If you got questions, leave them below in the comments. Otherwise, go to codecanet.com and uh would appreciate too if uh there's folks that are on Reddit. These topics are from Reddit. So, um share the channel on Reddit. I'd appreciate it. Thank you. Take care.