What should I do when I feel overshadowed by an extremely talented team member?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
21
down vote

favorite
3












I'm a Full Stack developer and I'm in a newly created team of 4. There's this one other guy (let's call him Tom) who was hired with me. So the two of us are newbies in this company.



However, Tom is extremely talented. In our first sprint, he literally brought down the project and rebuilt it back up on a solid foundation single handedly. The only thing I did, was type whatever he told me to type. We tried pair-programming, but he ended up being the brain behind this re-architecture.



Ever since this happened, I barely ever feel like taking up new stories during sprint planning. All of us just go along with whatever he says. At first, he took the hardest of tasks upon himself. Then, he seems to be putting the most important and biggest pieces of the project together while the rest of the 3 of us simply look at his code and try to learn and understand what he's upto.



New stories in the backlog are getting so advanced, I'm finding it hard to keep up. Tom finds some of them difficult too, but he's way too smart and gets the job done quickly. Then, he sits beside me and ends up finishing my tasks too.



At this point, I feel pretty useless. It feels like my employer doesn't need me anymore. What are some things I need to do, to stay productive and get ahead in this environment?



PS: The other two developers are full-timers with super-senior roles. They have more things to do, other than writing code. So they let us newbie juniors do all the implementation.




professionalism team productivity




share|improve this question

















  • 6




    The organization is kind of strange. You have 2 junior developers who code and to other super-gods who let junior people to do the job. I am curios what kind of super important roles do other 2 super junior people do? In any other organization I worked in, no one needed 1 super cool guy to overview 1 junior guy. Based on your description I would actually think that these 2 super senior people are useless.
    – Salvador Dali
    May 30 '16 at 5:09






  • 11




    Since Tom sounds willing to help you out, work on becoming buddies, and getting him to explain his game-plan and techniques to you. Blindly typing what he tells you makes you his secretary, not a developer. Ask him why he's choosing to do things a certain way. Sit down with him at lunch and have him explain the architecture to you. Ask questions, and seek to understand what's going on rather than just blindly following his lead. Seek to become his partner, not his helper. If he uses a technique you're not familiar with ask for clarification, and do a bit of research to catch up to him
    – AndreiROM
    May 30 '16 at 14:04






  • 2




    Tom and I are great buddies. Tom is ALWAYS willing to help me out. I ask questions, he gives an advanced answer; only part of which I understand. This seems to go on forever. It's as if Tom makes huge strides in progress whereas I simply provide support. The other two team members have their own things. One of them has dedicated himself to covering the project with as much unit tests as possible and the other one is a tester plus devops.
    – Divyanth Jayaraj
    May 30 '16 at 14:46






  • 3




    Some people just "get" good code design, others struggle. It's possible that you're one of those people who can handle the little ticky repetitive tasks that always seem to need to be done that might bore the life out of Tom to the extent that he would constantly be making mistakes. Not everyone has a talent that is regarded as glamorous, but sometimes those little ticky tasks are the more necessary ones.
    – Amy Blankenship
    May 30 '16 at 17:22






  • 5




    Imagine if Tom never came. You'd still be stuck with old architecture, not knowing if it's good or bad, if you're slow or the tasks are too hard, not knowing how things can be done better, faster, more efficiently. So now imagine talking to yourself from a year ago. Can you see just how much better you already got? What you have is a truly unique opportunity to get years of experience really fast - all you have to do is follow Tom and absorb all his knowledge. You might not get as good as Tom, but you'll sure get much better than yesterday. Sometimes I'm Tom and I wish there was another Tom.
    – Anton Koscejev
    Jun 1 '16 at 15:48
















up vote
21
down vote

favorite
3












I'm a Full Stack developer and I'm in a newly created team of 4. There's this one other guy (let's call him Tom) who was hired with me. So the two of us are newbies in this company.



However, Tom is extremely talented. In our first sprint, he literally brought down the project and rebuilt it back up on a solid foundation single handedly. The only thing I did, was type whatever he told me to type. We tried pair-programming, but he ended up being the brain behind this re-architecture.



Ever since this happened, I barely ever feel like taking up new stories during sprint planning. All of us just go along with whatever he says. At first, he took the hardest of tasks upon himself. Then, he seems to be putting the most important and biggest pieces of the project together while the rest of the 3 of us simply look at his code and try to learn and understand what he's upto.



New stories in the backlog are getting so advanced, I'm finding it hard to keep up. Tom finds some of them difficult too, but he's way too smart and gets the job done quickly. Then, he sits beside me and ends up finishing my tasks too.



At this point, I feel pretty useless. It feels like my employer doesn't need me anymore. What are some things I need to do, to stay productive and get ahead in this environment?



PS: The other two developers are full-timers with super-senior roles. They have more things to do, other than writing code. So they let us newbie juniors do all the implementation.




professionalism team productivity




share|improve this question

















  • 6




    The organization is kind of strange. You have 2 junior developers who code and to other super-gods who let junior people to do the job. I am curios what kind of super important roles do other 2 super junior people do? In any other organization I worked in, no one needed 1 super cool guy to overview 1 junior guy. Based on your description I would actually think that these 2 super senior people are useless.
    – Salvador Dali
    May 30 '16 at 5:09






  • 11




    Since Tom sounds willing to help you out, work on becoming buddies, and getting him to explain his game-plan and techniques to you. Blindly typing what he tells you makes you his secretary, not a developer. Ask him why he's choosing to do things a certain way. Sit down with him at lunch and have him explain the architecture to you. Ask questions, and seek to understand what's going on rather than just blindly following his lead. Seek to become his partner, not his helper. If he uses a technique you're not familiar with ask for clarification, and do a bit of research to catch up to him
    – AndreiROM
    May 30 '16 at 14:04






  • 2




    Tom and I are great buddies. Tom is ALWAYS willing to help me out. I ask questions, he gives an advanced answer; only part of which I understand. This seems to go on forever. It's as if Tom makes huge strides in progress whereas I simply provide support. The other two team members have their own things. One of them has dedicated himself to covering the project with as much unit tests as possible and the other one is a tester plus devops.
    – Divyanth Jayaraj
    May 30 '16 at 14:46






  • 3




    Some people just "get" good code design, others struggle. It's possible that you're one of those people who can handle the little ticky repetitive tasks that always seem to need to be done that might bore the life out of Tom to the extent that he would constantly be making mistakes. Not everyone has a talent that is regarded as glamorous, but sometimes those little ticky tasks are the more necessary ones.
    – Amy Blankenship
    May 30 '16 at 17:22






  • 5




    Imagine if Tom never came. You'd still be stuck with old architecture, not knowing if it's good or bad, if you're slow or the tasks are too hard, not knowing how things can be done better, faster, more efficiently. So now imagine talking to yourself from a year ago. Can you see just how much better you already got? What you have is a truly unique opportunity to get years of experience really fast - all you have to do is follow Tom and absorb all his knowledge. You might not get as good as Tom, but you'll sure get much better than yesterday. Sometimes I'm Tom and I wish there was another Tom.
    – Anton Koscejev
    Jun 1 '16 at 15:48












up vote
21
down vote

favorite
3









up vote
21
down vote

favorite
3






3





I'm a Full Stack developer and I'm in a newly created team of 4. There's this one other guy (let's call him Tom) who was hired with me. So the two of us are newbies in this company.



However, Tom is extremely talented. In our first sprint, he literally brought down the project and rebuilt it back up on a solid foundation single handedly. The only thing I did, was type whatever he told me to type. We tried pair-programming, but he ended up being the brain behind this re-architecture.



Ever since this happened, I barely ever feel like taking up new stories during sprint planning. All of us just go along with whatever he says. At first, he took the hardest of tasks upon himself. Then, he seems to be putting the most important and biggest pieces of the project together while the rest of the 3 of us simply look at his code and try to learn and understand what he's upto.



New stories in the backlog are getting so advanced, I'm finding it hard to keep up. Tom finds some of them difficult too, but he's way too smart and gets the job done quickly. Then, he sits beside me and ends up finishing my tasks too.



At this point, I feel pretty useless. It feels like my employer doesn't need me anymore. What are some things I need to do, to stay productive and get ahead in this environment?



PS: The other two developers are full-timers with super-senior roles. They have more things to do, other than writing code. So they let us newbie juniors do all the implementation.




professionalism team productivity




share|improve this question













I'm a Full Stack developer and I'm in a newly created team of 4. There's this one other guy (let's call him Tom) who was hired with me. So the two of us are newbies in this company.



However, Tom is extremely talented. In our first sprint, he literally brought down the project and rebuilt it back up on a solid foundation single handedly. The only thing I did, was type whatever he told me to type. We tried pair-programming, but he ended up being the brain behind this re-architecture.



Ever since this happened, I barely ever feel like taking up new stories during sprint planning. All of us just go along with whatever he says. At first, he took the hardest of tasks upon himself. Then, he seems to be putting the most important and biggest pieces of the project together while the rest of the 3 of us simply look at his code and try to learn and understand what he's upto.



New stories in the backlog are getting so advanced, I'm finding it hard to keep up. Tom finds some of them difficult too, but he's way too smart and gets the job done quickly. Then, he sits beside me and ends up finishing my tasks too.



At this point, I feel pretty useless. It feels like my employer doesn't need me anymore. What are some things I need to do, to stay productive and get ahead in this environment?



PS: The other two developers are full-timers with super-senior roles. They have more things to do, other than writing code. So they let us newbie juniors do all the implementation.





professionalism team productivity





share|improve this question












share|improve this question




share|improve this question








edited May 30 '16 at 4:59
























asked May 30 '16 at 4:19









Divyanth Jayaraj

27129




27129







  • 6




    The organization is kind of strange. You have 2 junior developers who code and to other super-gods who let junior people to do the job. I am curios what kind of super important roles do other 2 super junior people do? In any other organization I worked in, no one needed 1 super cool guy to overview 1 junior guy. Based on your description I would actually think that these 2 super senior people are useless.
    – Salvador Dali
    May 30 '16 at 5:09






  • 11




    Since Tom sounds willing to help you out, work on becoming buddies, and getting him to explain his game-plan and techniques to you. Blindly typing what he tells you makes you his secretary, not a developer. Ask him why he's choosing to do things a certain way. Sit down with him at lunch and have him explain the architecture to you. Ask questions, and seek to understand what's going on rather than just blindly following his lead. Seek to become his partner, not his helper. If he uses a technique you're not familiar with ask for clarification, and do a bit of research to catch up to him
    – AndreiROM
    May 30 '16 at 14:04






  • 2




    Tom and I are great buddies. Tom is ALWAYS willing to help me out. I ask questions, he gives an advanced answer; only part of which I understand. This seems to go on forever. It's as if Tom makes huge strides in progress whereas I simply provide support. The other two team members have their own things. One of them has dedicated himself to covering the project with as much unit tests as possible and the other one is a tester plus devops.
    – Divyanth Jayaraj
    May 30 '16 at 14:46






  • 3




    Some people just "get" good code design, others struggle. It's possible that you're one of those people who can handle the little ticky repetitive tasks that always seem to need to be done that might bore the life out of Tom to the extent that he would constantly be making mistakes. Not everyone has a talent that is regarded as glamorous, but sometimes those little ticky tasks are the more necessary ones.
    – Amy Blankenship
    May 30 '16 at 17:22






  • 5




    Imagine if Tom never came. You'd still be stuck with old architecture, not knowing if it's good or bad, if you're slow or the tasks are too hard, not knowing how things can be done better, faster, more efficiently. So now imagine talking to yourself from a year ago. Can you see just how much better you already got? What you have is a truly unique opportunity to get years of experience really fast - all you have to do is follow Tom and absorb all his knowledge. You might not get as good as Tom, but you'll sure get much better than yesterday. Sometimes I'm Tom and I wish there was another Tom.
    – Anton Koscejev
    Jun 1 '16 at 15:48












  • 6




    The organization is kind of strange. You have 2 junior developers who code and to other super-gods who let junior people to do the job. I am curios what kind of super important roles do other 2 super junior people do? In any other organization I worked in, no one needed 1 super cool guy to overview 1 junior guy. Based on your description I would actually think that these 2 super senior people are useless.
    – Salvador Dali
    May 30 '16 at 5:09






  • 11




    Since Tom sounds willing to help you out, work on becoming buddies, and getting him to explain his game-plan and techniques to you. Blindly typing what he tells you makes you his secretary, not a developer. Ask him why he's choosing to do things a certain way. Sit down with him at lunch and have him explain the architecture to you. Ask questions, and seek to understand what's going on rather than just blindly following his lead. Seek to become his partner, not his helper. If he uses a technique you're not familiar with ask for clarification, and do a bit of research to catch up to him
    – AndreiROM
    May 30 '16 at 14:04






  • 2




    Tom and I are great buddies. Tom is ALWAYS willing to help me out. I ask questions, he gives an advanced answer; only part of which I understand. This seems to go on forever. It's as if Tom makes huge strides in progress whereas I simply provide support. The other two team members have their own things. One of them has dedicated himself to covering the project with as much unit tests as possible and the other one is a tester plus devops.
    – Divyanth Jayaraj
    May 30 '16 at 14:46






  • 3




    Some people just "get" good code design, others struggle. It's possible that you're one of those people who can handle the little ticky repetitive tasks that always seem to need to be done that might bore the life out of Tom to the extent that he would constantly be making mistakes. Not everyone has a talent that is regarded as glamorous, but sometimes those little ticky tasks are the more necessary ones.
    – Amy Blankenship
    May 30 '16 at 17:22






  • 5




    Imagine if Tom never came. You'd still be stuck with old architecture, not knowing if it's good or bad, if you're slow or the tasks are too hard, not knowing how things can be done better, faster, more efficiently. So now imagine talking to yourself from a year ago. Can you see just how much better you already got? What you have is a truly unique opportunity to get years of experience really fast - all you have to do is follow Tom and absorb all his knowledge. You might not get as good as Tom, but you'll sure get much better than yesterday. Sometimes I'm Tom and I wish there was another Tom.
    – Anton Koscejev
    Jun 1 '16 at 15:48







6




6




The organization is kind of strange. You have 2 junior developers who code and to other super-gods who let junior people to do the job. I am curios what kind of super important roles do other 2 super junior people do? In any other organization I worked in, no one needed 1 super cool guy to overview 1 junior guy. Based on your description I would actually think that these 2 super senior people are useless.
– Salvador Dali
May 30 '16 at 5:09




The organization is kind of strange. You have 2 junior developers who code and to other super-gods who let junior people to do the job. I am curios what kind of super important roles do other 2 super junior people do? In any other organization I worked in, no one needed 1 super cool guy to overview 1 junior guy. Based on your description I would actually think that these 2 super senior people are useless.
– Salvador Dali
May 30 '16 at 5:09




11




11




Since Tom sounds willing to help you out, work on becoming buddies, and getting him to explain his game-plan and techniques to you. Blindly typing what he tells you makes you his secretary, not a developer. Ask him why he's choosing to do things a certain way. Sit down with him at lunch and have him explain the architecture to you. Ask questions, and seek to understand what's going on rather than just blindly following his lead. Seek to become his partner, not his helper. If he uses a technique you're not familiar with ask for clarification, and do a bit of research to catch up to him
– AndreiROM
May 30 '16 at 14:04




Since Tom sounds willing to help you out, work on becoming buddies, and getting him to explain his game-plan and techniques to you. Blindly typing what he tells you makes you his secretary, not a developer. Ask him why he's choosing to do things a certain way. Sit down with him at lunch and have him explain the architecture to you. Ask questions, and seek to understand what's going on rather than just blindly following his lead. Seek to become his partner, not his helper. If he uses a technique you're not familiar with ask for clarification, and do a bit of research to catch up to him
– AndreiROM
May 30 '16 at 14:04




2




2




Tom and I are great buddies. Tom is ALWAYS willing to help me out. I ask questions, he gives an advanced answer; only part of which I understand. This seems to go on forever. It's as if Tom makes huge strides in progress whereas I simply provide support. The other two team members have their own things. One of them has dedicated himself to covering the project with as much unit tests as possible and the other one is a tester plus devops.
– Divyanth Jayaraj
May 30 '16 at 14:46




Tom and I are great buddies. Tom is ALWAYS willing to help me out. I ask questions, he gives an advanced answer; only part of which I understand. This seems to go on forever. It's as if Tom makes huge strides in progress whereas I simply provide support. The other two team members have their own things. One of them has dedicated himself to covering the project with as much unit tests as possible and the other one is a tester plus devops.
– Divyanth Jayaraj
May 30 '16 at 14:46




3




3




Some people just "get" good code design, others struggle. It's possible that you're one of those people who can handle the little ticky repetitive tasks that always seem to need to be done that might bore the life out of Tom to the extent that he would constantly be making mistakes. Not everyone has a talent that is regarded as glamorous, but sometimes those little ticky tasks are the more necessary ones.
– Amy Blankenship
May 30 '16 at 17:22




Some people just "get" good code design, others struggle. It's possible that you're one of those people who can handle the little ticky repetitive tasks that always seem to need to be done that might bore the life out of Tom to the extent that he would constantly be making mistakes. Not everyone has a talent that is regarded as glamorous, but sometimes those little ticky tasks are the more necessary ones.
– Amy Blankenship
May 30 '16 at 17:22




5




5




Imagine if Tom never came. You'd still be stuck with old architecture, not knowing if it's good or bad, if you're slow or the tasks are too hard, not knowing how things can be done better, faster, more efficiently. So now imagine talking to yourself from a year ago. Can you see just how much better you already got? What you have is a truly unique opportunity to get years of experience really fast - all you have to do is follow Tom and absorb all his knowledge. You might not get as good as Tom, but you'll sure get much better than yesterday. Sometimes I'm Tom and I wish there was another Tom.
– Anton Koscejev
Jun 1 '16 at 15:48




Imagine if Tom never came. You'd still be stuck with old architecture, not knowing if it's good or bad, if you're slow or the tasks are too hard, not knowing how things can be done better, faster, more efficiently. So now imagine talking to yourself from a year ago. Can you see just how much better you already got? What you have is a truly unique opportunity to get years of experience really fast - all you have to do is follow Tom and absorb all his knowledge. You might not get as good as Tom, but you'll sure get much better than yesterday. Sometimes I'm Tom and I wish there was another Tom.
– Anton Koscejev
Jun 1 '16 at 15:48










8 Answers
8






active

oldest

votes

















up vote
17
down vote



accepted










Tom obviously has the "big-picture" architecture in his mind. This makes designing the smaller pieces and seeing how everything fits together far easier.



Rather than focusing on the minutiae, you should focus on understanding the architecture that Tom has in mind. If you have a decent understanding of good design techniques then that should help you immensely. If Tom doesn't already have something describing the architecture written down then it would probably be very worthwhile for you to take a shot at documenting the architecture and then get Tom to help fill in what you missed.



If Tom is as good as you say then I'll bet his approach is very systematic and actually quite easy to follow once you learn the "whats" and "whys" of what Tom is trying to achieve in the architecture. Once you understand the "whats" and "whys" then you can focus on the "hows" and I'm sure it'll be a lot easier then.



From your description it seems like you are simply implementing things the way Tom is telling you without understanding why. That's why you aren't feeling like you are getting better. You really need to understand the why's or you'll never improve and you'll be needing Tom's help every time you tackle something remotely different.






share|improve this answer























  • I have been accused as being a programming god. I am not I just follow simple rules, that I have discovered lead to good designs, that are quick to create, and less buggy. These techniques can be learnt by anyone.
    – ctrl-alt-delor
    Jun 2 '16 at 9:07










  • @richard - you don't give yourself enough credit. Sure, anyone can learn the techniques but being able use them with skill is another matter. Anyone can learn to swing a baseball bat or golf club but that doesn't mean that just anyone will be even remotely skillful at hitting the ball.
    – Dunk
    Jun 9 '17 at 14:34










  • see ted.com/speakers/carol_dweck — I don't deny that I have some talent. I am just saying that most of if can be learnt. “If you think that you can learn new things, or if you think that you can not, then you are right.”
    – ctrl-alt-delor
    Jun 9 '17 at 16:21

















up vote
21
down vote













Not taking up stories during sprint planning just shoves you farther into the background. Stop being grumpy and start improving your game.



Work with him. Learn from him. Ask him to help you come up to his level. Peer-review his code, asking questions as necessary to understand it -- someone has to, and it's a great opportunity to learn.






share|improve this answer





















  • Yeah, I've got those basics covered. But there's only so much of it you can do, unless you make use of some drastically new idea. That's why I asked this question here.
    – Divyanth Jayaraj
    May 30 '16 at 4:57






  • 1




    @DivyanthJayaraj There may only be so much you can do. It may be that you eventually get to Tom's level, or you don't because Tom has sacrificed in his personal life to excel at work and/or is way more passionate than you. Like others have stated, not having a positive attitude about the situation is the worst thing you can do for yourself and the company.
    – The Muffin Man
    May 31 '16 at 15:23

















up vote
11
down vote













This is a very difficult question to answer, since the answer depends heavily on Tom. I have worked on several different programs that have had a genius level programmer on them and here are some of things I have picked up on.



  • Have a mind set of you are the second best developer on the team, not the worst developer

  • Avoid measuring your own performance against others. Are you giving it all you can? Just because he is an extremely good developer and you are simply a good developer does not make you a bad developer.

What is Tom's personality?



Tom's personality greatly impacts on how much he can and will be willing to help you. If he does not mind helping/teaching you take full advantage of it. If he is stubborn and/or lacks personal skills, learn as much as you can from the Internet, keep your skills sharp, and begin looking for a new job else where. In both cases contribute what you can. If your program has no testers then focus on testing his code. There are many reasons for this: it will help you learn his stuff, it keeps you busy and performing, it validates that his code is genius level code and not meatball surgery code (the latter which looks good for a little while and then falls apart).



Advice for leaders



Generally though the leaders on the team need to be aware that they got a genius on the team and take appropriate steps. The main reason being is that genius level developers have a tendency to write code that takes a genius to understand. This results in risk to the program, and the genius needs to learn how to write more maintainable code. Example from my own past:



One time we had a genius level developer on our team for three months. He did an incredible job tackling all kinds of challenging code problems that would have taken other developers on the team twice as long. Problem was after three months his previous program desperately needed him back, because he was the only one who could fix some of the problems they were having. So we ended up losing him, at which point we had to start maintaining his code.



Fortunately we had not become dependent on him like his previous program, but we still had trouble with other developers struggling to make updates to his code since it took them so long to get ramped up on his code. In your case where there is only two people developing, and this goes on unhandled for years, and then Tom decides to leave, it could result in huge hit to the program's performance.






share|improve this answer

















  • 1




    Also, it's not easy to learn to step back and let other people pick up tasks you could do twice as fast and leave more robust code behind. Tom needs to learn to let other people try and possibly make mistakes. He may well have to fix things, but over the longer haul he won't be able to do everything single-handedly.
    – Amy Blankenship
    May 30 '16 at 17:26






  • 1




    i like your comment about meatball surgery vs genius. There are many ways to seem like you know what you're talking about, but in reality you're full of it. You also talk about maintaining code. I remember someone saying what makes a good coder is the ability to write readable code for others ,because if you can't, then you're not very helpful. Reminds me of someone at a programming competition who everyone claimed was so smart, and a "Genius coder," yet when the judges went to read his code.... they couldn't understand it. You might get logic, but not how to present it well.
    – XaolingBao
    May 31 '16 at 20:41






  • 1




    I call someone who simply writes code that somewhat works, no matter how challenging the task, but can only be understood with great explanation or requiring a really smart person to understand a hacker. Certainly not a genius, at least in terms of software developer. A true genius takes something really difficult to understand and makes it simple. That's also how I define a good engineer in general.
    – Dunk
    Jun 2 '16 at 14:09

















up vote
3
down vote













I didn't know you felt this way...



But seriously, just be more assertive. Sometimes people tend to have personalities where they feel as if projects are done incorrectly if they're not directly hovering over it. Split up the work to a point that either one of you can look at each other's progress and understand what's going on. Don't be caught with your mouth agape if he suddenly goes MIA and you're left with the sole responsibility.






share|improve this answer






























    up vote
    1
    down vote













    Discuss some stories, when you got an Idee if any just put it out there. The entire Idea of sprint planning is to brainstorm not to go with whatever "tom" said. Maybe your idea´s are better than you think. Sitting on the back of your seat aint going to work for you.



    Other than that bug testing is important. And doing that on your own code is tough. And I am not pointing to unit tests, but real human testing. Doing this might not be your ideal Position, but helps you really think about how to build code to prevent Errors/bugs in the first place.






    share|improve this answer




























      up vote
      0
      down vote













      Its a good opportunity for you, take the challenging task ask question to your talented team member definitely he will help you out. You will learn a lot from him and don't feel like you are pretty useless its your mistake that you are not coming front to take the tasks, after him you only the point of contact its just that you didn't contribute much from your side but you know each and everything in that project.



      Take the new stories discuss with your team mates and start working on that's how a team works, all the team members will not be equally talented but you need to learn utilizing the talent of others by asking them politely, but be sure that you are not boring them by asking silly question and not trying anything from your side that will keep you productive in the team.






      share|improve this answer




























        up vote
        0
        down vote













        Are you sure that Tom is the genius that you think he is? This reads like the introduction to a Daily WTF story, where Tom comes on and reimplements the system and talks a good line, but whenever anyone actually looks at his code, it's actually slipshod and baseless.



        It's certainly possible that Tom knows what he is doing (and you should have one of the senior developers confirm that for you), in which case hopefully he can teach you a lot, but my guess is that Tom thinks he knows a hell of a lot more than he actually does, in which case you will benefit by slowly building up your skills, and being wary of anything that Tom does that is too quick and/or too easy.






        share|improve this answer





















        • "Tom thinks he knows a hell of a lot more than he actually does". That usually covers the incompetent to "mildly" competent developers. The really good ones tend to think they don't know enough. On the flip-side, while the really good developers tend to think they don't know enough, they do know enough to realize that their co-workers know far less; so they know they have be assertive or their project is doomed.
          – Dunk
          Jun 2 '16 at 14:14


















        up vote
        0
        down vote













        He takes the time to do pair programming and instruct you, so try to learn from him.



        I have a younger colleague much less experienced than me (I am programming since before she was born). We don't do pair programming, but regular code reviews, and after 1-2 months I can see her getting better to a point that I estimate that in 1-3 months i can remove myself from that part of the project and let her do it on her own.



        So if your team and the senior developer have the right attitude (to learn and have him free for other stuff after some time), the world should be fine.



        Some practical advice:



        • in a sprint you should evaluate how you see the task - evaluating user stories only works if everybody give his opinion


        • committing to a task does not mean that you have to do it without help - ask for help in the daily standup


        • if backlog stories get so complicated that only one person in team even feels able to understand the impact and scope of them, (assuming you scrum), then refining/splitting the story is needed. Having a story description which is not understood by the team as a whole is not acceptable.


        • To me it seems that he has much of the architecture in his head, which may make it terribly difficult to follow. Maybe you can have a "document" the architecture story.






        share|improve this answer





















          Your Answer







          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "423"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          noCode: true, onDemand: false,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );








           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f67949%2fwhat-should-i-do-when-i-feel-overshadowed-by-an-extremely-talented-team-member%23new-answer', 'question_page');

          );

          Post as a guest












          StackExchange.ready(function ()
          $("#show-editor-button input, #show-editor-button button").click(function ()
          var showEditor = function()
          $("#show-editor-button").hide();
          $("#post-form").removeClass("dno");
          StackExchange.editor.finallyInit();
          ;

          var useFancy = $(this).data('confirm-use-fancy');
          if(useFancy == 'True')
          var popupTitle = $(this).data('confirm-fancy-title');
          var popupBody = $(this).data('confirm-fancy-body');
          var popupAccept = $(this).data('confirm-fancy-accept-button');

          $(this).loadPopup(
          url: '/post/self-answer-popup',
          loaded: function(popup)
          var pTitle = $(popup).find('h2');
          var pBody = $(popup).find('.popup-body');
          var pSubmit = $(popup).find('.popup-submit');

          pTitle.text(popupTitle);
          pBody.html(popupBody);
          pSubmit.val(popupAccept).click(showEditor);

          )
          else
          var confirmText = $(this).data('confirm-text');
          if (confirmText ? confirm(confirmText) : true)
          showEditor();


          );
          );






          8 Answers
          8






          active

          oldest

          votes








          8 Answers
          8






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          17
          down vote



          accepted










          Tom obviously has the "big-picture" architecture in his mind. This makes designing the smaller pieces and seeing how everything fits together far easier.



          Rather than focusing on the minutiae, you should focus on understanding the architecture that Tom has in mind. If you have a decent understanding of good design techniques then that should help you immensely. If Tom doesn't already have something describing the architecture written down then it would probably be very worthwhile for you to take a shot at documenting the architecture and then get Tom to help fill in what you missed.



          If Tom is as good as you say then I'll bet his approach is very systematic and actually quite easy to follow once you learn the "whats" and "whys" of what Tom is trying to achieve in the architecture. Once you understand the "whats" and "whys" then you can focus on the "hows" and I'm sure it'll be a lot easier then.



          From your description it seems like you are simply implementing things the way Tom is telling you without understanding why. That's why you aren't feeling like you are getting better. You really need to understand the why's or you'll never improve and you'll be needing Tom's help every time you tackle something remotely different.






          share|improve this answer























          • I have been accused as being a programming god. I am not I just follow simple rules, that I have discovered lead to good designs, that are quick to create, and less buggy. These techniques can be learnt by anyone.
            – ctrl-alt-delor
            Jun 2 '16 at 9:07










          • @richard - you don't give yourself enough credit. Sure, anyone can learn the techniques but being able use them with skill is another matter. Anyone can learn to swing a baseball bat or golf club but that doesn't mean that just anyone will be even remotely skillful at hitting the ball.
            – Dunk
            Jun 9 '17 at 14:34










          • see ted.com/speakers/carol_dweck — I don't deny that I have some talent. I am just saying that most of if can be learnt. “If you think that you can learn new things, or if you think that you can not, then you are right.”
            – ctrl-alt-delor
            Jun 9 '17 at 16:21














          up vote
          17
          down vote



          accepted










          Tom obviously has the "big-picture" architecture in his mind. This makes designing the smaller pieces and seeing how everything fits together far easier.



          Rather than focusing on the minutiae, you should focus on understanding the architecture that Tom has in mind. If you have a decent understanding of good design techniques then that should help you immensely. If Tom doesn't already have something describing the architecture written down then it would probably be very worthwhile for you to take a shot at documenting the architecture and then get Tom to help fill in what you missed.



          If Tom is as good as you say then I'll bet his approach is very systematic and actually quite easy to follow once you learn the "whats" and "whys" of what Tom is trying to achieve in the architecture. Once you understand the "whats" and "whys" then you can focus on the "hows" and I'm sure it'll be a lot easier then.



          From your description it seems like you are simply implementing things the way Tom is telling you without understanding why. That's why you aren't feeling like you are getting better. You really need to understand the why's or you'll never improve and you'll be needing Tom's help every time you tackle something remotely different.






          share|improve this answer























          • I have been accused as being a programming god. I am not I just follow simple rules, that I have discovered lead to good designs, that are quick to create, and less buggy. These techniques can be learnt by anyone.
            – ctrl-alt-delor
            Jun 2 '16 at 9:07










          • @richard - you don't give yourself enough credit. Sure, anyone can learn the techniques but being able use them with skill is another matter. Anyone can learn to swing a baseball bat or golf club but that doesn't mean that just anyone will be even remotely skillful at hitting the ball.
            – Dunk
            Jun 9 '17 at 14:34










          • see ted.com/speakers/carol_dweck — I don't deny that I have some talent. I am just saying that most of if can be learnt. “If you think that you can learn new things, or if you think that you can not, then you are right.”
            – ctrl-alt-delor
            Jun 9 '17 at 16:21












          up vote
          17
          down vote



          accepted







          up vote
          17
          down vote



          accepted






          Tom obviously has the "big-picture" architecture in his mind. This makes designing the smaller pieces and seeing how everything fits together far easier.



          Rather than focusing on the minutiae, you should focus on understanding the architecture that Tom has in mind. If you have a decent understanding of good design techniques then that should help you immensely. If Tom doesn't already have something describing the architecture written down then it would probably be very worthwhile for you to take a shot at documenting the architecture and then get Tom to help fill in what you missed.



          If Tom is as good as you say then I'll bet his approach is very systematic and actually quite easy to follow once you learn the "whats" and "whys" of what Tom is trying to achieve in the architecture. Once you understand the "whats" and "whys" then you can focus on the "hows" and I'm sure it'll be a lot easier then.



          From your description it seems like you are simply implementing things the way Tom is telling you without understanding why. That's why you aren't feeling like you are getting better. You really need to understand the why's or you'll never improve and you'll be needing Tom's help every time you tackle something remotely different.






          share|improve this answer















          Tom obviously has the "big-picture" architecture in his mind. This makes designing the smaller pieces and seeing how everything fits together far easier.



          Rather than focusing on the minutiae, you should focus on understanding the architecture that Tom has in mind. If you have a decent understanding of good design techniques then that should help you immensely. If Tom doesn't already have something describing the architecture written down then it would probably be very worthwhile for you to take a shot at documenting the architecture and then get Tom to help fill in what you missed.



          If Tom is as good as you say then I'll bet his approach is very systematic and actually quite easy to follow once you learn the "whats" and "whys" of what Tom is trying to achieve in the architecture. Once you understand the "whats" and "whys" then you can focus on the "hows" and I'm sure it'll be a lot easier then.



          From your description it seems like you are simply implementing things the way Tom is telling you without understanding why. That's why you aren't feeling like you are getting better. You really need to understand the why's or you'll never improve and you'll be needing Tom's help every time you tackle something remotely different.







          share|improve this answer















          share|improve this answer



          share|improve this answer








          edited May 31 '16 at 19:01


























          answered May 31 '16 at 18:53









          Dunk

          1,10278




          1,10278











          • I have been accused as being a programming god. I am not I just follow simple rules, that I have discovered lead to good designs, that are quick to create, and less buggy. These techniques can be learnt by anyone.
            – ctrl-alt-delor
            Jun 2 '16 at 9:07










          • @richard - you don't give yourself enough credit. Sure, anyone can learn the techniques but being able use them with skill is another matter. Anyone can learn to swing a baseball bat or golf club but that doesn't mean that just anyone will be even remotely skillful at hitting the ball.
            – Dunk
            Jun 9 '17 at 14:34










          • see ted.com/speakers/carol_dweck — I don't deny that I have some talent. I am just saying that most of if can be learnt. “If you think that you can learn new things, or if you think that you can not, then you are right.”
            – ctrl-alt-delor
            Jun 9 '17 at 16:21
















          • I have been accused as being a programming god. I am not I just follow simple rules, that I have discovered lead to good designs, that are quick to create, and less buggy. These techniques can be learnt by anyone.
            – ctrl-alt-delor
            Jun 2 '16 at 9:07










          • @richard - you don't give yourself enough credit. Sure, anyone can learn the techniques but being able use them with skill is another matter. Anyone can learn to swing a baseball bat or golf club but that doesn't mean that just anyone will be even remotely skillful at hitting the ball.
            – Dunk
            Jun 9 '17 at 14:34










          • see ted.com/speakers/carol_dweck — I don't deny that I have some talent. I am just saying that most of if can be learnt. “If you think that you can learn new things, or if you think that you can not, then you are right.”
            – ctrl-alt-delor
            Jun 9 '17 at 16:21















          I have been accused as being a programming god. I am not I just follow simple rules, that I have discovered lead to good designs, that are quick to create, and less buggy. These techniques can be learnt by anyone.
          – ctrl-alt-delor
          Jun 2 '16 at 9:07




          I have been accused as being a programming god. I am not I just follow simple rules, that I have discovered lead to good designs, that are quick to create, and less buggy. These techniques can be learnt by anyone.
          – ctrl-alt-delor
          Jun 2 '16 at 9:07












          @richard - you don't give yourself enough credit. Sure, anyone can learn the techniques but being able use them with skill is another matter. Anyone can learn to swing a baseball bat or golf club but that doesn't mean that just anyone will be even remotely skillful at hitting the ball.
          – Dunk
          Jun 9 '17 at 14:34




          @richard - you don't give yourself enough credit. Sure, anyone can learn the techniques but being able use them with skill is another matter. Anyone can learn to swing a baseball bat or golf club but that doesn't mean that just anyone will be even remotely skillful at hitting the ball.
          – Dunk
          Jun 9 '17 at 14:34












          see ted.com/speakers/carol_dweck — I don't deny that I have some talent. I am just saying that most of if can be learnt. “If you think that you can learn new things, or if you think that you can not, then you are right.”
          – ctrl-alt-delor
          Jun 9 '17 at 16:21




          see ted.com/speakers/carol_dweck — I don't deny that I have some talent. I am just saying that most of if can be learnt. “If you think that you can learn new things, or if you think that you can not, then you are right.”
          – ctrl-alt-delor
          Jun 9 '17 at 16:21












          up vote
          21
          down vote













          Not taking up stories during sprint planning just shoves you farther into the background. Stop being grumpy and start improving your game.



          Work with him. Learn from him. Ask him to help you come up to his level. Peer-review his code, asking questions as necessary to understand it -- someone has to, and it's a great opportunity to learn.






          share|improve this answer





















          • Yeah, I've got those basics covered. But there's only so much of it you can do, unless you make use of some drastically new idea. That's why I asked this question here.
            – Divyanth Jayaraj
            May 30 '16 at 4:57






          • 1




            @DivyanthJayaraj There may only be so much you can do. It may be that you eventually get to Tom's level, or you don't because Tom has sacrificed in his personal life to excel at work and/or is way more passionate than you. Like others have stated, not having a positive attitude about the situation is the worst thing you can do for yourself and the company.
            – The Muffin Man
            May 31 '16 at 15:23














          up vote
          21
          down vote













          Not taking up stories during sprint planning just shoves you farther into the background. Stop being grumpy and start improving your game.



          Work with him. Learn from him. Ask him to help you come up to his level. Peer-review his code, asking questions as necessary to understand it -- someone has to, and it's a great opportunity to learn.






          share|improve this answer





















          • Yeah, I've got those basics covered. But there's only so much of it you can do, unless you make use of some drastically new idea. That's why I asked this question here.
            – Divyanth Jayaraj
            May 30 '16 at 4:57






          • 1




            @DivyanthJayaraj There may only be so much you can do. It may be that you eventually get to Tom's level, or you don't because Tom has sacrificed in his personal life to excel at work and/or is way more passionate than you. Like others have stated, not having a positive attitude about the situation is the worst thing you can do for yourself and the company.
            – The Muffin Man
            May 31 '16 at 15:23












          up vote
          21
          down vote










          up vote
          21
          down vote









          Not taking up stories during sprint planning just shoves you farther into the background. Stop being grumpy and start improving your game.



          Work with him. Learn from him. Ask him to help you come up to his level. Peer-review his code, asking questions as necessary to understand it -- someone has to, and it's a great opportunity to learn.






          share|improve this answer













          Not taking up stories during sprint planning just shoves you farther into the background. Stop being grumpy and start improving your game.



          Work with him. Learn from him. Ask him to help you come up to his level. Peer-review his code, asking questions as necessary to understand it -- someone has to, and it's a great opportunity to learn.







          share|improve this answer













          share|improve this answer



          share|improve this answer











          answered May 30 '16 at 4:32









          keshlam

          41.5k1267144




          41.5k1267144











          • Yeah, I've got those basics covered. But there's only so much of it you can do, unless you make use of some drastically new idea. That's why I asked this question here.
            – Divyanth Jayaraj
            May 30 '16 at 4:57






          • 1




            @DivyanthJayaraj There may only be so much you can do. It may be that you eventually get to Tom's level, or you don't because Tom has sacrificed in his personal life to excel at work and/or is way more passionate than you. Like others have stated, not having a positive attitude about the situation is the worst thing you can do for yourself and the company.
            – The Muffin Man
            May 31 '16 at 15:23
















          • Yeah, I've got those basics covered. But there's only so much of it you can do, unless you make use of some drastically new idea. That's why I asked this question here.
            – Divyanth Jayaraj
            May 30 '16 at 4:57






          • 1




            @DivyanthJayaraj There may only be so much you can do. It may be that you eventually get to Tom's level, or you don't because Tom has sacrificed in his personal life to excel at work and/or is way more passionate than you. Like others have stated, not having a positive attitude about the situation is the worst thing you can do for yourself and the company.
            – The Muffin Man
            May 31 '16 at 15:23















          Yeah, I've got those basics covered. But there's only so much of it you can do, unless you make use of some drastically new idea. That's why I asked this question here.
          – Divyanth Jayaraj
          May 30 '16 at 4:57




          Yeah, I've got those basics covered. But there's only so much of it you can do, unless you make use of some drastically new idea. That's why I asked this question here.
          – Divyanth Jayaraj
          May 30 '16 at 4:57




          1




          1




          @DivyanthJayaraj There may only be so much you can do. It may be that you eventually get to Tom's level, or you don't because Tom has sacrificed in his personal life to excel at work and/or is way more passionate than you. Like others have stated, not having a positive attitude about the situation is the worst thing you can do for yourself and the company.
          – The Muffin Man
          May 31 '16 at 15:23




          @DivyanthJayaraj There may only be so much you can do. It may be that you eventually get to Tom's level, or you don't because Tom has sacrificed in his personal life to excel at work and/or is way more passionate than you. Like others have stated, not having a positive attitude about the situation is the worst thing you can do for yourself and the company.
          – The Muffin Man
          May 31 '16 at 15:23










          up vote
          11
          down vote













          This is a very difficult question to answer, since the answer depends heavily on Tom. I have worked on several different programs that have had a genius level programmer on them and here are some of things I have picked up on.



          • Have a mind set of you are the second best developer on the team, not the worst developer

          • Avoid measuring your own performance against others. Are you giving it all you can? Just because he is an extremely good developer and you are simply a good developer does not make you a bad developer.

          What is Tom's personality?



          Tom's personality greatly impacts on how much he can and will be willing to help you. If he does not mind helping/teaching you take full advantage of it. If he is stubborn and/or lacks personal skills, learn as much as you can from the Internet, keep your skills sharp, and begin looking for a new job else where. In both cases contribute what you can. If your program has no testers then focus on testing his code. There are many reasons for this: it will help you learn his stuff, it keeps you busy and performing, it validates that his code is genius level code and not meatball surgery code (the latter which looks good for a little while and then falls apart).



          Advice for leaders



          Generally though the leaders on the team need to be aware that they got a genius on the team and take appropriate steps. The main reason being is that genius level developers have a tendency to write code that takes a genius to understand. This results in risk to the program, and the genius needs to learn how to write more maintainable code. Example from my own past:



          One time we had a genius level developer on our team for three months. He did an incredible job tackling all kinds of challenging code problems that would have taken other developers on the team twice as long. Problem was after three months his previous program desperately needed him back, because he was the only one who could fix some of the problems they were having. So we ended up losing him, at which point we had to start maintaining his code.



          Fortunately we had not become dependent on him like his previous program, but we still had trouble with other developers struggling to make updates to his code since it took them so long to get ramped up on his code. In your case where there is only two people developing, and this goes on unhandled for years, and then Tom decides to leave, it could result in huge hit to the program's performance.






          share|improve this answer

















          • 1




            Also, it's not easy to learn to step back and let other people pick up tasks you could do twice as fast and leave more robust code behind. Tom needs to learn to let other people try and possibly make mistakes. He may well have to fix things, but over the longer haul he won't be able to do everything single-handedly.
            – Amy Blankenship
            May 30 '16 at 17:26






          • 1




            i like your comment about meatball surgery vs genius. There are many ways to seem like you know what you're talking about, but in reality you're full of it. You also talk about maintaining code. I remember someone saying what makes a good coder is the ability to write readable code for others ,because if you can't, then you're not very helpful. Reminds me of someone at a programming competition who everyone claimed was so smart, and a "Genius coder," yet when the judges went to read his code.... they couldn't understand it. You might get logic, but not how to present it well.
            – XaolingBao
            May 31 '16 at 20:41






          • 1




            I call someone who simply writes code that somewhat works, no matter how challenging the task, but can only be understood with great explanation or requiring a really smart person to understand a hacker. Certainly not a genius, at least in terms of software developer. A true genius takes something really difficult to understand and makes it simple. That's also how I define a good engineer in general.
            – Dunk
            Jun 2 '16 at 14:09














          up vote
          11
          down vote













          This is a very difficult question to answer, since the answer depends heavily on Tom. I have worked on several different programs that have had a genius level programmer on them and here are some of things I have picked up on.



          • Have a mind set of you are the second best developer on the team, not the worst developer

          • Avoid measuring your own performance against others. Are you giving it all you can? Just because he is an extremely good developer and you are simply a good developer does not make you a bad developer.

          What is Tom's personality?



          Tom's personality greatly impacts on how much he can and will be willing to help you. If he does not mind helping/teaching you take full advantage of it. If he is stubborn and/or lacks personal skills, learn as much as you can from the Internet, keep your skills sharp, and begin looking for a new job else where. In both cases contribute what you can. If your program has no testers then focus on testing his code. There are many reasons for this: it will help you learn his stuff, it keeps you busy and performing, it validates that his code is genius level code and not meatball surgery code (the latter which looks good for a little while and then falls apart).



          Advice for leaders



          Generally though the leaders on the team need to be aware that they got a genius on the team and take appropriate steps. The main reason being is that genius level developers have a tendency to write code that takes a genius to understand. This results in risk to the program, and the genius needs to learn how to write more maintainable code. Example from my own past:



          One time we had a genius level developer on our team for three months. He did an incredible job tackling all kinds of challenging code problems that would have taken other developers on the team twice as long. Problem was after three months his previous program desperately needed him back, because he was the only one who could fix some of the problems they were having. So we ended up losing him, at which point we had to start maintaining his code.



          Fortunately we had not become dependent on him like his previous program, but we still had trouble with other developers struggling to make updates to his code since it took them so long to get ramped up on his code. In your case where there is only two people developing, and this goes on unhandled for years, and then Tom decides to leave, it could result in huge hit to the program's performance.






          share|improve this answer

















          • 1




            Also, it's not easy to learn to step back and let other people pick up tasks you could do twice as fast and leave more robust code behind. Tom needs to learn to let other people try and possibly make mistakes. He may well have to fix things, but over the longer haul he won't be able to do everything single-handedly.
            – Amy Blankenship
            May 30 '16 at 17:26






          • 1




            i like your comment about meatball surgery vs genius. There are many ways to seem like you know what you're talking about, but in reality you're full of it. You also talk about maintaining code. I remember someone saying what makes a good coder is the ability to write readable code for others ,because if you can't, then you're not very helpful. Reminds me of someone at a programming competition who everyone claimed was so smart, and a "Genius coder," yet when the judges went to read his code.... they couldn't understand it. You might get logic, but not how to present it well.
            – XaolingBao
            May 31 '16 at 20:41






          • 1




            I call someone who simply writes code that somewhat works, no matter how challenging the task, but can only be understood with great explanation or requiring a really smart person to understand a hacker. Certainly not a genius, at least in terms of software developer. A true genius takes something really difficult to understand and makes it simple. That's also how I define a good engineer in general.
            – Dunk
            Jun 2 '16 at 14:09












          up vote
          11
          down vote










          up vote
          11
          down vote









          This is a very difficult question to answer, since the answer depends heavily on Tom. I have worked on several different programs that have had a genius level programmer on them and here are some of things I have picked up on.



          • Have a mind set of you are the second best developer on the team, not the worst developer

          • Avoid measuring your own performance against others. Are you giving it all you can? Just because he is an extremely good developer and you are simply a good developer does not make you a bad developer.

          What is Tom's personality?



          Tom's personality greatly impacts on how much he can and will be willing to help you. If he does not mind helping/teaching you take full advantage of it. If he is stubborn and/or lacks personal skills, learn as much as you can from the Internet, keep your skills sharp, and begin looking for a new job else where. In both cases contribute what you can. If your program has no testers then focus on testing his code. There are many reasons for this: it will help you learn his stuff, it keeps you busy and performing, it validates that his code is genius level code and not meatball surgery code (the latter which looks good for a little while and then falls apart).



          Advice for leaders



          Generally though the leaders on the team need to be aware that they got a genius on the team and take appropriate steps. The main reason being is that genius level developers have a tendency to write code that takes a genius to understand. This results in risk to the program, and the genius needs to learn how to write more maintainable code. Example from my own past:



          One time we had a genius level developer on our team for three months. He did an incredible job tackling all kinds of challenging code problems that would have taken other developers on the team twice as long. Problem was after three months his previous program desperately needed him back, because he was the only one who could fix some of the problems they were having. So we ended up losing him, at which point we had to start maintaining his code.



          Fortunately we had not become dependent on him like his previous program, but we still had trouble with other developers struggling to make updates to his code since it took them so long to get ramped up on his code. In your case where there is only two people developing, and this goes on unhandled for years, and then Tom decides to leave, it could result in huge hit to the program's performance.






          share|improve this answer













          This is a very difficult question to answer, since the answer depends heavily on Tom. I have worked on several different programs that have had a genius level programmer on them and here are some of things I have picked up on.



          • Have a mind set of you are the second best developer on the team, not the worst developer

          • Avoid measuring your own performance against others. Are you giving it all you can? Just because he is an extremely good developer and you are simply a good developer does not make you a bad developer.

          What is Tom's personality?



          Tom's personality greatly impacts on how much he can and will be willing to help you. If he does not mind helping/teaching you take full advantage of it. If he is stubborn and/or lacks personal skills, learn as much as you can from the Internet, keep your skills sharp, and begin looking for a new job else where. In both cases contribute what you can. If your program has no testers then focus on testing his code. There are many reasons for this: it will help you learn his stuff, it keeps you busy and performing, it validates that his code is genius level code and not meatball surgery code (the latter which looks good for a little while and then falls apart).



          Advice for leaders



          Generally though the leaders on the team need to be aware that they got a genius on the team and take appropriate steps. The main reason being is that genius level developers have a tendency to write code that takes a genius to understand. This results in risk to the program, and the genius needs to learn how to write more maintainable code. Example from my own past:



          One time we had a genius level developer on our team for three months. He did an incredible job tackling all kinds of challenging code problems that would have taken other developers on the team twice as long. Problem was after three months his previous program desperately needed him back, because he was the only one who could fix some of the problems they were having. So we ended up losing him, at which point we had to start maintaining his code.



          Fortunately we had not become dependent on him like his previous program, but we still had trouble with other developers struggling to make updates to his code since it took them so long to get ramped up on his code. In your case where there is only two people developing, and this goes on unhandled for years, and then Tom decides to leave, it could result in huge hit to the program's performance.







          share|improve this answer













          share|improve this answer



          share|improve this answer











          answered May 30 '16 at 11:34









          Anketam

          3,75321134




          3,75321134







          • 1




            Also, it's not easy to learn to step back and let other people pick up tasks you could do twice as fast and leave more robust code behind. Tom needs to learn to let other people try and possibly make mistakes. He may well have to fix things, but over the longer haul he won't be able to do everything single-handedly.
            – Amy Blankenship
            May 30 '16 at 17:26






          • 1




            i like your comment about meatball surgery vs genius. There are many ways to seem like you know what you're talking about, but in reality you're full of it. You also talk about maintaining code. I remember someone saying what makes a good coder is the ability to write readable code for others ,because if you can't, then you're not very helpful. Reminds me of someone at a programming competition who everyone claimed was so smart, and a "Genius coder," yet when the judges went to read his code.... they couldn't understand it. You might get logic, but not how to present it well.
            – XaolingBao
            May 31 '16 at 20:41






          • 1




            I call someone who simply writes code that somewhat works, no matter how challenging the task, but can only be understood with great explanation or requiring a really smart person to understand a hacker. Certainly not a genius, at least in terms of software developer. A true genius takes something really difficult to understand and makes it simple. That's also how I define a good engineer in general.
            – Dunk
            Jun 2 '16 at 14:09












          • 1




            Also, it's not easy to learn to step back and let other people pick up tasks you could do twice as fast and leave more robust code behind. Tom needs to learn to let other people try and possibly make mistakes. He may well have to fix things, but over the longer haul he won't be able to do everything single-handedly.
            – Amy Blankenship
            May 30 '16 at 17:26






          • 1




            i like your comment about meatball surgery vs genius. There are many ways to seem like you know what you're talking about, but in reality you're full of it. You also talk about maintaining code. I remember someone saying what makes a good coder is the ability to write readable code for others ,because if you can't, then you're not very helpful. Reminds me of someone at a programming competition who everyone claimed was so smart, and a "Genius coder," yet when the judges went to read his code.... they couldn't understand it. You might get logic, but not how to present it well.
            – XaolingBao
            May 31 '16 at 20:41






          • 1




            I call someone who simply writes code that somewhat works, no matter how challenging the task, but can only be understood with great explanation or requiring a really smart person to understand a hacker. Certainly not a genius, at least in terms of software developer. A true genius takes something really difficult to understand and makes it simple. That's also how I define a good engineer in general.
            – Dunk
            Jun 2 '16 at 14:09







          1




          1




          Also, it's not easy to learn to step back and let other people pick up tasks you could do twice as fast and leave more robust code behind. Tom needs to learn to let other people try and possibly make mistakes. He may well have to fix things, but over the longer haul he won't be able to do everything single-handedly.
          – Amy Blankenship
          May 30 '16 at 17:26




          Also, it's not easy to learn to step back and let other people pick up tasks you could do twice as fast and leave more robust code behind. Tom needs to learn to let other people try and possibly make mistakes. He may well have to fix things, but over the longer haul he won't be able to do everything single-handedly.
          – Amy Blankenship
          May 30 '16 at 17:26




          1




          1




          i like your comment about meatball surgery vs genius. There are many ways to seem like you know what you're talking about, but in reality you're full of it. You also talk about maintaining code. I remember someone saying what makes a good coder is the ability to write readable code for others ,because if you can't, then you're not very helpful. Reminds me of someone at a programming competition who everyone claimed was so smart, and a "Genius coder," yet when the judges went to read his code.... they couldn't understand it. You might get logic, but not how to present it well.
          – XaolingBao
          May 31 '16 at 20:41




          i like your comment about meatball surgery vs genius. There are many ways to seem like you know what you're talking about, but in reality you're full of it. You also talk about maintaining code. I remember someone saying what makes a good coder is the ability to write readable code for others ,because if you can't, then you're not very helpful. Reminds me of someone at a programming competition who everyone claimed was so smart, and a "Genius coder," yet when the judges went to read his code.... they couldn't understand it. You might get logic, but not how to present it well.
          – XaolingBao
          May 31 '16 at 20:41




          1




          1




          I call someone who simply writes code that somewhat works, no matter how challenging the task, but can only be understood with great explanation or requiring a really smart person to understand a hacker. Certainly not a genius, at least in terms of software developer. A true genius takes something really difficult to understand and makes it simple. That's also how I define a good engineer in general.
          – Dunk
          Jun 2 '16 at 14:09




          I call someone who simply writes code that somewhat works, no matter how challenging the task, but can only be understood with great explanation or requiring a really smart person to understand a hacker. Certainly not a genius, at least in terms of software developer. A true genius takes something really difficult to understand and makes it simple. That's also how I define a good engineer in general.
          – Dunk
          Jun 2 '16 at 14:09










          up vote
          3
          down vote













          I didn't know you felt this way...



          But seriously, just be more assertive. Sometimes people tend to have personalities where they feel as if projects are done incorrectly if they're not directly hovering over it. Split up the work to a point that either one of you can look at each other's progress and understand what's going on. Don't be caught with your mouth agape if he suddenly goes MIA and you're left with the sole responsibility.






          share|improve this answer



























            up vote
            3
            down vote













            I didn't know you felt this way...



            But seriously, just be more assertive. Sometimes people tend to have personalities where they feel as if projects are done incorrectly if they're not directly hovering over it. Split up the work to a point that either one of you can look at each other's progress and understand what's going on. Don't be caught with your mouth agape if he suddenly goes MIA and you're left with the sole responsibility.






            share|improve this answer

























              up vote
              3
              down vote










              up vote
              3
              down vote









              I didn't know you felt this way...



              But seriously, just be more assertive. Sometimes people tend to have personalities where they feel as if projects are done incorrectly if they're not directly hovering over it. Split up the work to a point that either one of you can look at each other's progress and understand what's going on. Don't be caught with your mouth agape if he suddenly goes MIA and you're left with the sole responsibility.






              share|improve this answer















              I didn't know you felt this way...



              But seriously, just be more assertive. Sometimes people tend to have personalities where they feel as if projects are done incorrectly if they're not directly hovering over it. Split up the work to a point that either one of you can look at each other's progress and understand what's going on. Don't be caught with your mouth agape if he suddenly goes MIA and you're left with the sole responsibility.







              share|improve this answer















              share|improve this answer



              share|improve this answer








              edited May 27 '17 at 11:33









              Glorfindel

              1,65641522




              1,65641522











              answered May 31 '16 at 18:46









              Tom Park

              312




              312




















                  up vote
                  1
                  down vote













                  Discuss some stories, when you got an Idee if any just put it out there. The entire Idea of sprint planning is to brainstorm not to go with whatever "tom" said. Maybe your idea´s are better than you think. Sitting on the back of your seat aint going to work for you.



                  Other than that bug testing is important. And doing that on your own code is tough. And I am not pointing to unit tests, but real human testing. Doing this might not be your ideal Position, but helps you really think about how to build code to prevent Errors/bugs in the first place.






                  share|improve this answer

























                    up vote
                    1
                    down vote













                    Discuss some stories, when you got an Idee if any just put it out there. The entire Idea of sprint planning is to brainstorm not to go with whatever "tom" said. Maybe your idea´s are better than you think. Sitting on the back of your seat aint going to work for you.



                    Other than that bug testing is important. And doing that on your own code is tough. And I am not pointing to unit tests, but real human testing. Doing this might not be your ideal Position, but helps you really think about how to build code to prevent Errors/bugs in the first place.






                    share|improve this answer























                      up vote
                      1
                      down vote










                      up vote
                      1
                      down vote









                      Discuss some stories, when you got an Idee if any just put it out there. The entire Idea of sprint planning is to brainstorm not to go with whatever "tom" said. Maybe your idea´s are better than you think. Sitting on the back of your seat aint going to work for you.



                      Other than that bug testing is important. And doing that on your own code is tough. And I am not pointing to unit tests, but real human testing. Doing this might not be your ideal Position, but helps you really think about how to build code to prevent Errors/bugs in the first place.






                      share|improve this answer













                      Discuss some stories, when you got an Idee if any just put it out there. The entire Idea of sprint planning is to brainstorm not to go with whatever "tom" said. Maybe your idea´s are better than you think. Sitting on the back of your seat aint going to work for you.



                      Other than that bug testing is important. And doing that on your own code is tough. And I am not pointing to unit tests, but real human testing. Doing this might not be your ideal Position, but helps you really think about how to build code to prevent Errors/bugs in the first place.







                      share|improve this answer













                      share|improve this answer



                      share|improve this answer











                      answered May 30 '16 at 7:24









                      Raoul Mensink

                      1,267317




                      1,267317




















                          up vote
                          0
                          down vote













                          Its a good opportunity for you, take the challenging task ask question to your talented team member definitely he will help you out. You will learn a lot from him and don't feel like you are pretty useless its your mistake that you are not coming front to take the tasks, after him you only the point of contact its just that you didn't contribute much from your side but you know each and everything in that project.



                          Take the new stories discuss with your team mates and start working on that's how a team works, all the team members will not be equally talented but you need to learn utilizing the talent of others by asking them politely, but be sure that you are not boring them by asking silly question and not trying anything from your side that will keep you productive in the team.






                          share|improve this answer

























                            up vote
                            0
                            down vote













                            Its a good opportunity for you, take the challenging task ask question to your talented team member definitely he will help you out. You will learn a lot from him and don't feel like you are pretty useless its your mistake that you are not coming front to take the tasks, after him you only the point of contact its just that you didn't contribute much from your side but you know each and everything in that project.



                            Take the new stories discuss with your team mates and start working on that's how a team works, all the team members will not be equally talented but you need to learn utilizing the talent of others by asking them politely, but be sure that you are not boring them by asking silly question and not trying anything from your side that will keep you productive in the team.






                            share|improve this answer























                              up vote
                              0
                              down vote










                              up vote
                              0
                              down vote









                              Its a good opportunity for you, take the challenging task ask question to your talented team member definitely he will help you out. You will learn a lot from him and don't feel like you are pretty useless its your mistake that you are not coming front to take the tasks, after him you only the point of contact its just that you didn't contribute much from your side but you know each and everything in that project.



                              Take the new stories discuss with your team mates and start working on that's how a team works, all the team members will not be equally talented but you need to learn utilizing the talent of others by asking them politely, but be sure that you are not boring them by asking silly question and not trying anything from your side that will keep you productive in the team.






                              share|improve this answer













                              Its a good opportunity for you, take the challenging task ask question to your talented team member definitely he will help you out. You will learn a lot from him and don't feel like you are pretty useless its your mistake that you are not coming front to take the tasks, after him you only the point of contact its just that you didn't contribute much from your side but you know each and everything in that project.



                              Take the new stories discuss with your team mates and start working on that's how a team works, all the team members will not be equally talented but you need to learn utilizing the talent of others by asking them politely, but be sure that you are not boring them by asking silly question and not trying anything from your side that will keep you productive in the team.







                              share|improve this answer













                              share|improve this answer



                              share|improve this answer











                              answered May 30 '16 at 7:10









                              Ali786

                              1551212




                              1551212




















                                  up vote
                                  0
                                  down vote













                                  Are you sure that Tom is the genius that you think he is? This reads like the introduction to a Daily WTF story, where Tom comes on and reimplements the system and talks a good line, but whenever anyone actually looks at his code, it's actually slipshod and baseless.



                                  It's certainly possible that Tom knows what he is doing (and you should have one of the senior developers confirm that for you), in which case hopefully he can teach you a lot, but my guess is that Tom thinks he knows a hell of a lot more than he actually does, in which case you will benefit by slowly building up your skills, and being wary of anything that Tom does that is too quick and/or too easy.






                                  share|improve this answer





















                                  • "Tom thinks he knows a hell of a lot more than he actually does". That usually covers the incompetent to "mildly" competent developers. The really good ones tend to think they don't know enough. On the flip-side, while the really good developers tend to think they don't know enough, they do know enough to realize that their co-workers know far less; so they know they have be assertive or their project is doomed.
                                    – Dunk
                                    Jun 2 '16 at 14:14















                                  up vote
                                  0
                                  down vote













                                  Are you sure that Tom is the genius that you think he is? This reads like the introduction to a Daily WTF story, where Tom comes on and reimplements the system and talks a good line, but whenever anyone actually looks at his code, it's actually slipshod and baseless.



                                  It's certainly possible that Tom knows what he is doing (and you should have one of the senior developers confirm that for you), in which case hopefully he can teach you a lot, but my guess is that Tom thinks he knows a hell of a lot more than he actually does, in which case you will benefit by slowly building up your skills, and being wary of anything that Tom does that is too quick and/or too easy.






                                  share|improve this answer





















                                  • "Tom thinks he knows a hell of a lot more than he actually does". That usually covers the incompetent to "mildly" competent developers. The really good ones tend to think they don't know enough. On the flip-side, while the really good developers tend to think they don't know enough, they do know enough to realize that their co-workers know far less; so they know they have be assertive or their project is doomed.
                                    – Dunk
                                    Jun 2 '16 at 14:14













                                  up vote
                                  0
                                  down vote










                                  up vote
                                  0
                                  down vote









                                  Are you sure that Tom is the genius that you think he is? This reads like the introduction to a Daily WTF story, where Tom comes on and reimplements the system and talks a good line, but whenever anyone actually looks at his code, it's actually slipshod and baseless.



                                  It's certainly possible that Tom knows what he is doing (and you should have one of the senior developers confirm that for you), in which case hopefully he can teach you a lot, but my guess is that Tom thinks he knows a hell of a lot more than he actually does, in which case you will benefit by slowly building up your skills, and being wary of anything that Tom does that is too quick and/or too easy.






                                  share|improve this answer













                                  Are you sure that Tom is the genius that you think he is? This reads like the introduction to a Daily WTF story, where Tom comes on and reimplements the system and talks a good line, but whenever anyone actually looks at his code, it's actually slipshod and baseless.



                                  It's certainly possible that Tom knows what he is doing (and you should have one of the senior developers confirm that for you), in which case hopefully he can teach you a lot, but my guess is that Tom thinks he knows a hell of a lot more than he actually does, in which case you will benefit by slowly building up your skills, and being wary of anything that Tom does that is too quick and/or too easy.







                                  share|improve this answer













                                  share|improve this answer



                                  share|improve this answer











                                  answered Jun 1 '16 at 17:47









                                  JasonB

                                  11113




                                  11113











                                  • "Tom thinks he knows a hell of a lot more than he actually does". That usually covers the incompetent to "mildly" competent developers. The really good ones tend to think they don't know enough. On the flip-side, while the really good developers tend to think they don't know enough, they do know enough to realize that their co-workers know far less; so they know they have be assertive or their project is doomed.
                                    – Dunk
                                    Jun 2 '16 at 14:14

















                                  • "Tom thinks he knows a hell of a lot more than he actually does". That usually covers the incompetent to "mildly" competent developers. The really good ones tend to think they don't know enough. On the flip-side, while the really good developers tend to think they don't know enough, they do know enough to realize that their co-workers know far less; so they know they have be assertive or their project is doomed.
                                    – Dunk
                                    Jun 2 '16 at 14:14
















                                  "Tom thinks he knows a hell of a lot more than he actually does". That usually covers the incompetent to "mildly" competent developers. The really good ones tend to think they don't know enough. On the flip-side, while the really good developers tend to think they don't know enough, they do know enough to realize that their co-workers know far less; so they know they have be assertive or their project is doomed.
                                  – Dunk
                                  Jun 2 '16 at 14:14





                                  "Tom thinks he knows a hell of a lot more than he actually does". That usually covers the incompetent to "mildly" competent developers. The really good ones tend to think they don't know enough. On the flip-side, while the really good developers tend to think they don't know enough, they do know enough to realize that their co-workers know far less; so they know they have be assertive or their project is doomed.
                                  – Dunk
                                  Jun 2 '16 at 14:14











                                  up vote
                                  0
                                  down vote













                                  He takes the time to do pair programming and instruct you, so try to learn from him.



                                  I have a younger colleague much less experienced than me (I am programming since before she was born). We don't do pair programming, but regular code reviews, and after 1-2 months I can see her getting better to a point that I estimate that in 1-3 months i can remove myself from that part of the project and let her do it on her own.



                                  So if your team and the senior developer have the right attitude (to learn and have him free for other stuff after some time), the world should be fine.



                                  Some practical advice:



                                  • in a sprint you should evaluate how you see the task - evaluating user stories only works if everybody give his opinion


                                  • committing to a task does not mean that you have to do it without help - ask for help in the daily standup


                                  • if backlog stories get so complicated that only one person in team even feels able to understand the impact and scope of them, (assuming you scrum), then refining/splitting the story is needed. Having a story description which is not understood by the team as a whole is not acceptable.


                                  • To me it seems that he has much of the architecture in his head, which may make it terribly difficult to follow. Maybe you can have a "document" the architecture story.






                                  share|improve this answer

























                                    up vote
                                    0
                                    down vote













                                    He takes the time to do pair programming and instruct you, so try to learn from him.



                                    I have a younger colleague much less experienced than me (I am programming since before she was born). We don't do pair programming, but regular code reviews, and after 1-2 months I can see her getting better to a point that I estimate that in 1-3 months i can remove myself from that part of the project and let her do it on her own.



                                    So if your team and the senior developer have the right attitude (to learn and have him free for other stuff after some time), the world should be fine.



                                    Some practical advice:



                                    • in a sprint you should evaluate how you see the task - evaluating user stories only works if everybody give his opinion


                                    • committing to a task does not mean that you have to do it without help - ask for help in the daily standup


                                    • if backlog stories get so complicated that only one person in team even feels able to understand the impact and scope of them, (assuming you scrum), then refining/splitting the story is needed. Having a story description which is not understood by the team as a whole is not acceptable.


                                    • To me it seems that he has much of the architecture in his head, which may make it terribly difficult to follow. Maybe you can have a "document" the architecture story.






                                    share|improve this answer























                                      up vote
                                      0
                                      down vote










                                      up vote
                                      0
                                      down vote









                                      He takes the time to do pair programming and instruct you, so try to learn from him.



                                      I have a younger colleague much less experienced than me (I am programming since before she was born). We don't do pair programming, but regular code reviews, and after 1-2 months I can see her getting better to a point that I estimate that in 1-3 months i can remove myself from that part of the project and let her do it on her own.



                                      So if your team and the senior developer have the right attitude (to learn and have him free for other stuff after some time), the world should be fine.



                                      Some practical advice:



                                      • in a sprint you should evaluate how you see the task - evaluating user stories only works if everybody give his opinion


                                      • committing to a task does not mean that you have to do it without help - ask for help in the daily standup


                                      • if backlog stories get so complicated that only one person in team even feels able to understand the impact and scope of them, (assuming you scrum), then refining/splitting the story is needed. Having a story description which is not understood by the team as a whole is not acceptable.


                                      • To me it seems that he has much of the architecture in his head, which may make it terribly difficult to follow. Maybe you can have a "document" the architecture story.






                                      share|improve this answer













                                      He takes the time to do pair programming and instruct you, so try to learn from him.



                                      I have a younger colleague much less experienced than me (I am programming since before she was born). We don't do pair programming, but regular code reviews, and after 1-2 months I can see her getting better to a point that I estimate that in 1-3 months i can remove myself from that part of the project and let her do it on her own.



                                      So if your team and the senior developer have the right attitude (to learn and have him free for other stuff after some time), the world should be fine.



                                      Some practical advice:



                                      • in a sprint you should evaluate how you see the task - evaluating user stories only works if everybody give his opinion


                                      • committing to a task does not mean that you have to do it without help - ask for help in the daily standup


                                      • if backlog stories get so complicated that only one person in team even feels able to understand the impact and scope of them, (assuming you scrum), then refining/splitting the story is needed. Having a story description which is not understood by the team as a whole is not acceptable.


                                      • To me it seems that he has much of the architecture in his head, which may make it terribly difficult to follow. Maybe you can have a "document" the architecture story.







                                      share|improve this answer













                                      share|improve this answer



                                      share|improve this answer











                                      answered May 28 '17 at 11:59









                                      Sascha

                                      6,06521231




                                      6,06521231






















                                           

                                          draft saved


                                          draft discarded


























                                           


                                          draft saved


                                          draft discarded














                                          StackExchange.ready(
                                          function ()
                                          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f67949%2fwhat-should-i-do-when-i-feel-overshadowed-by-an-extremely-talented-team-member%23new-answer', 'question_page');

                                          );

                                          Post as a guest




































































                                          Comments

                                          Post a Comment

                                          Popular posts from this blog

                                          What does second last employer means? [closed]

                                          Image
                                          Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote -3 down vote favorite Say, for example I have worked in the following companies, Company A => 2010 - 2011 Company B => 2011 - 2012 Company C => 2012 - Till Date Company D => Have offer Now assume Company D is asking to submit documents from my second last employer. So from the list of companies given, which company would be qualified as second last employer? software-industry employer share | improve this question asked Aug 10 '14 at 5:16 Rajaprabhu Aravindasamy 559 1 6 13 closed as off-topic by Jim G., jmort253 ♦ Aug 11 '14 at 1:58 This question appears to be off-topic. The users who voted to close gave this specific reason: "Questions seeking advice on company-specific regulations, agreements, or policies should be directed to your manager or HR department. Questions that address...
                                          Read more

                                          List of Gilmore Girls characters

                                          Image
                                          The season three cast—(Back row): Lane, Michel, Paris, Emily, Richard, Sookie, Miss Patty, Kirk; Front row: Jess, Luke, Lorelai, Rory, Dean This is a list of characters for the comedy-drama television series Gilmore Girls . Contents 1 Main characters 1.1 Lorelai Gilmore 1.2 Rory Gilmore 1.3 Sookie St. James 1.4 Lane Kim 1.5 Michel Gerard 1.6 Luke Danes 1.7 Emily Gilmore 1.8 Richard Gilmore 1.9 Paris Geller 1.10 Dean Forester 1.11 Jess Mariano 1.12 Kirk Gleason 1.13 Jason Stiles 1.14 Logan Huntzberger 2 Major recurring characters 2.1 Christopher Hayden 2.2 Jackson Belleville 2.3 Mrs. Kim 2.4 Tristin DuGray 2.5 Max Medina 2.6 Taylor Doose 2.7 Dave Rygalski 2.8 Marty 3 Recurring characters 3.1 Stars Hollow 3.2 Chilton 3.3 Yale 3.4 Other 4 Notable guest stars 5 Unseen characters 6 Notes 7 References Main characters Actor Character Appearances Season 1 Season 2 Season 3 Season 4 Season 5 Season 6 Season 7 A Year in the Life Lauren Graham Lorelai Gilmore...
                                          Read more

                                          One-line joke

                                          A one-liner is a joke that is delivered in a single line. A good one-liner is said to be pithy - concise and meaningful. [1] Comedians and actors use this comedic method as part of their act, e.g. Jimmy Carr, Tommy Cooper, Rodney Dangerfield, Norm Macdonald, Ken Dodd, Stewart Francis, Zach Galifianakis, Mitch Hedberg, Anthony Jeselnik, Milton Jones, Shappi Khorsandi, Jay London, Mark Linn-Baker, Demetri Martin, Groucho Marx, Dan Mintz, Emo Philips, Tim Vine, Steven Wright and Henny Youngman and Arnold Schwarzenegger. [ citation needed ] Many fictional characters are also known to deliver one-liners, including James Bond, who usually includes pithy and laconic quips after disposing of a villain. [ citation needed ] Examples "A baby seal walks into a club." "A dyslexic man walks into a bra." (Anonymous) "There are three types of people, those who can count and those who can't." "Venison's dear, isn't it?" (Jimmy Carr) "An escala...
                                          Read more