A bit of a meta question: As someone who feels like a 'B' or even 'C' at times, what would it take to become an 'A' player? Is it predicated on pure talent alone, hard work, or experience?
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?
Fake it 'til you make it. Throw yourself at problems that you think are over your head. If you care and you want to do good work you'll figure out a way to get something done. Especially if you have a good mentor or someone that can guide you to answers to hard questions or take you under their wing.
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.
Are you sure "fake it til you make it" is the correct term for this idea? I'm familiar with the term, but usually in a different context.
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.
Playing up to your opponent's level can happen in tennis too. One of the factors I think might be coming into play, especially in a sport like volleyball or tennis, is that your opponent is directly across from you and their play provides a mental model for you during the game. You can subconsciously mimic what they do, and their actions during the game act as a constant reminder for how to play well.
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.
If you're interested in anecdotes about this, consider reading http://thedanplan.com/blog/ - Dan quit his job to learn to play golf, something he'd never done before. Currently he's at 3000 hours of practice...
That last bit is crucial - surround yourself with people smarter than you - otherwise you'll spend most of your time solving complex problems in inefficient ways, which could very much work against you.
Yes. A thousands times, yes! Some people find themselves to be the smartest person in the room and think, "I've made it!" Others, in the same situation think, "Time to move on..."
I believe that the top trait in A players is the same as in the top founders, which is determination [1]. That determination often manifests itself as the desire to understand how something really works, rather than glossing over the details, the drive to learn a new language well enough to use it to implement ideas, to take on the learning curve for a new tool or system, to automate something, or to test their code before releasing it into the wild.
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.
I don't really think determination is the magic ingredient. Personally I think the process of writing software is very similar to writing a song. (is anybody here also a songwriter)? Because if you try to write a song before you're ready, it just doesn't work no matter how hard you try, but once the idea has fully formed inside your head, it's as if the song writes itself, i think software is the same way. i remember hearing jobs talk about how a lot of the A players would also write poetry.
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)
That's a pretty romantic way of putting it, but I agree mostly. You're dead on about so-called 'A' players who have big egos and can't communicate or play well with others; They might even be 'A' in terms of technical expertise but that's not the whole picture.
Good stuff, dabent. I agree; Abstractions are valuable tools, but it's important to know whats underneath the abstraction, for when the abstraction leaks, or when it's the wrong tool for the job.
That's not developers, that's life. Determination is the top predictor of success in... anything. It would even be a tautological statement if we couldn't look at others and predict determination levels before the success happens.
My experience is somewhat limited to places that probably don't have the best developers in the world, but I think one of the major things I've noticed in people that I would consider to be mediocre programmers is a lack of desire to understand how something works. They just want to get the thing they need to work, and often times this lack of desire to understand how something works extends to their own code. If you strive to understand how your own code works, you will be much more likely to notice the bugs as you think through the flow.
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.
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.
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.
Questioning yourself is the first instinct of an A player. They don't believe they have all the answers, they believe that they are frauds in a lot of ways because they see the large picture and realize that they cannot hope to know all that is required to be an expert in all areas. Instead they become proficient in understanding the thought-processes that lead to expertise in multiple "specialized" fields and apply it to all areas of endeavor.
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.
You could almost argue that those who put the time and work in, are by definition the 'A' players. Even if you're not top dog in terms of technical expertise; If you've got the hunger and passion to know more you'll almost certainly succeed over time.
Look for a book called Topgrading, it's a methodology and defines A,B and C players.
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.
Key question: Are your peers better than you due to experience or talent? In other words have they also been doing this for a year or several years? If they've been doing it for several years even though they're the same age as you they aren't your peers. By the way I suggest you check out the 10,000 hour rule: http://www.gladwell.com/outliers/outliers_excerpt1.html
I'm where oacgnol is at too. Just as an addendum to what he said, are there any pro programmers here who went from C to A? How much time did this take you? I feel like I struggled way too much to much to get basic computing concepts - netmasks, bitshifts, c pointers... Don't even get me started on how much javascript confounds me! :-D
There will always be people better than you, no matter how good you are. Realize this, and try to learn from them. While I can't tell you if you have the raw talent, constantly trying to improve is important.
In a way, a bit of neuroticism about your skill will help you. Complacency is a killer.
The best way of becoming an 'A' player it to work closely with some of them. Accept a lower salary to be able to do that if necessary.
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.
Try not worry about how you stack up in absolute terms, and think more in terms of relative accomplishments. It helps me when I have these thoughts too.
Hmm, "fake it till you make it" is not quite right - you can never "make it". You need to always learn AND learn how to learn as you go.
I agree that you need to let others know that you're an A (even if you think you're a B or C), but if internally you believe you "made it", you're already falling down, IMO...
Talk about stuff as you learn it (at your local user group or whatever). That way it forces you to consolidate what you are learning - plus you become viewed as an expert by the people who are learning from you (which of course you are, as you are a step ahead of them).
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?