A Developer in need is a Developer indeed...
-
I usually say to my Team mates that when they get any complex issue, don't just rush to get it done soon by taking help from other mate(s) the same time. Instead try resolving it by themselve first by understanding the cause of issue and doing other analysis; set some cut off time for resolving it according to the need (if there is any urgent release). And if the issue is about crossing the said time then take the help of others to get it resolved. By following this way, we can learn a lot and in future if same issue appears it can be tracked easily and hence can be resolved quickly. What's your views on this, please suggest. Thanks
My Reading-o-Meter
Previous -> Read "CLR via C#" by Jeffrey Richter. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
1. Ask if the issue/feature has appeared before and therefore might not need new code/much work. 2. Work on it assuming 1 is bad. 3. Ask once you've tried some stuff. Not without trying though. It's quite annoying to ask for help when you've tried nothing and expect everything to be served.
-
1. Ask if the issue/feature has appeared before and therefore might not need new code/much work. 2. Work on it assuming 1 is bad. 3. Ask once you've tried some stuff. Not without trying though. It's quite annoying to ask for help when you've tried nothing and expect everything to be served.
I think #3 is what Mohammed was trying to say; give it a fair attempt on your own, but don't allow yourself to just spin your wheels. Points 1 and 2 are just as valid. If there's something you can get re-use from, find out about it and do so, don't reinvent.
-
I usually say to my Team mates that when they get any complex issue, don't just rush to get it done soon by taking help from other mate(s) the same time. Instead try resolving it by themselve first by understanding the cause of issue and doing other analysis; set some cut off time for resolving it according to the need (if there is any urgent release). And if the issue is about crossing the said time then take the help of others to get it resolved. By following this way, we can learn a lot and in future if same issue appears it can be tracked easily and hence can be resolved quickly. What's your views on this, please suggest. Thanks
My Reading-o-Meter
Previous -> Read "CLR via C#" by Jeffrey Richter. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
I don't work on a team anymore, but back when I did we had a one hour rule: if you couldn't figure it out in an hour, ask for help. This applied to problem-solving, not so much coding practices or requirements, for instance trying to get the right results from a complex SQL query or debugging a difficult issue. The idea is that you don't want someone spinning their wheels and wasting time on a problem that could be solved much faster with some help from a more experienced programmer, but you also don't want someone asking for help with every little thing, which will annoy everyone, and the person asking for help will never learn to do it on his/her own. It was really a mentoring rule for how the senior programmers helped the junior ones. I used to work with a junior programmer who literally asked for help with everything, from the beginning he had no confidence and wouldn't produce any code without having his hand held; he had negative productivity, never really learned to program, and had to find another job. Another new hire sat quietly in a corner and failed, too embarrassed to ask for help or even take it when it was offered. Either extreme is a death trap for a junior programmer.
-
I usually say to my Team mates that when they get any complex issue, don't just rush to get it done soon by taking help from other mate(s) the same time. Instead try resolving it by themselve first by understanding the cause of issue and doing other analysis; set some cut off time for resolving it according to the need (if there is any urgent release). And if the issue is about crossing the said time then take the help of others to get it resolved. By following this way, we can learn a lot and in future if same issue appears it can be tracked easily and hence can be resolved quickly. What's your views on this, please suggest. Thanks
My Reading-o-Meter
Previous -> Read "CLR via C#" by Jeffrey Richter. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
Lots of good stuff here, from the arrogant a-holes to the overhelpers. One thing I like about Agile is the ten minute meeting in the morning with the team to find out where everyone is at; currently we don't do that where i am now. :laugh: So, in my past experiences, just do it. if your unsure of what your doing, ask for some pointers, other code that someone may know of that is similar to the solution. Work with the nice people and stay away from the a-holes, you don't need their help and they always end up with their head up their, ya know. :wtf: YOUR ON DEVELOPMENT, FOR CHRIST SAKES TRY AND BRING IT DOWN :doh:
-
I usually say to my Team mates that when they get any complex issue, don't just rush to get it done soon by taking help from other mate(s) the same time. Instead try resolving it by themselve first by understanding the cause of issue and doing other analysis; set some cut off time for resolving it according to the need (if there is any urgent release). And if the issue is about crossing the said time then take the help of others to get it resolved. By following this way, we can learn a lot and in future if same issue appears it can be tracked easily and hence can be resolved quickly. What's your views on this, please suggest. Thanks
My Reading-o-Meter
Previous -> Read "CLR via C#" by Jeffrey Richter. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
I completely agree. Understanding the problem is required before asking a teammate, and learning the code by trying to solve the problem on your own pays benefits to the team down the road, so some effort should go into both before bothering someone else. Even if you can figure out the solution, sometimes it's a good idea to ask a teammate as well, just in case there's something you didn't think of or consider. The one-hour time limit someone else suggested seems far too short, but every code base, problem, and developer is different.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
I completely agree. Understanding the problem is required before asking a teammate, and learning the code by trying to solve the problem on your own pays benefits to the team down the road, so some effort should go into both before bothering someone else. Even if you can figure out the solution, sometimes it's a good idea to ask a teammate as well, just in case there's something you didn't think of or consider. The one-hour time limit someone else suggested seems far too short, but every code base, problem, and developer is different.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
patbob wrote:
The one-hour time limit someone else suggested seems far too short, but every code base, problem, and developer is different.
Well, I didn't come up with that rule, but it seemed to work well. It wasn't as if all problems could be solved in an hour, but if you spent an hour on it without even getting an idea of what to do, it was time to ask for help.
-
I usually say to my Team mates that when they get any complex issue, don't just rush to get it done soon by taking help from other mate(s) the same time. Instead try resolving it by themselve first by understanding the cause of issue and doing other analysis; set some cut off time for resolving it according to the need (if there is any urgent release). And if the issue is about crossing the said time then take the help of others to get it resolved. By following this way, we can learn a lot and in future if same issue appears it can be tracked easily and hence can be resolved quickly. What's your views on this, please suggest. Thanks
My Reading-o-Meter
Previous -> Read "CLR via C#" by Jeffrey Richter. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
Mohammed Hameed wrote:
don't just rush to get it done soon by taking help from other mate(s) the same time
I see many of these people in StackOverflow... ;P
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
I don't work on a team anymore, but back when I did we had a one hour rule: if you couldn't figure it out in an hour, ask for help. This applied to problem-solving, not so much coding practices or requirements, for instance trying to get the right results from a complex SQL query or debugging a difficult issue. The idea is that you don't want someone spinning their wheels and wasting time on a problem that could be solved much faster with some help from a more experienced programmer, but you also don't want someone asking for help with every little thing, which will annoy everyone, and the person asking for help will never learn to do it on his/her own. It was really a mentoring rule for how the senior programmers helped the junior ones. I used to work with a junior programmer who literally asked for help with everything, from the beginning he had no confidence and wouldn't produce any code without having his hand held; he had negative productivity, never really learned to program, and had to find another job. Another new hire sat quietly in a corner and failed, too embarrassed to ask for help or even take it when it was offered. Either extreme is a death trap for a junior programmer.
:thumbsup::thumbsup:
My Reading-o-Meter
Previous -> Read "CLR via C#" by Jeffrey Richter. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
-
I completely agree. Understanding the problem is required before asking a teammate, and learning the code by trying to solve the problem on your own pays benefits to the team down the road, so some effort should go into both before bothering someone else. Even if you can figure out the solution, sometimes it's a good idea to ask a teammate as well, just in case there's something you didn't think of or consider. The one-hour time limit someone else suggested seems far too short, but every code base, problem, and developer is different.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
Perfect.
My Reading-o-Meter
Previous -> Read "CLR via C#" by Jeffrey Richter. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
-
Mohammed Hameed wrote:
don't just rush to get it done soon by taking help from other mate(s) the same time
I see many of these people in StackOverflow... ;P
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
Yes, I do agree.
My Reading-o-Meter
Previous -> Read "CLR via C#" by Jeffrey Richter. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.