24

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.

Improve this question
9
  • 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
    Commented May 30, 2016 at 5:09
  • 14
    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
    Commented May 30, 2016 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
    Commented May 30, 2016 at 14:46
  • 5
    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
    Commented May 30, 2016 at 17:22
  • 7
    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
    Commented Jun 1, 2016 at 15:48

10 Answers 10

Reset to default
25

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.

Improve this answer
3
  • 1
    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
    Commented Jun 2, 2016 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
    Commented Jun 9, 2017 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
    Commented Jun 9, 2017 at 16:21
23

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.

Improve this answer
2
  • 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
    Commented May 30, 2016 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
    Commented May 31, 2016 at 15:23
12

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.

Improve this answer
3
  • 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
    Commented May 30, 2016 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
    Commented May 31, 2016 at 20:41
  • 2
    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
    Commented Jun 2, 2016 at 14:09
3

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.

Improve this answer
2

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.

Improve this answer
1
  • "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
    Commented Jun 2, 2016 at 14:14
1

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.

Improve this answer
1

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.

Improve this answer
1
  • A story is generally something where the customer can say, "I don't want that right now; I want this other thing instead." Things you need that are not business features should typically not be stories but tasks that are automatically part of stories when you estimate them, just like unit tests, refactoring or any other technical requirement you need to keep your code base in good enough shape that it doesn't slow down your development.
    – cjs
    Commented Mar 12 at 10:08
0

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.

Improve this answer
0

Learn from them. Watch how they approach tasks, ask for advice/guidance when you need it, ask them whether there are places you could be working more closely with them to accelerate that transfer if experience and knowledge.

This should be seen as an opportunity, not a threat. And both you learning from them and then helping improve your skills will look good on the year-end review, especially if you can point to specific growth and accomplishments.

Improve this answer
0

We tried pair-programming, but he ended up being the brain behind this re-architecture.

That's not a problem. Pair programming isn't always about two co-equals doing the design and coding together; it is frequently also used to bring someone less knowledgeable (whether a junior developer or just someone new to the project) up to speed.

I suggest that you continue pair programming, even if not all the time, because even if you're not doing the "work" yet, you're watching, learning, and asking questions. In particular, see if you can get Tom to "think out loud" as you pair-program, so you can develop a sense of how he's making his decisions about what to do.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .