[karmakaze]

There's different kinds of 'big pictures'. Certain kinds I work to understand, paint and realize. Other kinds I purposefully avoid. Area I'm weak at and choose not to specialize in are office politics, external market forces unrelated to product-market fit (e.g. price wars or shipping crappy stuff first), etc. The kinds I am active in are seeing how different technical solutions merge at higher levels, or very long-term directions of development. An area I'm not strong in but want to get better at is understanding the vertical market and needs. It's hard to learn from second-hand examples long after the act of creation.

Among developers the most common missing big pictures may be things like micro-optimization, over-engineering things 'just in case', inappropriate creation of or elimination of tech debt. Refactoring can be a large sink as it sometimes means rearranging earlier teams' work to fit current team's sensibilities rather than along the lines of where flexibility/speed is needed for upcoming/anticipated areas.

As for suggestions, not focusing too closely on particular aspects, thinking pragmatically with the opinion that each thing "is not important" until you can find solid pragmatic reasons for them to be with some leeway for important things you feel but can't exactly pinpoint. It's not easy, takes lots of practice. Do your work 'in the open', share early, share often, get feedback from both devs and non-devs. Participate in non-technical discussions. Maybe lots of pair programming with someone seen as getting the big picture would be valuable. Then you can experience exactly when, where, possibly how that a picture was recognized and acted upon.

Also realize that even if you only get medium sized pictures, that's ok too. Not everyone has to be good at everything. Lean into your strengths while putting some effort into other areas, don't let it be a perceived/imagined failure.

[rcd2]

Thanks! Good advice here.