3 ms·

Seems a pretty naïve description of Engineering types. Not only is there no data to back this up, but it makes it seem like hard divisions: I can anecdotally te

Seems a pretty naïve description of Engineering types. Not only is there no data to back this up, but it makes it seem like hard divisions: I can anecdotally tell you about junior engineers who over-engineer in the wrong areas, or experienced engineers who `under-engineer` due to time|pressure|issue-critical requirements. Nonsense.

okhudeira 10y ago
Author here. Your point is valid. I do try to make this clear in this portion: > However, an over-engineer can sometimes perform like an under-engineer or an engineer. Underperformance and overperformance could be influenced by a number of factors including work environment, context, intellectual horsepower, and even personal life. I personally continue to write under-engineered and over-engineered code because there are so many internal and external factors that go into solving a problem.
- badloginagain 10y ago
  I encourage you to keep writing, but it seems you need more research into developer patterns if you want to contribute to an already highly discussed topic. For instance, last month this article[1] gave some seriously good insights to developer checkin frequency based on hard data. It provides a lot more value than the anecdotal, muddy definitions of over/under/engineer. [1] - https://blog.gitprime.com/check-in-frequency-and-codebase-impact-the-surprising-correlation/ https://blog.gitprime.com/check-in-frequency-and-codebase-im...
  - Ace17 10y ago
    What is "impact"?
  - okhudeira 10y ago
    I appreciate the feedback. That's a very interesting article. However, it does seem suffer from the same issues Joel outlined, namely, the measure of attributes of a commit can be gamed and worked towards to achieve a "prolific" or "senior" status. What the article you linked does reinforce is the value of iterative development. As opposed to doing large infrequent commits, doing small bits of work more frequently causes a success higher or "impact". I would say that the article provides a data driven approach to justifying the effectiveness of good iterative planning. However, it doesn't address whether the commits of the "senior" engineer or the "prolific" engineer are of high quality.
  - random_rr 10y ago
    The linked article actually has very little in the way of substance.

okhudeira 10y ago

Author here. Your point is valid. I do try to make this clear in this portion: > However, an over-engineer can sometimes perform like an under-engineer or an engineer. Underperformance and overperformance could be influenced by a number of factors including work environment, context, intellectual horsepower, and even personal life. I personally continue to write under-engineered and over-engineered code because there are so many internal and external factors that go into solving a problem.

badloginagain 10y ago
I encourage you to keep writing, but it seems you need more research into developer patterns if you want to contribute to an already highly discussed topic. For instance, last month this article[1] gave some seriously good insights to developer checkin frequency based on hard data. It provides a lot more value than the anecdotal, muddy definitions of over/under/engineer. [1] - https://blog.gitprime.com/check-in-frequency-and-codebase-impact-the-surprising-correlation/ https://blog.gitprime.com/check-in-frequency-and-codebase-im...
- Ace17 10y ago
  What is "impact"?
- okhudeira 10y ago
  I appreciate the feedback. That's a very interesting article. However, it does seem suffer from the same issues Joel outlined, namely, the measure of attributes of a commit can be gamed and worked towards to achieve a "prolific" or "senior" status. What the article you linked does reinforce is the value of iterative development. As opposed to doing large infrequent commits, doing small bits of work more frequently causes a success higher or "impact". I would say that the article provides a data driven approach to justifying the effectiveness of good iterative planning. However, it doesn't address whether the commits of the "senior" engineer or the "prolific" engineer are of high quality.
- random_rr 10y ago
  The linked article actually has very little in the way of substance.