|
|
|
|
|
by pbh101
2609 days ago
|
|
Inspect your own feelings of why you feel your approach/solution is better. If you haven’t done it before, this can be a lot of work. Get to the point where you can convey the underlying reasons for them: why is it important to you? What’s going to be worse or slower with their solution? What future problems is your solution avoiding? How can they identify similar situations and apply the same concept next time? It is good that you see these things instinctually as you say but if others don’t (including the coder in question) then you can make improvements by conveying this to them. And that is frequently more than half the battle in getting improvements operationalized: getting others to adopt and push and spread your good ideas as their own. In a healthy org, these developers should be open and eager to listen, learn from new ideas, and adopt improved methods or outlooks, especially from a tech lead (or equivalent), who in turn should be able to update his/her own methods/outlooks when similarly presented with improvements. |
|