Hell, I've fixed 1 liner bugs that have taken me a week to figure out.
Hell, I've fixed 1 liner bugs that have taken me a week to figure out.
...
- ask for help
- try to explain how it's supposed to work
- try to explain how it's not working
- Listen to them come up with all the ideas that I've already ruled out
- Try to explain why their preferred idea has already been
ruled out or is not actually relevant to the problem
- conclude they still don't understand the problem or even
how this part of the system works
- go ahead and just solve the problem myself
...
before it's OK to stop "asking for help", and just fix the damn thing?What I've found to be a good middle ground is take some time to think things through myself first, at least in rough strokes. Then have someone else come in and review the work. There is a balance of doing too much vs too little yourself of course, but I don't think there is a hard and fast rule (e.g. 1 day worth) for it.
There are a lot of ways to keep your team updated, but more importantly, it's frankly arrogant to think you can or even should tackle any problem on your own.
When Joe has a problem with X, he should go ask for help, even though he's the one best able to deal with it? Should he ask himself for help?
Can you see the problem with blanket statements like this?
That said, I don't know how to change the situation if you have devs with skillsets that don't seem to overlap much, which seems inevitable for some companies