New job related question
-
Is it appropriate to go to a co-worker or a team lead if one is having a coding problem? ... I mean when they "hit a wall" etc. ... especially if it involves developing within the company's infrastructure ... The only advantage that I can think of is saving time ... if I were a senior person in a company I would rather have the new-comer drop by my cube and ask me the "how to ..." so that we can quickly get it out of the way and that person can get along with the project itself rather than struggling for 2 hours on one problem ...
Um, why not just strike up a conversation with the new guy and ask if he has any questions about the system in a non-attacking manner? I've heard somewhere that people can still talk to one another. :rolleyes: Running around telling a senior is only going to put you on this guy's shitlist. Personally, I've seen this happen before. It should've been avoided by training the new guy before you stuck him on an important part of the system. This happening is usually a sign of piss-poor management in the first place. Jeremy Falcon
-
Pete Madden wrote:
Is it appropriate to go to a co-worker or a team lead if one is having a coding problem?
Yes. If I don't know something then I ask someone. I'll spend a reasonable amount of time trying to figure it out myself (mainly so that I can ask the right questions if I do run into problems). If I get stuck, then first I'll ask 'Google' and if that is no use then I'll ask a co-worker. Sometimes the best way to learn is to have a problem's solution be explained to us. Michael CP Blog [^] Development Blog [^]
Michael P Butler wrote:
Yes.
Yeah, but it would be better for Pete to just go talk to the guy rather than run around and "tattle tell" on the new guy. Jeremy Falcon
-
Michael P Butler wrote:
Yes.
Yeah, but it would be better for Pete to just go talk to the guy rather than run around and "tattle tell" on the new guy. Jeremy Falcon
What made you think that I am NOT the "New Guy"?
-
Is it appropriate to go to a co-worker or a team lead if one is having a coding problem? ... I mean when they "hit a wall" etc. ... especially if it involves developing within the company's infrastructure ... The only advantage that I can think of is saving time ... if I were a senior person in a company I would rather have the new-comer drop by my cube and ask me the "how to ..." so that we can quickly get it out of the way and that person can get along with the project itself rather than struggling for 2 hours on one problem ...
Pete Madden wrote:
if I were a senior person in a company I would rather have the new-comer drop by my cube and ask me the "how to ..."
That depends, what if he came with a really stupid question three times a day, i would rather talk to my co-worker than my boss or team lead, better yet when talking to the lead take the team member with you and explain that we have been stuck on this for a long time and we have done good amount of research on this.
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg
-
Um, why not just strike up a conversation with the new guy and ask if he has any questions about the system in a non-attacking manner? I've heard somewhere that people can still talk to one another. :rolleyes: Running around telling a senior is only going to put you on this guy's shitlist. Personally, I've seen this happen before. It should've been avoided by training the new guy before you stuck him on an important part of the system. This happening is usually a sign of piss-poor management in the first place. Jeremy Falcon
In the above mentioned scenario there is no 3rd person involved ... its just the new guy and the senior guy ... I just asked to know how things work in the corp. world.
-
Pete Madden wrote:
Is it appropriate to go to a co-worker or a team lead if one is having a coding problem?
Yes. If I don't know something then I ask someone. I'll spend a reasonable amount of time trying to figure it out myself (mainly so that I can ask the right questions if I do run into problems). If I get stuck, then first I'll ask 'Google' and if that is no use then I'll ask a co-worker. Sometimes the best way to learn is to have a problem's solution be explained to us. Michael CP Blog [^] Development Blog [^]
Thanks! ... I usually do it like that ... first try solving it myself, then google and then go to the sr. person.
-
What made you think that I am NOT the "New Guy"?
Because you never said it was you. :) Jeremy Falcon
-
In the above mentioned scenario there is no 3rd person involved ... its just the new guy and the senior guy ... I just asked to know how things work in the corp. world.
Pete Madden wrote:
I just asked to know how things work in the corp. world.
Then if it's you, then definately go to the senior guy and start asking a buttload of questions. Unless he's a retard, he'll be glad you did. Jeremy Falcon
-
Pete Madden wrote:
if I were a senior person in a company I would rather have the new-comer drop by my cube and ask me the "how to ..."
That depends, what if he came with a really stupid question three times a day, i would rather talk to my co-worker than my boss or team lead, better yet when talking to the lead take the team member with you and explain that we have been stuck on this for a long time and we have done good amount of research on this.
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg
Monty v2.0 wrote:
That depends, what if he came with a really stupid question three times a day
hmmm ... true ... I should be careful on what I ask ... although I don't ask "basic" or "stupid" questions I think it would be wise to not ask anything about general programming like say something wrong with C# code for instance ... I feel it will only do more harm than good ...
-
Pete Madden wrote:
if I were a senior person in a company I would rather have the new-comer drop by my cube and ask me the "how to ..."
That depends, what if he came with a really stupid question three times a day, i would rather talk to my co-worker than my boss or team lead, better yet when talking to the lead take the team member with you and explain that we have been stuck on this for a long time and we have done good amount of research on this.
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg
Monty v2.0 wrote:
what if he came with a really stupid question three times a day
Then you need to better your interviewing techniques. :) Jeremy Falcon
-
Pete Madden wrote:
I just asked to know how things work in the corp. world.
Then if it's you, then definately go to the senior guy and start asking a buttload of questions. Unless he's a retard, he'll be glad you did. Jeremy Falcon
wow! ... you are something.
-
wow! ... you are something.
So now you're gonna be an ass because you didn't say you were talking about yourself? Damn dude, go take some prozac. Jeremy Falcon
-
Is it appropriate to go to a co-worker or a team lead if one is having a coding problem? ... I mean when they "hit a wall" etc. ... especially if it involves developing within the company's infrastructure ... The only advantage that I can think of is saving time ... if I were a senior person in a company I would rather have the new-comer drop by my cube and ask me the "how to ..." so that we can quickly get it out of the way and that person can get along with the project itself rather than struggling for 2 hours on one problem ...
Pete Madden wrote:
The only advantage that I can think of is saving time
And to the company that is money. You and the company want you to make money for your mutual benefit. Work should not be an ego test. There is no such thing as a stupid question. Something basic for you but maybe it was some area they just did not get involved in or missed the point of the task. Now when the same question arrises day after day for weeks, then yes you got the wrong person for that position, do something about it if you can. In a large organization, that is not allways an option. "Every new day begins with possibilities. It's up to us to fill it with things that move us toward progress and peace.” (Ronald Reagan)
-
Is it appropriate to go to a co-worker or a team lead if one is having a coding problem? ... I mean when they "hit a wall" etc. ... especially if it involves developing within the company's infrastructure ... The only advantage that I can think of is saving time ... if I were a senior person in a company I would rather have the new-comer drop by my cube and ask me the "how to ..." so that we can quickly get it out of the way and that person can get along with the project itself rather than struggling for 2 hours on one problem ...
The short answer: Yes. The real answer: It depends. You've got several possible situations here: 1. ProblemGuy is stuck, and needs a fresh viewpoint to get started again. He explains what he's tried, but he's had a tough time getting outside the box. Good enough; help him out. 2. ProblemGuy is stuck for the third time this week. You wonder why they ever hired him, and then you remember he's the CTO's wife's second cousin. You reach the point where you're always checking on him, making sure he's not wandered off into the weeds. You don't want his part of the project to drag yours down. 3. ProblemGuy is a political animal (of the reptile variety). He has a habit of asking for help, but never seems to follow it. In review meetings, he's always complaining that he tried 'thus and so's approach' but they never seem to work out. You feel betrayed, and the P.H.B. wonders why ProblemGuy is the only one who seems to have the right answers. There are other possibilities. I don't think you can create a blanket policy. There's a line between the efficiency of getting a quick answer and not having the rocks to figure a problem out for yourself.
Software Zen:
delete this; -
Monty v2.0 wrote:
what if he came with a really stupid question three times a day
Then you need to better your interviewing techniques. :) Jeremy Falcon
Jeremy Falcon wrote:
Then you need to better your interviewing techniques.
Very true, my interviewing techniques are pathetic, its all about if i like the guy or not rather than his coding skills and i have been wrong in the past X| , but still its hard to change.
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg
-
Jeremy Falcon wrote:
Then you need to better your interviewing techniques.
Very true, my interviewing techniques are pathetic, its all about if i like the guy or not rather than his coding skills and i have been wrong in the past X| , but still its hard to change.
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg
I am no expert on interviewing but I think your criteria seems to be right ... if you don't like the guy its a ticking bomb from the start. Coding can be taught but you cannot take an unsocial code monkey and refine its social skills.
-
I am no expert on interviewing but I think your criteria seems to be right ... if you don't like the guy its a ticking bomb from the start. Coding can be taught but you cannot take an unsocial code monkey and refine its social skills.
-
The short answer: Yes. The real answer: It depends. You've got several possible situations here: 1. ProblemGuy is stuck, and needs a fresh viewpoint to get started again. He explains what he's tried, but he's had a tough time getting outside the box. Good enough; help him out. 2. ProblemGuy is stuck for the third time this week. You wonder why they ever hired him, and then you remember he's the CTO's wife's second cousin. You reach the point where you're always checking on him, making sure he's not wandered off into the weeds. You don't want his part of the project to drag yours down. 3. ProblemGuy is a political animal (of the reptile variety). He has a habit of asking for help, but never seems to follow it. In review meetings, he's always complaining that he tried 'thus and so's approach' but they never seem to work out. You feel betrayed, and the P.H.B. wonders why ProblemGuy is the only one who seems to have the right answers. There are other possibilities. I don't think you can create a blanket policy. There's a line between the efficiency of getting a quick answer and not having the rocks to figure a problem out for yourself.
Software Zen:
delete this;There is no Neopotism involved and politics is not my cup of tea so I guess I do fall under the Ist category.:) Taking pride in one's work is good as long as ego isn't a part of it.
-
Pete Madden wrote:
The only advantage that I can think of is saving time
And to the company that is money. You and the company want you to make money for your mutual benefit. Work should not be an ego test. There is no such thing as a stupid question. Something basic for you but maybe it was some area they just did not get involved in or missed the point of the task. Now when the same question arrises day after day for weeks, then yes you got the wrong person for that position, do something about it if you can. In a large organization, that is not allways an option. "Every new day begins with possibilities. It's up to us to fill it with things that move us toward progress and peace.” (Ronald Reagan)
Michael A. Barnhart wrote:
And to the company that is money. You and the company want you to make money for your mutual benefit.
You bet!
Michael A. Barnhart wrote:
Work should not be an ego test.
Very true ... infact I've seen that the best developers implement that sincerely. ########################## Taking pride in one's work is good as long as ego isn't a part of it. ##########################
-
Jeremy Falcon wrote:
Then you need to better your interviewing techniques.
Very true, my interviewing techniques are pathetic, its all about if i like the guy or not rather than his coding skills and i have been wrong in the past X| , but still its hard to change.
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg
Monty v2.0 wrote:
its all about if i like the guy or not
Well, as said already that's important too. After all, you're going to be spending a lot of time with the coworker. Jeremy Falcon