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 prefer using the word "expert" over the word "senior", because the word "senior" is too muddied up with vague notions about what it means for someone to be a "senior" programmer).
Being a young programmer and with very little experience under my belt, I didn't consider my mentor to be particularly exceptional. Sure, he was doing a great job. But having nothing to compare it against, I just figured this is how all programmers perform. Little did I know.
Over the next 12 years I've crossed paths with many programmers -- some great, some not so much. Nonetheless, having worked with programmers of varying degrees of ability allowed me to put that initial experience into perspective. Moreover, I began noticing certain key characteristics, common to almost all expert programmers I had run into:
Craftsmanship
Expert programmers treat their work like the age-old fine craftsmen: quality is king. While average engineers churn out reams and reams of code, expert programmers write code that reads more like poetry than code. Their code has an actual aesthetic quality to it and they believe that "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."-Antoine de Saint-Exupery
Responsibility
Expert programmers really own their work. Expert programmers don't wait around for "sprint planning", to be assigned tasks or for someone else to write "stories" for them. They simply take ownership of the problem and get to work. This also extends to not blindly following rote requirements and just do what their told -- thus passing their responsibility elsewhere . Instead, they constantly challenge the status quo in order to get to the bottom of the situation and to deliver the right solution. They believe in giving their customers what they need, not what they think they want.
Expert programmers make mistakes like any other programmers. But rather than blaming the stars, the weather and the dog next door for their faulty code, they get down to business to solve the bug. They do not dismiss bugs as a "one-off glitch" or (god forbid) write workarounds around them. Rather, they find the root cause of the problem and eliminate it.
Agility
Interestingly, and almost counter-intuitively, expert programmers move very quickly from problem to solution. Despite spending more time on properly designing, writing and testing their solution they usually deliver much quicker than the average programmer. This is because expert programmers rarely start from scratch. Their software is typically built in a way that promotes reusability and extensibility.
Another advantage of the Expert programmer is that they recognize that the vast majority of problems were already solved time and again by other programmers. These solutions can often be found in the form of code libraries, write-ups and best practices. While average programmers will try to solve the problem with the tools and knowledge they have, expert programmers will seek other viewpoints, even if it means getting into uncharted waters.
Passion
Expert programmers are some of the most passionate individuals I have ever met. They love what they do and their job seems to me more like play than work. As a result, programming is not something they put aside when their work day is over. They usually spend significant amounts of their free time reading about, practicing and improving their craft. It is this diligence of practice that often has the expert programmer appear as exceptionally gifted. What usually passes as talent is actually consistent study and practice over a long period of time.
Parting Thoughts
If you run into one of these expert programmers, I have but only one piece of advice to give you: "leach" on to them like your life depends on it and learn everything you can learn. No book can replace the one-on-one experience and the gains attendant to apprenticing under an expert programmer.
Also, if you have a related story to share I'd love to hear about it.
Top comments (8)
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.