Let's imagine a hypothetical scenario where a group with whom you have a dependency on assigns a bug to you, telling you it is not their problem. And, let's also say that you had little familiarity with this code. Would you:
A) Spend an hour to generally understand the code, and then try to debug what was wrong?
B) Spend an hour to generally understand the code, and then find someone to explain the specific problem to you?
C) Find someone to explain the specific problem to you, then spend an hour to generally understand the code?
D) Twiddle your thumbs until someone with a more vested interest in this problem takes it over from you.
I think the answer is, it depends. All too many of us go with Option A, simply accepting ownership of the problem. Sure, you will learn the most by debugging everything yourself, but it will take the longest amount of time. Often times, you don't care about learning about this code and just want to hack through to find a reasonable fix. This approach would only be appropriate if you want to own this code long term, and the debugging time is essentially a time investment.
Researching the issue first will allow you to absorb the most when you finally do talk to the expert, since you will actually understand what he's talking about. But talking to the expert first will save you ramp-up time, and has the additional benefit that they may realize they can fix it in less time it takes to explain it to you, and just fix it themselves. I feel it works best for cross-group collaboration to do your own due diligence first, except in cases where time is critical.
Finally, there are times when even thumb twiddling might be appropriate. Sometimes, the bug is sufficiently complex that you need the issues surrounding it to bake before you can tackle your own problem. Sometimes, time is the only way for the other group to see the light. Sometimes, time will cause the genuine priority of the bug to emerge, when it is weighed against other issues for possible postponement, and stakeholders protest. I find the right things usually happen when they are being addressed by the people who care about it the most.
A) Spend an hour to generally understand the code, and then try to debug what was wrong?
B) Spend an hour to generally understand the code, and then find someone to explain the specific problem to you?
C) Find someone to explain the specific problem to you, then spend an hour to generally understand the code?
D) Twiddle your thumbs until someone with a more vested interest in this problem takes it over from you.
I think the answer is, it depends. All too many of us go with Option A, simply accepting ownership of the problem. Sure, you will learn the most by debugging everything yourself, but it will take the longest amount of time. Often times, you don't care about learning about this code and just want to hack through to find a reasonable fix. This approach would only be appropriate if you want to own this code long term, and the debugging time is essentially a time investment.
Researching the issue first will allow you to absorb the most when you finally do talk to the expert, since you will actually understand what he's talking about. But talking to the expert first will save you ramp-up time, and has the additional benefit that they may realize they can fix it in less time it takes to explain it to you, and just fix it themselves. I feel it works best for cross-group collaboration to do your own due diligence first, except in cases where time is critical.
Finally, there are times when even thumb twiddling might be appropriate. Sometimes, the bug is sufficiently complex that you need the issues surrounding it to bake before you can tackle your own problem. Sometimes, time is the only way for the other group to see the light. Sometimes, time will cause the genuine priority of the bug to emerge, when it is weighed against other issues for possible postponement, and stakeholders protest. I find the right things usually happen when they are being addressed by the people who care about it the most.
2 comments:
Là 1 siêu thị Uy Tín – Đáng tin cẩn. Có giỏi trong lĩnh vực tiêu pha. Chúng tôi luôn đặt “Lời ích khách hàng khi vay tiền lên hàng đầu”. Sau khoáng đãng năm phát triễn nghiên cứu vãn. xem xét được sự bất tiện và thủ tục rượm rà khi vay tiền hiện thời. Buộc phải chúng tôi đưa ra biện pháp mới thích hợp có khuynh hướng mới Vay tiền mặt – sở hữu tiền nhanh trong ngày.
một. Thủ tục vay đơn thuần nhất hiện thời
Chỉ nên giấy tờ ko buộc phải giám định rậm rì. Bằng tài xế hoặc Hộ khẩu đã vay được tiền.
2. Thời gian giải ngân tiền mặt nhanh nhất hiện thời
Cam kết phê duyệt đại dương sơ trong 15 – 30 phút. Giải ngân tiền bề mặt sau 30 phút – đến 2h giả dụ khiến giấy tờ trước 21H Tối. Chúng tôi cam kết giải quyết trong ngày. Ko để tồn sang hôm sau.
3. Vay toền trực tuyến miễn sao bạn mang mạng internet
hầu hết lúc phần lớn nơi. Coi xét website. Chúng tôi sẽ với chuyên viên tham vấn nhiều năm hoảng hốt nghiệm cung cấp game thủ. game thủ không cần phải đi xa hy vọng. Chỉ nhu cầu nhấc máy và gọi. Sẽ vay được tiền.
4. Chẳng hề tài sản đảm bảo, chẳng phải chứng minh thu nhập
Chỉ bắt buộc thủ tục mộc mạc như trên. Chúng tôi không cần ai bảo lãnh khoản vay cho game thủ. cầm buộc rất an toàn không làm cho phiền người nhà bạn.
vay tien nhanh, vay tiền nhanh, vay tiền online, vay tien online, vay tien, vay tiền, vay tien, vay tín chấp, vay tin chap, vay tiền nhanh nhất, vay tien nhanh online, vay tiền nhanh online, vay tiền online nhanh, vvay tien online nhanh,
vay tien nhanh nhat,
"Welcome to MedbookNEW. We are proud of spreading free medical books for more than 500.000 medical students and doctors all over the world.
medical book pdf
medical book free pdf
free download medical
medical book pdf
free medical book pdf"
Post a Comment