Comment by NicoJuicy | Hacker News Reader

Comment by NicoJuicy | Hacker News Reader

- Help everyone at first.

- Filter out those that don't ask the same things 2x - 3x.

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

- Assign features and more important stuff to the more independent ones.

- Lessen helping everyone, but move to the "only bother me if you're stuck" mantra. Let them work more independently and use the online documentation to find something.

- Have a daily standup, so that everyone knows what they are doing. If they have questions, this is when it (from now on) should be requested.

- Make sure you have an alpha, beta and master environment. Be on top of everything as soon as it enters the beta environment. Don't let them change in production ( except a seperate branch for a bugfix). They develop on the alpha branch or a feature-branch.

- If someone can't develop or work independently, try to change them more to "testing".

- Use kanban / agile.

- 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.

- Try to push the "don't commit, if it doesn't work" mantra.

==

I personally let them develop the entire time and when UX doesn't make sense or has not logical things that keep dragging on. I then spend an evening on fixing it as much as possible and explain the things i've done the day afterwards, without name calling.

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.

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 ;)

Reply on news.ycombinator.com