Re:Dad and The Ten Commandments of Egoless Programming (2012)
by EdwardDiego on Saturday March 14, 2015 @07:19PM
(#9204622)
> 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.)
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