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.
-
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.
Exactly the opposite to be honest. As soon as you come up against anything non-trivial you should always ask the team if there is something in the company codebase that already fulfils the requirement. There is no point in duplicating code everywhere, be it from a business perspective or from the POV of the developers in terms of maintainability, reusability, documentation and value of the team to the business aspect of the company. Sharing within the team fosters a proper team mentality and ensures that everyone has a stake in the foundation of the software you produce. If you give people purpose like that they will work far better than if they're just another number punching in and out on a daily basis. Involving people can go as far as reducing your staff turnover. You should also understand the issue before you write a line of code. Not doing so is route #1 to cowboy coding. Use higher level diagrams and UML to model complex interactions and highly abstract structures based on your requirements. Your requirements dictate what needs doing, your design dictates how it will be implemented. Not taking this step first is equivalent to building a house by just laying down a course of bricks anywhere and hoping for the best. A clean design also becomes your de facto documentation and in turn a proper knowledge transfer within the team becomes possible. I've worked at too many places where there has been no design up front, tens of developers have all had a go on an application each with their own undocumented ideas and it becomes one almighty mess trying to sort anything major out. The efficiency of the business suffers as a result and you can kiss your raise goodbye.
-
Exactly the opposite to be honest. As soon as you come up against anything non-trivial you should always ask the team if there is something in the company codebase that already fulfils the requirement. There is no point in duplicating code everywhere, be it from a business perspective or from the POV of the developers in terms of maintainability, reusability, documentation and value of the team to the business aspect of the company. Sharing within the team fosters a proper team mentality and ensures that everyone has a stake in the foundation of the software you produce. If you give people purpose like that they will work far better than if they're just another number punching in and out on a daily basis. Involving people can go as far as reducing your staff turnover. You should also understand the issue before you write a line of code. Not doing so is route #1 to cowboy coding. Use higher level diagrams and UML to model complex interactions and highly abstract structures based on your requirements. Your requirements dictate what needs doing, your design dictates how it will be implemented. Not taking this step first is equivalent to building a house by just laying down a course of bricks anywhere and hoping for the best. A clean design also becomes your de facto documentation and in turn a proper knowledge transfer within the team becomes possible. I've worked at too many places where there has been no design up front, tens of developers have all had a go on an application each with their own undocumented ideas and it becomes one almighty mess trying to sort anything major out. The efficiency of the business suffers as a result and you can kiss your raise goodbye.
Thanks Jim. It is a very nice indepth explanation. :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.
-
Exactly the opposite to be honest. As soon as you come up against anything non-trivial you should always ask the team if there is something in the company codebase that already fulfils the requirement. There is no point in duplicating code everywhere, be it from a business perspective or from the POV of the developers in terms of maintainability, reusability, documentation and value of the team to the business aspect of the company. Sharing within the team fosters a proper team mentality and ensures that everyone has a stake in the foundation of the software you produce. If you give people purpose like that they will work far better than if they're just another number punching in and out on a daily basis. Involving people can go as far as reducing your staff turnover. You should also understand the issue before you write a line of code. Not doing so is route #1 to cowboy coding. Use higher level diagrams and UML to model complex interactions and highly abstract structures based on your requirements. Your requirements dictate what needs doing, your design dictates how it will be implemented. Not taking this step first is equivalent to building a house by just laying down a course of bricks anywhere and hoping for the best. A clean design also becomes your de facto documentation and in turn a proper knowledge transfer within the team becomes possible. I've worked at too many places where there has been no design up front, tens of developers have all had a go on an application each with their own undocumented ideas and it becomes one almighty mess trying to sort anything major out. The efficiency of the business suffers as a result and you can kiss your raise goodbye.
Aggree to this. We have some common libraries, even some common templates for Webapps, come all with the same standard, .CSS, etc. We also have webservices operations like Active Directory Queries, User Settings (Name, Firstname, Department, Department changes, absences, ecc). So the core system is already done, and you only have to focus on the business model.
The signature is in building process.. Please wait...
-
Aggree to this. We have some common libraries, even some common templates for Webapps, come all with the same standard, .CSS, etc. We also have webservices operations like Active Directory Queries, User Settings (Name, Firstname, Department, Department changes, absences, ecc). So the core system is already done, and you only have to focus on the business model.
The signature is in building process.. Please wait...
Quote:
the core system is already done, and you only have to focus on the business model.
I like this point :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 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.
The issue is far more complex than it seems. You don't want your developers to be stuck on an issue too long, but you don't want them to start bugging each other for each little thing. it is more often a gray area than just black & white and it depends highly on the atmosphere, skillset and way-of-working of your team and that of the customer (which could be internal). We had a sort of tutorial ready for newcomers that explained what we had and how we used it. In addition we kept our own wiki as knowledge base for our product's specific problems (including coding issues, SQL stuff, ... ) On top of that we had regular code reviews and we encouraged talking to each other when complex situations arose. You'll need to find out the pace of your team yourself, but make sure that any working-protocol you want to implement is discussed with your team beforehand. hope this helps.
-
The issue is far more complex than it seems. You don't want your developers to be stuck on an issue too long, but you don't want them to start bugging each other for each little thing. it is more often a gray area than just black & white and it depends highly on the atmosphere, skillset and way-of-working of your team and that of the customer (which could be internal). We had a sort of tutorial ready for newcomers that explained what we had and how we used it. In addition we kept our own wiki as knowledge base for our product's specific problems (including coding issues, SQL stuff, ... ) On top of that we had regular code reviews and we encouraged talking to each other when complex situations arose. You'll need to find out the pace of your team yourself, but make sure that any working-protocol you want to implement is discussed with your team beforehand. hope this helps.
Thank you, thanks a lot...Awesome.
Quote:
hope this helps.
Yes, it helped a lot :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 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.
If you ask someone how to do something, and he knows how to do it, you learn immediately, and a new set of stuff opens up for you to read up on. If you don't know how to do something, and you struggle to do it, you will probably learn to do it well -- but probably not immediately, and trying to find available ways of doing things is rarely trivial, so the chances are that you'll end up reading up on all the wrong stuff, and possibly arriving at a less than optimal solution. Developers who don't know how to shout out "Hey, does anyone know how to...?" should learn.
I wanna be a eunuchs developer! Pass me a bread knife!
-
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.