4 ms·

The #1 trait is they will dig until they fully understand the problem. When writing code if the first draft Is not good they will rearchitect until it makes coh

The #1 trait is they will dig until they fully understand the problem. When writing code if the first draft Is not good they will rearchitect until it makes cohesive sense. Time spent getting it right the first time saves significantly more time than dealing with the fallout of not doing the right thing.

jasonpeacock 7y ago
So many people stop when it works, without understanding why it works. Or not caring how ugly it is. They have no long-term perspective about the future cost of support - fixing bugs, adding features, or just understanding what was done. When something changes and their snowflake solution breaks, their first reaction is to blame the external change for causing their poor solution to fail. Top engineers don't do this. They understand why their solution works, they know its limitations, and their solutions are understandable and supportable. This significantly lowers the total cost over time and is what helps projects deliver on time with quality.
- ScottFree 7y ago
  > So many people stop when it works, without understanding why it works. Most work environments train programmers to act that way. I find this is especially the case at workplaces that (sort of) follow scrum and agile. In most of these places, junior to mid-level programmers are given a task to work on that already has an hours estimate on it. Managers like to optimize efficiency and programmer time, so that estimate is always tight. Asking why we're doing this task is rarely received well and the tight time estimate means there's barely time to make the change work in the first place, let alone understand why it works. We're literally training our devs not to be top devs.
  - aledalgrande 7y ago
    The reverse side of the coin is an engineer who has complete leeway on what they do and they spend time "redecorating" their code ad nauseam. I think there is a golden mean to be found.

jasonpeacock 7y ago

So many people stop when it works, without understanding why it works. Or not caring how ugly it is. They have no long-term perspective about the future cost of support - fixing bugs, adding features, or just understanding what was done. When something changes and their snowflake solution breaks, their first reaction is to blame the external change for causing their poor solution to fail. Top engineers don't do this. They understand why their solution works, they know its limitations, and their solutions are understandable and supportable. This significantly lowers the total cost over time and is what helps projects deliver on time with quality.

ScottFree 7y ago
> So many people stop when it works, without understanding why it works. Most work environments train programmers to act that way. I find this is especially the case at workplaces that (sort of) follow scrum and agile. In most of these places, junior to mid-level programmers are given a task to work on that already has an hours estimate on it. Managers like to optimize efficiency and programmer time, so that estimate is always tight. Asking why we're doing this task is rarely received well and the tight time estimate means there's barely time to make the change work in the first place, let alone understand why it works. We're literally training our devs not to be top devs.
- aledalgrande 7y ago
  The reverse side of the coin is an engineer who has complete leeway on what they do and they spend time "redecorating" their code ad nauseam. I think there is a golden mean to be found.