4 ms·

1. Daily chats one on one, unscheduled time, with them showing me what they are doing in the editor. This time is used for code review. Sometimes it turns into

1. Daily chats one on one, unscheduled time, with them showing me what they are doing in the editor. This time is used for code review. Sometimes it turns into pair programming for training. Text messages over teams as needed. Open voice channel where I sit on mute a few hours a day they can drop into to ask questions. They can similarly drop in and wait for me to show up if I'm afk or focused on something else. 2. Ad hoc chats with manager, he is hands off other than twice weekly meeting. 3. Twice a week 60 minute meeting with the manager, product owner, researchers, QA, stakeholders. We demo new features to QA, finished features, and partially complete features to stakeholders. Plan new features as needed. 4. 3-5 minute video demos every two weeks sent to all interested parties 5. I block off several hours each day as quiet time for myself to do work. When I run larger teams (+5 engineers) I do not have personally assigned tasks 6. Pair programming, live code review once a day with each dev. I always prefer to hire devs who like to pair program, so ideally they will be pairing and rotating tasks regardless. Also promiscuous pairing, with tasks assigned to a pair stream not an individual. This ensures built in training and code review. No silos or solo work without significant input from a second dev ensures a minimum level of quality, catches issues early, and builds camaraderie. I would say, this project sounds highly risky. I would personally assume only one dev will get any work done, and plan accordingly. What would you do if you knew the whole team would disappear tomorrow? You would set expectations, deliver the most important things first and get it into the stakeholders hands immediately. Do this, and the extra features produced by the other devs will just be gravy on top. Don't try to micro plan out every dev's time feature by feature, instead just ask the customers to order the most important features first and try to get it in their hands. Trying to actually plan a project with a timeline greater than 12 months has a <10% success rate in my experience. Instead try to deliver a first working feature into their hands in 3 weeks. Repeat. Don't ever try to fix scope and time more than a month out, it's effectively impossible. If you could do that, you could just predict the stock market instead and skip all the hassle

sweca 2y ago
Maybe it's just me but this feels like micro management. Especially the daily chats where they show you their work in the editor. Your team's autonomy is being minimized.
- JackMorgan 2y ago
  I wouldn't do this exactly the same way with fully trained Sr engineers, but a whole team of 1-3 year engineers I would certainly do this. How else will they learn? I don't mean this in a snarky way, but what other options are there? Code review is _terrible_ for training. It happens at the worst possible time, when the only options left are rework. Micro reviews like this give them a chance to explain what they are doing and thinking, usually they figure out issues on their own this way. It's a chance to point out edge cases they haven't considered. Lots of times it's a chance for me to notice a gap in their training, like maybe they forgot that SQL migrations need to put into a file and committed, not just run locally in their database. Or maybe they are trying to edit an autogenerated file. Maybe they are building something that already exists because they didn't read through existing libraries. The list goes on and on. The only other ways they can be trained is just by doing and making a huge mess, which is extremely inefficient. Plenty of Jr engineers will never become a Sr engineer without feedback and mentorship, they will just make messes, never improve, get frustrated, and leave the industry. Notice the recent SO survey showing how few devs we have with more than 7 years. I think total lack of training is a big part of this. I don't want them to waste days building a feature totally wrong, then me spend hours writing up a "now do it this way", just to have them rewrite it all. This isn't creative writing, this is engineering. Better to make small nudges along the way, finding gaps in their knowledge, pointing out resources, articles, videos, and tools to get them up to speed. Then over time they get the satisfaction of needing less and less guidance, and being able to provide that guidance to others on the team. Definitely it's possible for this to be oppressive. It's possible for this to be micromanaging. I think the same is true for the style of go away for a week, come back and I'll point out a week's worth of mistakes all at once now that you think you're done. Having done both styles, I think this is far less wasteful and is much more humane. The way I look at it is this, if I'm the code/architecture quality gatekeeper, I want to give feedback as early and often as possible. Imagine you could only run unit tests after you've written all the code. That would be infuriating. I want to run them all the time, knowing very clearly what still needs to be done to finish a project. This is me providing that feedback about quality and architecture as early and often as possible. All that said, I'm probably a lot more aggressive with the size and scope of a project I'll let a Jr dev take on. I've got one now doing a month long series of features that all build to one coherent epic. He's gaining more and more momentum and confidence, needing less and less guidance each day. There's not a change he'd get to build something this huge on a normal team, they'd reserve it for a Sr dev, but because he's able to figure out each day what needs to be done, he's able to build out something really quite impressive. He's written 100% of the code, made a majority of big decisions himself, and still I'm 100% happy with everything that is committed. The second he is done he'll merge into main.

sweca 2y ago

Maybe it's just me but this feels like micro management. Especially the daily chats where they show you their work in the editor. Your team's autonomy is being minimized.

JackMorgan 2y ago
I wouldn't do this exactly the same way with fully trained Sr engineers, but a whole team of 1-3 year engineers I would certainly do this. How else will they learn? I don't mean this in a snarky way, but what other options are there? Code review is _terrible_ for training. It happens at the worst possible time, when the only options left are rework. Micro reviews like this give them a chance to explain what they are doing and thinking, usually they figure out issues on their own this way. It's a chance to point out edge cases they haven't considered. Lots of times it's a chance for me to notice a gap in their training, like maybe they forgot that SQL migrations need to put into a file and committed, not just run locally in their database. Or maybe they are trying to edit an autogenerated file. Maybe they are building something that already exists because they didn't read through existing libraries. The list goes on and on. The only other ways they can be trained is just by doing and making a huge mess, which is extremely inefficient. Plenty of Jr engineers will never become a Sr engineer without feedback and mentorship, they will just make messes, never improve, get frustrated, and leave the industry. Notice the recent SO survey showing how few devs we have with more than 7 years. I think total lack of training is a big part of this. I don't want them to waste days building a feature totally wrong, then me spend hours writing up a "now do it this way", just to have them rewrite it all. This isn't creative writing, this is engineering. Better to make small nudges along the way, finding gaps in their knowledge, pointing out resources, articles, videos, and tools to get them up to speed. Then over time they get the satisfaction of needing less and less guidance, and being able to provide that guidance to others on the team. Definitely it's possible for this to be oppressive. It's possible for this to be micromanaging. I think the same is true for the style of go away for a week, come back and I'll point out a week's worth of mistakes all at once now that you think you're done. Having done both styles, I think this is far less wasteful and is much more humane. The way I look at it is this, if I'm the code/architecture quality gatekeeper, I want to give feedback as early and often as possible. Imagine you could only run unit tests after you've written all the code. That would be infuriating. I want to run them all the time, knowing very clearly what still needs to be done to finish a project. This is me providing that feedback about quality and architecture as early and often as possible. All that said, I'm probably a lot more aggressive with the size and scope of a project I'll let a Jr dev take on. I've got one now doing a month long series of features that all build to one coherent epic. He's gaining more and more momentum and confidence, needing less and less guidance each day. There's not a change he'd get to build something this huge on a normal team, they'd reserve it for a Sr dev, but because he's able to figure out each day what needs to be done, he's able to build out something really quite impressive. He's written 100% of the code, made a majority of big decisions himself, and still I'm 100% happy with everything that is committed. The second he is done he'll merge into main.