Hacker News Reader

Comment by goldcd | Hacker News Reader

I've worked with a few developers who are great - people who get bored of waiting so just build it themselves one evening whilst everybody's arguing over funding/recruiting the team we thought was needed.

Within a team, I think 'greatness' comes in all manner of different forms, all of which are needed. The person who holds the whole software model in their head, and can rattle off the precise changes required to implement a new feature. The person who has an encyclopedic knowledge of all the technologies, and often spotted sat next to another engineer helping them through an issue. The person who mid-way through implementation spots a flaw or an improvement that can be make to the process and comes back offering options for improvement. Of course it's great to have the person who comes back after 2 weeks having written more code than the rest put together - but.. well monoculture is always bad. Wouldn't want a team of them.

View on HN

Oof, sadly this sounds like me... It's hard to delegate, and even harder to trust that it's done correctly. I know this will be my undoing someday, it also drives me insane because it puts extra pressure on myself...

Any suggestions? (Short of let people do it).

Start small and practice. Evaluate how people react to the task size and experiment from there. E.g. don't make someone annoyed by tasks way under their stature grow at the same rate as someone who struggles to deliver.

This goes for clarity, difficulty and size of the task. Don't make someone bad at filling the details do an unclear task. Don't make someone unskilled do a clear yet difficult task. Don't make someone with no track record work on a task for too many days without supervision. Etc.

Unfortunately, people not meeting standards you would will always be a thing unless you're leading people more skilled in the area of expertise. Which brings it's own set of issues.

Realize that others are at other points in their lives. That just because the code does not look the exact way you would write it does not mean it is not bad/wrong. There is always one more refactor to do. There is always more bug. Worry about what you can do. Help others when they need it (not when you want to, this is tricky to not become the knowitall guy).

Delegating is knowing that you need to let go and ingest the fact that they are there to help. Mistakes happen and will happen. But that is part of learning for you and them. If they are not learning that is a different issue. Do not worry about it. You will learn what you can put them on better. But once they learn something they can turn around and help you learn. They can take care of it and you do not have to worry. Delegation is trust. Learning to trust is learning to 'let go' and being open to being 'hurt'. But also being willing to forgive and forget.

I'm not a developer, so maybe not the best person to ask.

What seems to work is where areas of the product are assigned to specific teams - the overly-attached dev can at least see what's happening, provide guidance, without having to do the work, point to wiki that needs updating etc. Over time they'll build trust and can back away a bit.

What doesn't work is if work is given to a different team who just do their own thing and the 'parent dev' only finds what's happened to their baby on the commit/demo. Even if they've done a great job, it ruffles feathers.

Try another career. You'll never be successful in this one. Sorry its harsh but that's the way it is.

Unless you can change that trait, it's going to be a hell of a bumpy road with no payoff.

Reply on news.ycombinator.com