4 ms·

I follow this advice because I've found from experience that often there is a good reason, or at least _a_ reason, that I don't see. Maybe the loop does someho

I follow this advice because I've found from experience that often there is a good reason, or at least _a_ reason, that I don't see. Maybe the loop does somehow terminate, through an obscure mechanism. Or maybe it's not supposed to terminate. Or maybe I missed something obvious. I make mistakes all the time. I probably make mistakes more often than I do things right. Therefore, asking questions rather than making bold claims is usually betting the right way. This doesn't mean you have to be a pushover. If you don't see something, you can say, "I'm sorry if I'm being a little slow here, but I still don't understand. Can you explain how XYZ works in more detail?" Most people are very happy to help you understand.

EdwardDiego 12y ago
> I follow this advice because I've found from experience that often there is a good reason, or at least _a_ reason, that I don't see. Exactly. I pulled in devs from two teams recently to discuss confusing modelling of domain objects on one end of our app vs. the other end, as my team were trying to deal with both. The naming involved was completely contradictory, which always makes fitting a system into your head so much harder when you have to mentally translate. Turns out that each team had very valid reasons for modelling the entities as they did - the front-end team implemented the entities as understood by the business guys who would be using the GUI to configure them, and the other implemented the entities as understood by the API spec they were ultimately being transmitted over. The initial response of "this is so dumb" was very easy and very wrong. Much of my personal development as a dev has been learning to suppress that initial dismissive response when encountering 'bad' code, instead asking why the code is as it is. There's always a bit of a fundamental attribution error[1] in "your code is awful" discussions with devs. (Although I'd say that this points to the issues that can arise from having two teams implement two separate parts of a business process.) [1]: http://en.wikipedia.org/wiki/Fundamental_attribution_error http://en.wikipedia.org/wiki/Fundamental_attribution_error

EdwardDiego 12y ago

> I follow this advice because I've found from experience that often there is a good reason, or at least _a_ reason, that I don't see. Exactly. I pulled in devs from two teams recently to discuss confusing modelling of domain objects on one end of our app vs. the other end, as my team were trying to deal with both. The naming involved was completely contradictory, which always makes fitting a system into your head so much harder when you have to mentally translate. Turns out that each team had very valid reasons for modelling the entities as they did - the front-end team implemented the entities as understood by the business guys who would be using the GUI to configure them, and the other implemented the entities as understood by the API spec they were ultimately being transmitted over. The initial response of "this is so dumb" was very easy and very wrong. Much of my personal development as a dev has been learning to suppress that initial dismissive response when encountering 'bad' code, instead asking why the code is as it is. There's always a bit of a fundamental attribution error[1] in "your code is awful" discussions with devs. (Although I'd say that this points to the issues that can arise from having two teams implement two separate parts of a business process.) [1]: http://en.wikipedia.org/wiki/Fundamental_attribution_error http://en.wikipedia.org/wiki/Fundamental_attribution_error