Even though I know I'm still a junior developer (~1 yr exp), I feel hopeless at times that I'll never approach being 'A' status especially knowing that I have many peers my age that are already far and away better than me. How would I overcome that?
I've seen less-than-enthusiastic programmers who release shoddy work, expend more effort moving work onto other's plates that they'd expend just doing it themselves, let bad ideas stand without a fight, and never bother to keep up with changes in technology.
I've also seen very smart developers who've constantly been taken in by the latest shiny new thing to cross their path, think that testing is for the weak, and have no real determination to get something up and running completely.
If I have to be honest, I would describe very few of the developers I've worked with as "dumb". But many of them are either too passive [2], or lack the determination or desire to really compete a project.
One thing I've done to grow is to not try very hard to gloss over the details. Software is supposed to abstract away details, but it's too easy to think "I'll never learn that." or "Who cares what's under the covers? It just works." Understanding the subtleties isn't just an intellectual pursuit. Knowing the internals of a system allows a developer to know the limitations and strengths of a system, so it can be built upon or even repaired and improved.
1. http://paulgraham.com/determination.html 2. Sadly, in some situations, these are people who've simply been overwhelmed by the bureaucracy of their workplace. Fortunately, we are currently in a job seeker's market, and determined people can find better work conditions.
Another important trait in the A players is that they are good procrastinators. Or as pg says it, they procrastinate to do "something more important."
when i think of A players i always think of the musician who is able to improvise with another A musician instinctively, without needed time to rehearse. A players are able to communicate faster with each other than with B or C players. a so-called "A" player who has a big ego and can't play with others isn't actually an A player, but has managed to convince others (and himself) that he is.
seriously, if you want to become a better hacker, learn how to write a song, it's pure creation (or try painting, but songwriting is more creative imo)
Learn to effectively communicate and then communicate with your peers. You'll never know what you don't know unless you discover it (and there are only so many hours in a day), or you learn from other people. And you'll have an easier time trying to articulate your visions when you can communicate them effectively.
Don't worry about how good other people are. In fact, it's good to surround yourself with people that are more talented than you are, because it's easier to learn from them. Try to surround yourself with people smarter than you are. This is a lot easier if you contribute heavily to OSS or work in a product-focused group or company. It's pretty easy to let your skill set stagnate if your primary responsibilities are writing internal-use-only software.
Regardless, you're spot on.
My silly anecdote: Back in university I used to play pick-up two's volleyball a couple nights a week. At the other end of that same gym, the school team would practice, occasionally overlapping with the pick-up folks.
One day, their practice broke up around the same time as a game of sixes ended, so me & my partner wandered down and challenged a couple of the Team guys to a game of twos. It was quite memorable. 15-1, if I recall, and really not even that close. Pretty humbling, since we could certainly hang against anybody else we'd played up to that point.
But we stuck at it. Over the next couple months, we'd ask for games off those guys from time to time. 15-4. 15-8. 15-7. Then one day we lost 15-12. Fifteen to Twelve. Against a guy with a four foot vertical leap and a guy with one of those crazy olympic jump serves. Guys who were having their tuition paid for playing this sport. Wow.
And it's not like we went back and proceeded to dominate from there on out. Sure, we were better, but not that much better. We were better when we were playing better players. We were only playing that well because we were playing up to their level. It was quite a thing to see.
I've seen this same thing again and again over the years, particularly with Rock Climbing, where a group of people can attack a boulder problem that's way over any one of their abilities, and eventually get not just one guy over the top, but everybody, because of the group energy.
I can't see why it wouldn't be the same with programming.
I noticed this snow skiing too. I had learned to ski when I was four and went multiple times a year every year, but I lived in Texas so it wasn't an everyday event. Then one mogul run I followed directly behind a more advanced skier, mimicking his moves and rhythm, and all of a sudden on that run it clicked -- my skill level shot up several folds.
Early on when I was learning to program, I had a very strong curiosity that made me want to understand how everything works. I think if you have that natural curiosity, it is the easiest way to become a better programmer. As I've gotten older, though, that has waned. In response, I've tried to build habits of investigating things and trying to learn about them when I don't understand them. It is tempting to just use google to find the answer, or "shotgun" it by trying all kinds of random things before you get it to work, but learning how it works is always the best, and it will pay off later.
So, I guess my main point here is to just keep tinkering and reading and getting your head wrapped around all these things so that you understand them well. Then things will eventually become "easy" and intuitive.
There are many people who learned to code starting age 4 or 5 who are having rings run round them by people who learned to code in their 20s or even 30s. Age and experience are only components in a much larger, more complex equation.
While I can't provide much advice on becoming an "A" player, in terms of your outlook, stay eager, stay positive, and stay curious. People quit or fall into ruts all of the time (let's see where many of the dot com era folks ended up..) and still being "in the game" counts for a lot over the years. Everyone has doubts or moments where they feel out of their depth.. you just gotta keep plugging on.
Anyone who thinks they are an A player quite frankly isn't.
In Coders At Work (http://www.codersatwork.com), Ken Thompson says, "When I was 30, 35 years old, I knew, in a deep sense, every line of code I ever wrote. I’d write a program during the day, and at night I’d sit there and walk through it line by line and find bugs. I’d go back the next day and, sure enough, it would be wrong."
Building things without deep understanding may produce a program, but it won't get you to A. Building understanding gets you to A. This is a deliberate process that takes time and work. You may not get all the way to A, but it will put you on the right path.
Roughly from memory: A's are smart, get things done. The important thing is: An A player in one role may not be an A player in another role. If you put your best programmer at your retail store, you're probably going to have a bad time.
How do you overcome it? Find your passion, make sure you work with others that are A players (one trademark of A players is that they gravitate together), work on your skills and study peripheral ideas that could be implemented. If you're doing the above then youre probably an A player, if youre on Facebook half the day or complaining that someone didnt refill the coffee pot then you're probably not an A player in the role that you are in and you need to decide to train up or move somewhere where you can be an A player.
In a way, a bit of neuroticism about your skill will help you. Complacency is a killer.
If you feel like some of your peers are ahead of you, you can try diversifying your skills. Most other 'A' developers suck at things like UX, design or even basic human interaction. Surpass them on those areas. By being a B as a developer + B as a UX person + getting things done, you will be welcome in an all A's team.