Thursday, December 20, 2018

A World Of Tradeoffs

I've always maintained that, for a sufficiently large code base and especially if working with multiple coders, in order to judge whether or not an engineer was any good, you couldn't just look at the product and the the code. Instead you would need to understand the tradeoffs that the engineer made. Can you tell by just looking at the code? Sometimes, but not always.

 Every large code base is a giant mix of tradeoffs at different levels. There are a lot of decisions made in meeting rooms that might not be 100% explained in the code. Because of relationships and internal politics, sometimes an engineer has to pick and choose their battles. They might let go of a technical decision here to win a more important one on another front. Maybe they feel one technology is better but went with another technology because the other engineers on the team were more familiar with it. Maybe their boss is stubborn and they are optimizing to keep their job and get higher bonuses rather than making the engineering top notch. The most common tradeoff is time. It could be better if there was more time to make it so, but under a lot of time constraint, the engineer chooses the best solution that will make it within the deadline set. The list is endless, its not always about having the perfect 1's and 0's in a vacuum.

Now if it is this hard to judge whether an engineer is good or not based on the result. Imagine trying to judge an actual politician...