Early on in my programming career, I was very lucky to have had the opportunity to work with an expert programmer who took me under his wing. (I pr...
For further actions, you may consider blocking this person and/or reporting abuse
Boy this reminds me of how I got started. I remember when I was a lowly IT Technician, the company I worked at had one Developer in charge of the entire company's software. By himself. Sure he liked bourbon and weed a bit more than he should have, but with his workload, I don't blame him. I had messed around with developing scripts and automation to help with my own functions at the help desk (a ridiculously heavy work load and minimal staff was kind of a recurring theme at this company). He got a look at some of the code I was storing on source control, which I shouldn't have been, and approached me to see if I wanted to help him out. He took every spare second he could to help teach me the fundamentals. I had 4 bosses, he had 2, none of them liked that we would take time away from our insurmountable work to talk shop and learn from each other, but he did it anyway. Fast forward to today and I still call him Sensei, though we've long since lost touch. That codebase was his child and it showed and I would not even be a programmer today if not for the excitement he showed to have found just one other person who was as excited about his baby as he was.
Great story! Thanks for sharing!
So, are you saying that expert programmers aren't team players? That's what it sounds like you're saying.
Other than that paragraph, I agree with what you're saying. Not being a team player though, that's a big problem in most organizations.
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
Sure, but the article seems to be putting the expert programmer in the role of product owner. That is possibility in some organizations (and it's a good way to burn out that expert).
However, in others, it is the product owner, product or program manager or the like who has the responsibility and accountability for setting the work agenda and approving it. If the expert programmer goes rogue and ignores their wishes, this will create a bad working relationship. Since product owners tend to be closer to middle/upper management guess who gets the blame? That's when the expert developer gets put on a "personal improvement plan" because they aren't a team player and fired soon after if they don't leave on their own accord.
Nicely written. Sounds like you've had a few good expert programmers you've learned from in the past. Keep up the good work.