The speaker reflects on the changing dynamics of team size required for tasks, noting the increasing efficiency enabled by tools like Copilot and Code Whisperer. With these AI supports, fewer individuals are needed to accomplish tasks compared to a year ago, highlighting a shift in the reality of productivity. The speaker expresses admiration for Copilot's capabilities, attributing a portion of their recent successes to AI tools. They encourage viewers to leverage backend systems and services to streamline work, emphasizing the importance of focusing on showcasing value to customers rather than unnecessary tasks.
Summary
Decision Making and Considerations:
- Discussing the decision-making process for allocating developers to projects.
- Considering factors such as project complexity, team size, and effectiveness.
- Warning against over-allocating resources and the "too many cooks spoil the broth" phenomenon.
Examples and Analogies:
- Providing examples and analogies to illustrate the points made.
- Using the analogy of dividing a Kit Kat bar to explain the limitations of resource allocation.
- Explaining how to approach dividing tasks based on their nature and complexity.
Adaptation and Technology:
- Discussing the evolving landscape of software development and resource requirements.
- Mentioning the impact of tools like Copilot and Code Whisperer on developer productivity.
- Speculating on how future technological advancements may further change resource allocation dynamics.
Podcast
Check out on Spotify.
Transcript
0:01
Hey there, let's see you want to you're building something, you know, implementing some new feature and it's it's sizable and you're trying to figure out how many people to allocate to building this. Let's presume you have like 3 developers available, right? And this is like a really random example, but I'm just trying to convey a message here and hopefully I'm able to do it to some extent.
0:23
Let's see. I have 3 developers available and you want to try and divvy up the work between the three developers. That's one scenario. Let's say you have 6 developers available and you know this is a hypothetical scenario, so let's take a second option. You have 6 developers available and they are able to help right build this because they're they're not actively working on anything else.
0:43
Super hypothetical scenario, but it's it's worth having taking that example. Now what? As a dev manager? As a director of engineering or whoever it is that is leading this dev team, do you what? Let's say you have to make a decision here, right? Do I assign all six devs to this task, to this feature so they can divvy it up?
1:03
Or do I just use three of them right 50% of the team and have the other 50% do whatever it is right, maybe not do anything at all right, but not actually contribute to this this feature? Now, this might sound silly and like a rhetorical question, but it's not.
1:20
Trust me, right? The obvious answer. Quote, UN quote. The obvious answer might seem like, Yep, let's put all six people to do it right. But it's just, you know, you know, like the saying goes, right? Too many cooks spoil the broth. I mean, I've seen this time and again, right? There are certain tasks that you can divvy up a task, whether it's a new app, a feature enhancement, a bug fix, whatever it is, right?
1:43
You you can right? You know you should divvy up the work so more people are, you know, aware of what's going on so one person doesn't have all the awareness and knowledge. I get that part right, obviously, but there is only so much divvying up you could possibly do. Like it's like taking a Kit Kat, right? Since it was just Halloween a couple of days back, I've I guess that's in my mind.
2:03
If you took a Kit Kat, a regular sized Kit Kat, and you want to divvy it up, you can only divvy it up so many ways, right? Maybe. I mean they're big enough, but maybe you can. You know the the simplest way is you take a bar and you know it's the you split in the middle and give it to two people. It's the simplest way to divvy it up.
2:19
Or you can make it like 4 pieces, take split by two and then break the other half by two. It'd be 4 pieces very easily, you know, breakable into four. Right Now if you want to go any further than that, I I don't know how you're doing multiples unless you want to. It becomes crumbles or something, right?
2:35
I don't know if you can divvy it up by 8 pieces unless you had a knife. If you have a knife, OK sure, if you're like George and Seinfeld if I recall correctly, and you could you could actually cut the chocolate and eat it, but maybe 8 pieces. You couldn't do 16. Maybe you pushed it. He might be able to do 16 but can you do 32?
2:53
And again these are these sound like preposterous examples because they are actually, but I want to still try and convey that message. All I'm trying to say here is what I said in the 1st 30 seconds, but I guess I feel like I'm going to move to chat because it's absolutely beautiful outside here. So you you want to be careful how you deviate because I've seen places where like, hey, you know what, there's 65 people available.
3:13
Let's let all of them just jump in, you know, more programming and paper. All of that is, is cool, but it's it's effective to a certain extent in certain cases. You can't, like you can only drink the kool-aid to to, to some extent, right? If that makes sense. So be careful, right? And again, I can't give you how many if it's three or six because it's a completely concocted manufactured example or scenario here.
3:34
But I can give you some recommendations, right? If you're building a user interface, let's say building a page and you have devs available, maybe you're building a React page, for instance, right? Maybe two is is is a good sweet number to start with, right? Somebody's working on the, the presentational aspect of that page, that single page and the other person is helping out with the functional components, right?
3:56
Of the of the exact same React page, for instance, go from there. Don't put like three people or four people on that. It's just going to make it more complicated. Similarly, if you're building an API, like let's say building an endpoint API is too big, but let's say building an endpoint it, it's actually not terribly easy to split an endpoint into any more than sometimes even one person, right?
4:16
Depending on the size of the endpoint, obviously, and your design and which phase of the depth cycle you're in at that point of time. But I think it's it's if one, maybe two people, if if the endpoint's pretty big and complex, then you it's less about the endpoint, right?
4:33
It's the endpoint. It's just the way you're exposing that functionality to your to your users. It's it's more about what the functionality of that endpoint happens to be. And then that itself is a feature, right. And a single endpoint could be a full blown feature and enhancement for all for all that care. So ask yourself, what is the best way to split this, not so much from a developer or a human standpoint, but from a problem standpoint, right?
4:55
How can I break this problem down meaningfully And then you worry about assigning an individual to solving that problem now six months? I mean, I'm, you know, I'm doing this just after. Thanks. I'm sorry, Before Thanksgiving and 2023, let's say how well this, this video ages, right?
5:13
But I want to say this, if I had recorded this video a year ago, I said if you needed two people to do or three people to do something, you would, you would find three people, right? But now if you find two people and with a lot of support with Copilot and Code Whisperer and all that kind of stuff, you might just be able to do it, right?
5:33
So it's about the reality shifting. You require fewer individuals to achieve the same objectives today compared to last year. Perhaps next year, the landscape will change even more. I'll delve into Copilot in another video, but I've truly grown fond of it.
5:50
I've been using it for a few months now, and the speed at which we can develop endpoints, APIs, and features is remarkable. While we want to claim some credit, we must attribute at least 5% of our success to Copilot and other AI tools we're utilizing.
6:27
Thank you.
Top comments (0)