Recently, I attended a Meetup where one of the guests brought up an interesting question. She remarked about how programmers can accomplish a lot, sometimes with less knowledge than we think we need. As fresh novices, it's hard to even know when we are ready to hit the job. This conversation led to the question of natural talent and how this affects our productivity as programmers.
Giftedness is both a dark topic and happy one. On the one hand, it is comforting to think that we might be able to master a skill faster than other people. Who wouldn't want to be gifted, in one area or another? On the other hand, it is uncomfortable to consider the reality that at least a few other people have an advantage over us - and that they will always be better than us at what we do.
This conflict is at the root of the debate about giftedness. Nature VS nurture is another classic example of a debate along the same lines. We don't want to face the fact that other people are better than us just because they won the genetic lottery; at the same time, we want to believe their are shortcuts to learning a new skill.
Programming, like any other skill, divides people into various levels of capability. Given the same amount of effort in any skill, each of us will achieve unique and often radically different accomplishments.
As a beginner, I was able to spot the truly outstanding developers in a room. What I didn't think about is how much their genes, health, upbringing, and other factors impacted their skill level. Perhaps, I thought, they had just been programming for longer than other people.
Quickly, I dismissed that possibility. Looking in other areas of my life, talent was everywhere. Success in sports is largely distinguished alongside body composition, and the strength of the strength of reflexes. Music is another example where natural skill affected one's ability to play.
Soon, I paid more attention to what great programmers and why they had an upper hand. While obviously experience was one of the largest factors, I suspected that there was something more to it. After a few years, things became more clear.
A gifted programmer doesn't necessarily produce more software or write more code than another programmer. In fact, one of their most important skills is talking people out of bad ideas before any code is ever written. That's why having a person like this on your team can have such a huge impact. If you often find yourself writing bad code as a consequence of the awful code base you are stuck with, take a look around. The great developers have already probably realized the management was bad left. Either that, or they are making a lot of money to stay and clean up somebody else's mess.
Outstanding programmers choose the right tool for the job. They are not afraid of technology outside your team's core tool set. If you are lucky enough, one day you will end up on a project with nearly ideal architecture. This is likely the doing of somebody who actually knew what the hell was going on! Comparative skills are one of the primary signs of a great developer.
Great programmers still get hung up on stupid problems. I have never seen an exception to this rule. Forgot the semicolon? You bet. Tracking down a typo in a variable name for two hours? Happens all the time.
It isn't about the minute-by-minute productivity of a developer, either. Some programmers do best with just a few hours a day of focused work. In fact, this is true of almost all programmers. For a good part of the day, we're either distracting ourselves online, or we're tied up in meetings, estimates, and so on. There is no real way to write code for more than a few hours each day anyway. The human mind just doesn't focus for very long, especially when you start looking at variation in productivity across weeks and months at a time. (Side note - this is actually an area where we can often improve by optimizing brain function).
Rather than how many hours we spend staring at our screen, what is actually important is how long the code we write lives in production without causing problems. The quality of an end product is the absolute indicator of skill as a programmer. Everything else is secondary, including your ability to communicate, the speed at which you debug, or how many hours you work each week. Spending 18 weeks on a project that lives for 2 years is better than spending 6 weeks on a project that lasts 1 year - even though it took three times as long to do it.
Finally, I want to mention that there is just a sense I feel when I meet gifted software engineers. Their conversations about topics like code, politics, project life cycle, and career decisions are more far more detailed and expansive than an average programmer.
Obviously, we are not all gifted programmers, and that's OK. Well, it might not feel OK, but we have to remember that the average is the average - and each of us is most likely close to that mark. There is plenty of value even a poor programmer can contribute to projects. Handing off simpler tasks to team members allows the more skilled developers to focus on harder problems.
It's also important to remember that with effort, we can all improve our skills over time. Sure, we can't hurdle the natural barrier - and we may even discover our own. Our relationships with our skills is complex and individual. Some of us lack motivation, and some of us dislike challenge. Some of us like to learn and expand. All of us burn out, and all of us experience the struggles of writing software, and all of us get paid.