4 ms·

So you say to me rule 2 for effective collaboration is answering those 5 questions : Why is this change necessary? What assumptions is it based on? Were any al

by C4stor 9y ago

So you say to me rule 2 for effective collaboration is answering those 5 questions : Why is this change necessary? What assumptions is it based on? Were any alternative solutions considered? Why was this solution chosen from among the alternatives? Are there any non-obvious implications that this change has? But none of the proposed rules actually answer those 5 questions in their explanation.

ozim 9y ago
Also then you get people writing their life time stories in commit messages instead of writing code, good luck with velocity.
- deiwin 9y ago
  Thinking that providing additional context for commits is a waste of time is short-sighted. Yes, it requires more time and effort in the short-term (i.e. for creating the commit), but if it's a complex, long-lived project, then that extra effort will save a lot of time in the long run. Sometimes the extra time and effort is already made up for in the review process, which without proper context could drag out and cause a lot of back and forth. Sometimes it might save somebody hours and days of investigation time. This is not to mention the benefits that both the author and the readers of the commit get by better understanding both the problem and the solution.
  - ozim 9y ago
    People are bad at finding out what is important and what is not. Most of the time I have to cut through not relevant stuff that others thought would be important for fixing some issue. Lot more than some insightful commit saved my day, but maybe that is just my environment. Anyway good luck fixing anything trusting commit messages from long time ago. Code is truth and if you won't investigate you still don't know how it works.
- mabbo 9y ago
  Writing more code that no one understands the reason for is not better than writing explanations of why you wrote some code.
  - programmarchy 9y ago
    Then why not focus on writing readable code? And when you do need to write a workaround or something hard to understand, then document it in the code itself with a comment. It'll be recorded in the diff of the commit, plus it'll be more accessible when reading the codebase as a whole.
    - mabbo 9y ago
      These aren't mutually exclusive things. Write readable code so people can see how you did it. Write complete commit messages so that people understand why you did it. Especially with older codebase, hairier things you inherit that are full of monsters and WTFs, you need both. It's more work for you, but it saves the rest of the team even more time. It helps the dev reading it in three years understand, when he git blames to figure out why you did this strange thing.
hinkley 9y ago
Three to four of these should be captured in your ticketing system. Only why should go in the commit, along with the story number. If you have never used tools that can automatically link commit messages to stories you are truly missing out.

by C4stor 9y ago

ozim 9y ago

Also then you get people writing their life time stories in commit messages instead of writing code, good luck with velocity.

deiwin 9y ago
Thinking that providing additional context for commits is a waste of time is short-sighted. Yes, it requires more time and effort in the short-term (i.e. for creating the commit), but if it's a complex, long-lived project, then that extra effort will save a lot of time in the long run. Sometimes the extra time and effort is already made up for in the review process, which without proper context could drag out and cause a lot of back and forth. Sometimes it might save somebody hours and days of investigation time. This is not to mention the benefits that both the author and the readers of the commit get by better understanding both the problem and the solution.
- ozim 9y ago
  People are bad at finding out what is important and what is not. Most of the time I have to cut through not relevant stuff that others thought would be important for fixing some issue. Lot more than some insightful commit saved my day, but maybe that is just my environment. Anyway good luck fixing anything trusting commit messages from long time ago. Code is truth and if you won't investigate you still don't know how it works.
mabbo 9y ago
Writing more code that no one understands the reason for is not better than writing explanations of why you wrote some code.
- programmarchy 9y ago
  Then why not focus on writing readable code? And when you do need to write a workaround or something hard to understand, then document it in the code itself with a comment. It'll be recorded in the diff of the commit, plus it'll be more accessible when reading the codebase as a whole.
  - mabbo 9y ago
    These aren't mutually exclusive things. Write readable code so people can see how you did it. Write complete commit messages so that people understand why you did it. Especially with older codebase, hairier things you inherit that are full of monsters and WTFs, you need both. It's more work for you, but it saves the rest of the team even more time. It helps the dev reading it in three years understand, when he git blames to figure out why you did this strange thing.

hinkley 9y ago

Three to four of these should be captured in your ticketing system. Only why should go in the commit, along with the story number. If you have never used tools that can automatically link commit messages to stories you are truly missing out.