I'm Jake Cahill. Lifetime Pythonista, web scraping and automation expert. Enjoy books. Love my wife, dog, and cat, and think AI and Julia are pretty nifty
Location
Maine, USA
Education
A Master's patient mentorship and insatiable curiosity
I think what the OP is trying to say is that experts are proactive rather than reactive in their response to the product. It's easy to wait around bring told what to do, but trying to think ahead and treating the product (or your piece of it) like a much beloved, but troubled and unstable, friend or relative is what makes an expert programmer an expert. They want the product to succeed desperately and want to give it the best chance to do so. Rather than waiting around and hoping the products proverbial "sobriety lasts this time", an expert will do whatever it takes to help their "friend stay clean and live a productive life". This means getting other people involved, talking with others who are close to the product and encouraging those who are dragging their feet to step up. That, to me, is the definition of a team player.
Proactive is good as long as it doesn't create conflict in the organization with other development teams, product owners or elsewhere.
For example, an expert developer might think (correctly) that a web service is poorly designed and makes changes to it. All of a sudden, the mobile app doesn't work or a vital production system isn't working right. The refactor may have been the right thing to do but it wasn't communicated or timed well. Proactive can't mean going rogue and making changes without regard to how it will impact others.
I'm Jake Cahill. Lifetime Pythonista, web scraping and automation expert. Enjoy books. Love my wife, dog, and cat, and think AI and Julia are pretty nifty
Location
Maine, USA
Education
A Master's patient mentorship and insatiable curiosity
I think what the OP is trying to say is that experts are proactive rather than reactive in their response to the product. It's easy to wait around bring told what to do, but trying to think ahead and treating the product (or your piece of it) like a much beloved, but troubled and unstable, friend or relative is what makes an expert programmer an expert. They want the product to succeed desperately and want to give it the best chance to do so. Rather than waiting around and hoping the products proverbial "sobriety lasts this time", an expert will do whatever it takes to help their "friend stay clean and live a productive life". This means getting other people involved, talking with others who are close to the product and encouraging those who are dragging their feet to step up. That, to me, is the definition of a team player.
Proactive is good as long as it doesn't create conflict in the organization with other development teams, product owners or elsewhere.
For example, an expert developer might think (correctly) that a web service is poorly designed and makes changes to it. All of a sudden, the mobile app doesn't work or a vital production system isn't working right. The refactor may have been the right thing to do but it wasn't communicated or timed well. Proactive can't mean going rogue and making changes without regard to how it will impact others.
I totally agree