Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Possible Duplicate:
Charles Barkley syndrome

I've worked on a project where I've been the goto character that I'm sure many people are familiar with:

  • The guy who knows how every bit of the system works, and how each part has evolved.
  • The guy who knows where the buggy bits are.
  • The guy who knows how to diagnose every stack trace his colleagues can throw his way.

I've also assumed the role on other projects of a solid developer who can be counted on to churn out good quality code, but is someone who stays in the background and doesn't influence the project in the same way as the main guy.

If I were to join a new project team tomorrow, I'm not sure which role I would try to assume. I've found being the top dog to be a source of personal satisfaction, but also quite exhausting and disruptive (it's not so easy to plan your day at the office when anything can be thrown your way). On the other hand, I've found that keeping a sense of detachment between myself and my project can cause work to become, well, a little dull. I am young and ambitious, but at the same time I don't want work to sap me of my energy! Does anyone else wrestle with this dilemma, and if so how do you find a rewarding middle path?

share|improve this question

marked as duplicate by Jarrod Roberson, Karl Bielefeldt, gnat, Mark Trapp Feb 5 '12 at 20:26

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Your role may not be something you can choose. What your role in the team becomes will depend a lot on the knowledge, experience, capabilities, desires and ambitions of other members in the team . –  Marjan Venema Feb 5 '12 at 15:39
This isn't a debate or forum, and if you put just a fraction of the effort in looking for duplicates instead of apologizing for creating them, the place would be a cleaner better place for everyone. –  Jarrod Roberson Feb 5 '12 at 16:37
We have more Q's that are deemed invalid than not. What is this substack really for? –  Conrad.Dean Feb 5 '12 at 19:18
Closed as duplicate of a closed question? I don't understand. –  user2567 Feb 6 '12 at 15:11

7 Answers 7

up vote 20 down vote accepted

To be a solid team member, you should be a goto developer too.

Everyone in the team is supposed to collaborate and help other team members. Everything is not black or white. The problem you describe can be "fixed" if you ensure that everyone in the team take the responsability for the code. You can't be the owner of the code. It is not good for the team, not good for your employer and not good for you as you describe it.

Please consider the following ideas:

  • Document everything that deserve to be documented. Put documentation about the buggy bits, create the TODO in the code, create a bug or task for each problem that deserve to be logged.
  • Create an overall architecture document. Take the necessary time to do it. Present it to the whole team. Take 4h meeting if needed. Ask for feedback. Improve the document. Give the document to every new developer that enter in the team. Every team member should (with a rotating basis) help the newcomer to dive in the project (not you alone anymore).
  • Create a development wiki in which you add every error message your team members receive together with the solution. You'll help build the team knowledge.
  • Divide your day into chunks with dedicated space for team help. Your colleague can ask your questions but at certain moment only. I know people that used "codes" to notify their colleagues they needed concentration. One of them was headphones (when put, nobody should disturb him for not extremely urgent matters).

If you do that, you won't be the sole goto developer anymore and become a really solid team member.

share|improve this answer
+1 for you can't be the owner of the code. I've been guilty of storing a lot of information in my head even when the media you've described (wikis, bug tracking systems, design docs) have been at my disposal. –  avik Feb 5 '12 at 16:54
Perhaps this is why he doesn't want to be a "goto" developer --- –  IDWMaster Feb 5 '12 at 20:23
@IDWMaster: Oh there is a lot of things I don't want. But in a life, it's not possible to remove all constraints. Collaboration in a team looks like a requirement to me. –  user2567 Feb 6 '12 at 8:04

I recently went through the transition from being the go to guy who knows every system like the back of his hand to a new environment that is extremely unfamiliar. Ive found that I very quickly found my own niche in my new team. Also, while I too got great satisfaction from being the go to guy, ive really enjoyed not being that guy and being able to get on with things without the interruptions which were so frequent before. Ironically, being left to get on with things has kind of made me the go to guy for other things, but not to the same disruptive extent as before.

I think if you are capable, you will find your place in whichever team you are a member. Its just a matter of finding what makes you happiest.

share|improve this answer

Consider the question this way. Do you want to be the person dealing with other people all the time? That is what the goto developer seems to have from what you describe. In a new team, I'd suspect this comes if your skills significantly trump most of the rest of the team as otherwise there may be others that won't always come to you with stuff. The person knowing most of the inner workings of a system generally has to have been in the system for a while and show a great memory of knowing how things connect in the system, in my experience anyway.

Finding the balance between being in the spotlight that fixes the big problems for the team and being in the background as a good worker can be a challenge though consider each has its advantages and disadvantages. Some times it may be better to take the spotlight and be the hero and sometimes it may be better to let someone else take the spotlight. At least that is how I see it.

Be careful of the difference between arrogant and humility here. The goto developer may be seen as the former while the solid team player may be seen as the latter. If one is the goto developer, there is the question of whether one is passing along the knowledge and developing the skills of other developers so that others can get on the same level rather than hoarding information so that the goto developer may come across as egotistical.

share|improve this answer

Both of these roles are important to a team, so you could choose what you like best and what brings you the most satisfaction. The role you choose can also depend on who else is on your team that can also take on either of these roles, meaning sometimes you can be the "top dog" and other times you can be the "solid developer". You could also take on both roles at once, but that will be difficult as you already mentioned (i.e. constant interruptions). Choose what will work best for the team you are currently part of.

share|improve this answer

You make a distinction between being somone who is a good delveoper and someone who knows the code well. Normally the two go hand in hand, its hard to make good choices about how to extend or change a codebase unless you have a good understanding of it.

If your finding that questions about the code are becoming distracting I suggest you start a Wiki. That will stop you having similar questions asked repeatedly.

share|improve this answer

None of the above. Be the guy who does the things that need doing. Over time it will make you the first two bullet points and half of the third one.

share|improve this answer

Well that's kind of a false dichotomy. I mean, you speak of being the project's "top dog" and I wouldn't really recommend that approach for a lot of reasons, including that it makes life more hectic for you and because your employers will be suspicious of a person who hoards information.

On the other hand, the best team players are the goto guy for something the team needs. So while you shouldn't attempt to control the entire project, you should take ownership* of some aspect of the project. Now as long as you get the other team player behaviors right (in particular, communication) then the team can and will rely on you for that aspect of the project.

*incidentally, by "ownership" I don't mean that you hoard information about aspect, or push others away, but that you take charge of making sure that part of the project is getting handled correctly.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.