Clear, crisp guide. Thanks a lot.

> Those that ask things a lot and can't do much, assign them small tasks.

This is what I'm stuck with. Most times when this happens, I blame myself for not being capable of empowering them. Like you said, I should stop taking this hard and give some time for me as well as the person. Thanks.

Newbie mistake, just try to spent enough time the first time. So you are sure they understand, be less helpful the 2nd time.

"Don't be afraid to filter people out, it happens that some beginners take a toll on the time of the team, because they develop errors / don't test code."

I would put a huge caveat here: Make sure you're deeply involved the process and understand what's going before taking any steps to sideline a programmer that's underperforming.

I worked for 3 years on a project that was underperforming by every metric. Major features were constantly riddled with bugs, rewritten, over budget. We had no way to push our issues above the PM who was throwing the developers under the bus.

The functional requirements would change daily, deadlines would not move, we were getting less and less QA time and 0 time to write or update tests and we were trying to write an integration with a service that was still in development (trying to hit a moving target).

They brought in a BA and kid you not, she quit 3 weeks in. That got the notice of management, finally, and our semi-technical schizophrenic partner on the client side was let go. Before we were able to escalate these issues there was a very different impression of the work we were doing. Afterward it was like black and white. Perfect releases, on time, on budget, and we were delivering real value to the client.

You are talking about your POV as a developer under a bad PM, which is unrelated to the question in my view :)

I agree, it seems harsh because I talk efficiently. But I suppose most of us try to fill in the social aspects according to their situation of the roadmap I "suggested", we are all adults here and nobody will become a dictator and reference my comment, I hope :p

I thought I emphasized the point pretty well: Get involved in the process if you're managing a team of developers and don't just look at metrics. They can be misleading if there is no way for developers to communicate UP to managers or if there are self interested parties between you and your devs.

I've never thaught about a PM that isn't "involved" and only relies on metrics.

My experience is that PM's are part of the team ( and mostly a senior developer), not part of management.

They translate management decisions to their team and take responsibility for it. They shouldn't live in their ivory tower and not know what is going on.

Their experience gives them insights in developer efficiency issues and can solve more advanced problems.

Sometimes they help program, sometimes they are doing infrastructure ( Eg. Cloud management) or deployments.

They did good in the past and now do something else as a way of promotion and encounter new social aspects in managing a team and deploying a project.

Some should better stay developers and some like the challenge.

And if I interpreted the OP well, he's a promoted developer close to the team. And not a hired worker that thinks he's a PM without Dev experience.

Oh, we've had very different experiences relating to project management! I've never had a PM that was a former developer, and in my world senior developers usually act as solution architects without the title, mostly removed from the day to day development tasks unless they're briefing developers on documentation and implementation details.

You make several very good points.

I feel that we could also note that given, say, 10 team members, 2-3 will never become really competent. 1-2 might catch on quickly and the rest will become average given enough time, like 12+ months and with lots of mentoring.

That's a good list but don't mix being independent and being alone.

Beginners shouldn't be left alone for any sort of feature even if they are competent.The first couples of months you need a lot of feedback (more then a stand up every day). I'd say pair programming is the way to go.

He mentioned a new software job. An onboarding "event" should more or less happen existing software /architecture. This wasn't mentioned.

Pair programming is slow. You want everyone to be B+, while they become C's.

I keep the A+'s and migrate the F's to testing or something else.

I never excluded meetings anywhere.

I suppose the normal flow of analysis and explaining inner workings/features is still possible, I hadn't banned them. Just mentioned the stand-up as a recurring event for normal development days

Looks like i am too nice, but i see potential in them :)

I might try to directly help them a bit less.

I like giving them independent tasks that require some thought - but that aren't critical.

I spent a lot of time on helping out others. I'm perhaps a little quick on ruling someone out.

But i blame it on tight deadlines and multiple team members + seeing a pattern that works.

This list is almost perfect, but I’d add “Be patient” to round it out.

And learn them to use documentation and read open source code, would be another one ;)