this post was submitted on 07 Jun 2023
25 points (96.3% liked)
Programming
3347 readers
1 users here now
All things programming and coding related. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
About ten years ago, I was getting stressed out about it. Someone told me:
Stick to what you know well, if it will do what you want the end user won't care.
If what you know won't do what you want, find the thing that will do what you want and just focus on that. No need to go down a million rabbit holes.
If your team is using something you don't know, learn that and just focus on that and ask for help if you get lost.
I've found this advice to be extremely useful.
I'm managing some devs right now, one of whom is going really slowly. She's determined to do her part of the project in React. I said to her "How comfortable are you in React." She said "Not really, I'm totally new to it. I've used Angular in the past and React is really different." I said "Why aren't you doing your part of the project in Angular?" She had no good answer.
I feel like when you're managing a team you also have to consider the skills you want future devs to have to have. Not saying this is necessarily the case for you (for all I know you already have a mix of React and Angular), but on my teams we have bottlenecks when we need to do work in certain plugins because only one person knows VB6, or WPF, or has the license for the third party library needed to compile the plugin. The dev may not be available for weeks/months because other teams need work done in that tech. If everyone's using the same stack you can just assign tasks to people based on their availability.
I fully agree.
This particular case is a startup in a very sensitive area rushing to MVP that has chosen to imbue it's devs with a lot of autonomy and build a distributed infrastructure where they treat each other as black boxes. This decision was made before me, not that I necessarily agree or disagree, it's mostly working, but I'm struggling to get everyone to document their shit and I'm concerned about bus factor and replacing people / maintaining these systems in the future.
Anyway, I think that was her thinking when she chose React (wanting to learn it) but her progress has been underwhelming at the last few standups (she's built very little while the rest of the team is rocketing along). She's built so little in the last three weeks that she even agreed (today) that pivoting to Angular makes sense. We'll see if she can catch up.
That's fair--the right stack is the one that delivers on time. I wish her good luck and less stressful future sprints
The only ways that this potentially falls short is if you want or need to change jobs and the market is looking for people that know the thing you don't, you're potentially at a disadvantage. Also you may be able to do a thing with the tools you know, but there may be different tools more suited for doing the thing that takes fewer resources or allows resources to be reallocated to other things that customers do care about.