Know Your Next Commit - Revision history

Danbj at 08:50, 19 July 2009

Danbj — Sun, 19 Jul 2009 08:50:50 GMT

←Older revision		Revision as of 08:50, 19 July 2009
Line 3:		Line 3:
	It might seem that the first two were engrossed in the details of their work while only the third could see the bigger picture, and that the latter had the better focus. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services in some way."		It might seem that the first two were engrossed in the details of their work while only the third could see the bigger picture, and that the latter had the better focus. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services in some way."

-	The first two did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and could be finished within a couple of hours. Once they had finished those tasks, they would select a new feature or refactoring to work on. All the code written was done so with a clear purpose and a limited, achievable goal in mind.	+	The first two did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and could be finished within a couple of hours. Once they had finished those tasks, they would select a new feature or refactoring to work on. All the code written was thus done with a clear purpose and a limited, achievable goal in mind.

	The third programmer had not been able to decompose the problem and was working on all aspects at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written at the start of this long session was poorly matched for the solution that came out in the end.		The third programmer had not been able to decompose the problem and was working on all aspects at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written at the start of this long session was poorly matched for the solution that came out in the end.

Kevlin at 15:45, 7 July 2009

Kevlin — Tue, 07 Jul 2009 15:45:56 GMT

←Older revision		Revision as of 15:45, 7 July 2009
Line 1:		Line 1:
-	I tapped three programmers on their shoulders and asked what they where doing. "I am refactoring these methods" the first answered. "I am adding some parameters to this web action" the second answered. The third answered, "I am working on this user story."	+	I tapped three programmers on their shoulders and asked what they where doing. "I am refactoring these methods," the first answered. "I am adding some parameters to this web action," the second answered. The third answered, "I am working on this user story."

	It might seem that the first two were engrossed in the details of their work while only the third could see the bigger picture, and that the latter had the better focus. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services in some way."		It might seem that the first two were engrossed in the details of their work while only the third could see the bigger picture, and that the latter had the better focus. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services in some way."

-	The first two did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and could be finished within a couple of hours. Once they had finished those tasks, they would select a new feature ~~to add~~ or refactoring to ~~make~~. ~~In that way all~~ the code ~~they wrote~~ was ~~written~~ with a clear purpose and a limited, achievable goal in mind.	+	The first two did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and could be finished within a couple of hours. Once they had finished those tasks, they would select a new feature or refactoring to work on. All the code written was done so with a clear purpose and a limited, achievable goal in mind.

	The third programmer had not been able to decompose the problem and was working on all aspects at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written at the start of this long session was poorly matched for the solution that came out in the end.		The third programmer had not been able to decompose the problem and was working on all aspects at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written at the start of this long session was poorly matched for the solution that came out in the end.

-	What would the first two programmers do if their tasks took more than two hours? After ~~realising~~ they had taken on too much, they would most likely throw away their changes, define smaller tasks, and start over. To keep working would have lacked focus and led to speculative code entering the repository. Instead, changes would be thrown away, but the insights kept.	+	What would the first two programmers do if their tasks took more than two hours? After realizing they had taken on too much, they would most likely throw away their changes, define smaller tasks, and start over. To keep working would have lacked focus and led to speculative code entering the repository. Instead, changes would be thrown away, but the insights kept.

-	The third programmer might keep on guessing and desperately try to patch together his changes into something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, ~~that causes~~ strange code ~~changes without~~ a clear purpose to enter the repository.	+	The third programmer might keep on guessing and desperately try to patch together his changes into something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, not throwing the code away leads to slightly strange code, lacking a clear purpose, to enter the repository.

-	At some point ~~of time~~ even the commit-hard-ass programmers ~~could not~~ find something they thought could be finished in two hours ~~and would lead in a productive direction~~. Then, they would go directly into speculative mode, ~~play~~ around with the code, ~~and~~ of course ~~throw~~ away the changes whenever some insight ~~had lead~~ them back on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step.	+	At some point even the commit-hard-ass programmers might fail to find something useful they thought could be finished in two hours. Then, they would go directly into speculative mode, playing around with the code and, of course, throwing away the changes whenever some insight led them back on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step.

-	Know your next commit. If you cannot finish, throw away your changes, define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. Do not commit guesswork into your repository.	+	Know your next commit. If you cannot finish, throw away your changes, then define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. Do not commit guesswork into your repository.

	By [[Dan Bergh Johnsson]]		By [[Dan Bergh Johnsson]]

Danbj at 22:49, 31 January 2009

Danbj — Sat, 31 Jan 2009 22:49:56 GMT

←Older revision		Revision as of 22:49, 31 January 2009
Line 7:		Line 7:
	The third programmer had not been able to decompose the problem and was working on all aspects at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written at the start of this long session was poorly matched for the solution that came out in the end.		The third programmer had not been able to decompose the problem and was working on all aspects at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written at the start of this long session was poorly matched for the solution that came out in the end.

-	What would the first two programmers do if their tasks took more than two hours? After realising they had taken on too much, they would most likely throw away their changes, define smaller tasks, and start over. To keep working would have lacked focus and led to speculative code entering the repository. ~~The~~ changes would be thrown away, but the insights kept.	+	What would the first two programmers do if their tasks took more than two hours? After realising they had taken on too much, they would most likely throw away their changes, define smaller tasks, and start over. To keep working would have lacked focus and led to speculative code entering the repository. Instead, changes would be thrown away, but the insights kept.

	The third programmer might keep on guessing and desperately try to patch together his changes into something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, that causes strange code changes without a clear purpose to enter the repository.		The third programmer might keep on guessing and desperately try to patch together his changes into something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, that causes strange code changes without a clear purpose to enter the repository.

Kevlin at 18:53, 31 January 2009

Kevlin — Sat, 31 Jan 2009 18:53:09 GMT

←Older revision		Revision as of 18:53, 31 January 2009
Line 1:		Line 1:
	I tapped three programmers on their shoulders and asked what they where doing. "I am refactoring these methods" the first answered. "I am adding some parameters to this web action" the second answered. The third answered, "I am working on this user story."		I tapped three programmers on their shoulders and asked what they where doing. "I am refactoring these methods" the first answered. "I am adding some parameters to this web action" the second answered. The third answered, "I am working on this user story."

-	It might seem that the first two were ~~focused on~~ the details of their work while the third ~~focused on~~ the bigger picture, and that the latter ~~should be~~ better. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services some way."	+	It might seem that the first two were engrossed in the details of their work while only the third could see the bigger picture, and that the latter had the better focus. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services in some way."

-	The first two did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and could be finished within a couple of hours. Once they had finished those tasks, they would select a new ~~change~~ or refactoring. In that way all the code they wrote was written with a clear purpose and a limited, achievable goal in mind.	+	The first two did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and could be finished within a couple of hours. Once they had finished those tasks, they would select a new feature to add or refactoring to make. In that way all the code they wrote was written with a clear purpose and a limited, achievable goal in mind.

-	The third programmer had not been able to ~~break down~~ the problem and was working on all at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written in the start of this long session was poorly ~~directed~~ for the solution that came out in the end.	+	The third programmer had not been able to decompose the problem and was working on all aspects at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written at the start of this long session was poorly matched for the solution that came out in the end.

-	What would the two programmers do if it took more than two hours? ~~They would simply realise that~~ they had taken on too much, throw away their changes, define a smaller ~~task~~, and start over. To keep working would have ~~been speculative,~~ and ~~you do not want~~ speculative code ~~in your~~ repository. ~~So, the~~ changes ~~where~~ thrown away, but the insights kept.	+	What would the first two programmers do if their tasks took more than two hours? After realising they had taken on too much, they would most likely throw away their changes, define smaller tasks, and start over. To keep working would have lacked focus and led to speculative code entering the repository. The changes would be thrown away, but the insights kept.

-	The third programmer might keep on guessing and desperately try to patch together his changes to something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, that causes strange code changes without a clear purpose to enter the repository.	+	The third programmer might keep on guessing and desperately try to patch together his changes into something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, that causes strange code changes without a clear purpose to enter the repository.

-	At some point of time even the commit-hard-ass programmers could not find something they thought could be finished in two hours and would lead in a productive direction. Then, they would go directly into speculative mode, play around with the code, and of course throw away the changes whenever some insight had lead them back on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step.	+	At some point of time even the commit-hard-ass programmers could not find something they thought could be finished in two hours and would lead in a productive direction. Then, they would go directly into speculative mode, play around with the code, and of course throw away the changes whenever some insight had lead them back on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step.

-	Know your next commit. If you cannot finish, throw away your changes, define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. ~~And never let speculative code enter~~ your repository.	+	Know your next commit. If you cannot finish, throw away your changes, define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. Do not commit guesswork into your repository.

	By [[Dan Bergh Johnsson]]		By [[Dan Bergh Johnsson]]

Danbj: condensing

Danbj — Thu, 22 Jan 2009 15:22:54 GMT

condensing

←Older revision		Revision as of 15:22, 22 January 2009
Line 1:		Line 1:
-	I tapped three programmers on their shoulders and asked what they where doing. "I am refactoring these methods," the first answered. "I am adding some parameters to this web action," the second answered. The third answered, "I am working on this user story."	+	I tapped three programmers on their shoulders and asked what they where doing. "I am refactoring these methods" the first answered. "I am adding some parameters to this web action" the second answered. The third answered, "I am working on this user story."

-	It might seem that the first two were focused on the details of their work ~~and that~~ the third focused on the bigger picture, and that the latter should be better. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might ~~have to~~ change those services some way."	+	It might seem that the first two were focused on the details of their work while the third focused on the bigger picture, and that the latter should be better. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services some way."

-	The first two ~~programmers~~ did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and ~~that they thought~~ could ~~finish~~ within a couple of hours. Once they had finished those tasks, they would select a new change or refactoring. In that way all the code they wrote was written with a clear purpose and a limited, achievable goal in mind.	+	The first two did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and could be finished within a couple of hours. Once they had finished those tasks, they would select a new change or refactoring. In that way all the code they wrote was written with a clear purpose and a limited, achievable goal in mind.

-	The third programmer had not been able to break down the problem and was working on all at once. He had no idea of what it would take, ~~and was~~ basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written in the start of this long session was poorly directed for the solution that came out in the end.	+	The third programmer had not been able to break down the problem and was working on all at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written in the start of this long session was poorly directed for the solution that came out in the end.

	What would the two programmers do if it took more than two hours? They would simply realise that they had taken on too much, throw away their changes, define a smaller task, and start over. To keep working would have been speculative, and you do not want speculative code in your repository. So, the changes where thrown away, but the insights kept.		What would the two programmers do if it took more than two hours? They would simply realise that they had taken on too much, throw away their changes, define a smaller task, and start over. To keep working would have been speculative, and you do not want speculative code in your repository. So, the changes where thrown away, but the insights kept.
Line 11:		Line 11:
	The third programmer might keep on guessing and desperately try to patch together his changes to something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, that causes strange code changes without a clear purpose to enter the repository.		The third programmer might keep on guessing and desperately try to patch together his changes to something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, that causes strange code changes without a clear purpose to enter the repository.

-	At some point of time even the commit-hard-ass programmers could not find something they thought could be finished in two hours and would lead in a productive direction. Then, they would go directly into speculative mode, play around with the code, and of course ~~throwing~~ away the changes whenever ~~they had gained~~ some insight ~~leading~~ them on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step.	+	At some point of time even the commit-hard-ass programmers could not find something they thought could be finished in two hours and would lead in a productive direction. Then, they would go directly into speculative mode, play around with the code, and of course throw away the changes whenever some insight had lead them back on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step.

	Know your next commit. If you cannot finish, throw away your changes, define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. And never let speculative code enter your repository.		Know your next commit. If you cannot finish, throw away your changes, define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. And never let speculative code enter your repository.

Danbj: condensing

Danbj — Wed, 21 Jan 2009 19:33:28 GMT

condensing

←Older revision		Revision as of 19:33, 21 January 2009
Line 1:		Line 1:
-	I tapped ~~a programmer~~ on ~~her shoulder~~ and asked what ~~she was~~ doing. "I am refactoring these methods," ~~she~~ answered~~. I tapped a second programmer on his shoulder and asked what he was doing~~. "I am adding some parameters to this web action," he answered. The third answered, "I am working on this user story."	+	I tapped three programmers on their shoulders and asked what they where doing. "I am refactoring these methods," the first answered. "I am adding some parameters to this web action," the second answered. The third answered, "I am working on this user story."

-	It might seem that ~~numbers one and~~ two were focused on the details of their work and that the third ~~was~~ focused on the bigger picture, and that the latter should be better. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might have to change those services some way."	+	It might seem that the first two were focused on the details of their work and that the third focused on the bigger picture, and that the latter should be better. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might have to change those services some way."

-	The first two programmers did not lack ~~consideration~~ of the overall goal ~~of what they where doing~~. ~~But they~~ had selected tasks ~~that~~ they ~~could get to grips with, that~~ led in a productive direction, and that they thought could ~~be finished~~ within a couple of hours. Once they had finished those tasks, they would select a new change or refactoring. In that way all the code they wrote was written with a clear purpose and a limited ~~and~~ achievable goal in mind.	+	The first two programmers did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and that they thought could finish within a couple of hours. Once they had finished those tasks, they would select a new change or refactoring. In that way all the code they wrote was written with a clear purpose and a limited, achievable goal in mind.

-	The third programmer had ~~simply~~ not been able to break down the problem and was working on all ~~of it~~ at ~~one go~~. He had no idea of what it would take, and was basically doing speculative programming, hoping ~~that he would~~ arrive at some point where he would be able to commit. Most probably the code written in the start of this long session was poorly directed for the solution that came out in the end.	+	The third programmer had not been able to break down the problem and was working on all at once. He had no idea of what it would take, and was basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written in the start of this long session was poorly directed for the solution that came out in the end.

-	What would the two programmers do if ~~the task they had selected came out to take~~ more than two hours? They would simply realise that they had taken too ~~big a bite~~, throw away their changes, define a smaller task, and start over. To keep working would have been speculative, and you do not want speculative code in your repository. So, the changes where thrown away, but the insights ~~where~~ kept.	+	What would the two programmers do if it took more than two hours? They would simply realise that they had taken on too much, throw away their changes, define a smaller task, and start over. To keep working would have been speculative, and you do not want speculative code in your repository. So, the changes where thrown away, but the insights kept.

-	~~On the other hand, the~~ third programmer ~~would probably just~~ keep guessing ~~with less and less clue~~ and desperately try to patch together his changes to something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, that causes ~~a lot of~~ strange code changes without a clear purpose to enter the repository.	+	The third programmer might keep on guessing and desperately try to patch together his changes to something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, that causes strange code changes without a clear purpose to enter the repository.

-	At some point of time even the commit-hard-ass programmers could not find something they thought could be finished in two hours and would lead in a productive direction. Then, they would go directly into speculative mode ~~and~~ play around with the code~~: trying some wild refactoring just to see how the code would move~~, ~~or patching on some functionality to see if it would fit in the structure —~~ and of course throwing away the changes whenever they had gained some insight leading them on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step.	+	At some point of time even the commit-hard-ass programmers could not find something they thought could be finished in two hours and would lead in a productive direction. Then, they would go directly into speculative mode, play around with the code, and of course throwing away the changes whenever they had gained some insight leading them on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step.

-	Know your next commit. If you cannot finish, throw away your changes ~~and~~ define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. And never let speculative code enter your repository.	+	Know your next commit. If you cannot finish, throw away your changes, define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. And never let speculative code enter your repository.

	By [[Dan Bergh Johnsson]]		By [[Dan Bergh Johnsson]]

Kevlin at 15:59, 24 November 2008

Kevlin — Mon, 24 Nov 2008 15:59:15 GMT

←Older revision		Revision as of 15:59, 24 November 2008
Line 1:		Line 1:
-	I tapped a programmer on her shoulder and asked what she was doing. “I am refactoring these ~~methods”~~, she answered. I tapped a second programmer on his shoulder and asked what he was doing~~, “I~~ am adding some parameters to this web ~~action”~~, he answered. The third answered~~. “I~~ am working on this user ~~story”~~	+	I tapped a programmer on her shoulder and asked what she was doing. "I am refactoring these methods," she answered. I tapped a second programmer on his shoulder and asked what he was doing. "I am adding some parameters to this web action," he answered. The third answered, "I am working on this user story."

-	It might seem that ~~number~~ one and two ~~where focusing~~ on details of their work and that the ~~second~~ focused on the bigger picture, and that the latter should be better. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and ~~where to~~ be finished within an hour or so. The third programmer answered~~: “Oh~~, I guess I will be ready within a few days; I will probably add a few classes and might have to change those services some way.”	+	It might seem that numbers one and two were focused on the details of their work and that the third was focused on the bigger picture, and that the latter should be better. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might have to change those services some way."

-	The first two programmers did not lack consideration of the ~~over-all~~ goal of what they where doing. But, they had selected ~~a task~~ that they could get ~~a grip on~~, that led in a productive direction, and they thought could be finished within ~~two~~ hours. Once they had finished ~~that task~~, they would select a new change or refactoring. In that way all the code they wrote ~~where~~ written with a clear purpose and a limited and achievable goal in mind.	+	The first two programmers did not lack consideration of the overall goal of what they where doing. But they had selected tasks that they could get to grips with, that led in a productive direction, and that they thought could be finished within a couple of hours. Once they had finished those tasks, they would select a new change or refactoring. In that way all the code they wrote was written with a clear purpose and a limited and achievable goal in mind.

-	The third programmer had simply not been able to break down the problem and ~~where~~ working on all of it at one go. He had no idea of what it would take, and ~~where~~ basically doing speculative programming, hoping that he would arrive at some point where he would be able to commit. Most probably the code written in the start of this long session ~~where~~ poorly directed for the solution that came out in the end.	+	The third programmer had simply not been able to break down the problem and was working on all of it at one go. He had no idea of what it would take, and was basically doing speculative programming, hoping that he would arrive at some point where he would be able to commit. Most probably the code written in the start of this long session was poorly directed for the solution that came out in the end.

	What would the two programmers do if the task they had selected came out to take more than two hours? They would simply realise that they had taken too big a bite, throw away their changes, define a smaller task, and start over. To keep working would have been speculative, and you do not want speculative code in your repository. So, the changes where thrown away, but the insights where kept.		What would the two programmers do if the task they had selected came out to take more than two hours? They would simply realise that they had taken too big a bite, throw away their changes, define a smaller task, and start over. To keep working would have been speculative, and you do not want speculative code in your repository. So, the changes where thrown away, but the insights where kept.

-	On the other hand, the third programmer would probably just keep guessing with less and less clue and desperately try to patch together his changes to something that could be committed. ~~Because~~, you cannot throw away code-changes you have done – that would be ~~a waste of~~ work ~~wouldn’t~~ it? Unfortunately that causes a lot of strange code-changes without a clear purpose to enter the repository.	+	On the other hand, the third programmer would probably just keep guessing with less and less clue and desperately try to patch together his changes to something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, that causes a lot of strange code changes without a clear purpose to enter the repository.

-	At some point of time even the commit-hard-ass programmers could not find something they thought could be finished in two hours and would lead in a productive direction. Then, they would go directly into speculative mode and play around with the code: trying some wild refactoring just to see how the code would move, or patching on some functionality to see if it would fit in the structure – and of course throwing away the changes whenever they had gained some insight leading them on track. ~~Because, of course even~~ these seemingly unstructured hacking sessions ~~had a~~ purpose: to learn about the code to be able to define a task that would constitute a productive step.	+	At some point of time even the commit-hard-ass programmers could not find something they thought could be finished in two hours and would lead in a productive direction. Then, they would go directly into speculative mode and play around with the code: trying some wild refactoring just to see how the code would move, or patching on some functionality to see if it would fit in the structure — and of course throwing away the changes whenever they had gained some insight leading them on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step.

-	Know your next commit. If you cannot finish, throw away your changes, and define a new task you believe in with the insights you have gained. Do speculative ~~experiment~~ whenever needed, but do not let yourself slip into speculative mode without noticing. And never let speculative code enter your repository.	+	Know your next commit. If you cannot finish, throw away your changes and define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. And never let speculative code enter your repository.

	By [[Dan Bergh Johnsson]]		By [[Dan Bergh Johnsson]]

Kevlin at 19:49, 22 November 2008

Kevlin — Sat, 22 Nov 2008 19:49:59 GMT

←Older revision		Revision as of 19:49, 22 November 2008
Line 1:		Line 1:
-	Know Your Next Commit
-
	I tapped a programmer on her shoulder and asked what she was doing. “I am refactoring these methods”, she answered. I tapped a second programmer on his shoulder and asked what he was doing, “I am adding some parameters to this web action”, he answered. The third answered. “I am working on this user story”		I tapped a programmer on her shoulder and asked what she was doing. “I am refactoring these methods”, she answered. I tapped a second programmer on his shoulder and asked what he was doing, “I am adding some parameters to this web action”, he answered. The third answered. “I am working on this user story”

Line 16:		Line 14:

	Know your next commit. If you cannot finish, throw away your changes, and define a new task you believe in with the insights you have gained. Do speculative experiment whenever needed, but do not let yourself slip into speculative mode without noticing. And never let speculative code enter your repository.		Know your next commit. If you cannot finish, throw away your changes, and define a new task you believe in with the insights you have gained. Do speculative experiment whenever needed, but do not let yourself slip into speculative mode without noticing. And never let speculative code enter your repository.
		+
		+	By [[Dan Bergh Johnsson]]
		+
		+	This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page

Danbj: inital version

Danbj — Sat, 22 Nov 2008 18:13:23 GMT

inital version

New page

Know Your Next Commit

I tapped a programmer on her shoulder and asked what she was doing. “I am refactoring these methods”, she answered. I tapped a second programmer on his shoulder and asked what he was doing, “I am adding some parameters to this web action”, he answered. The third answered. “I am working on this user story”

It might seem that number one and two where focusing on details of their work and that the second focused on the bigger picture, and that the latter should be better. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and where to be finished within an hour or so. The third programmer answered: “Oh, I guess I will be ready within a few days; I will probably add a few classes and might have to change those services some way.”

The first two programmers did not lack consideration of the over-all goal of what they where doing. But, they had selected a task that they could get a grip on, that led in a productive direction, and they thought could be finished within two hours. Once they had finished that task, they would select a new change or refactoring. In that way all the code they wrote where written with a clear purpose and a limited and achievable goal in mind.

The third programmer had simply not been able to break down the problem and where working on all of it at one go. He had no idea of what it would take, and where basically doing speculative programming, hoping that he would arrive at some point where he would be able to commit. Most probably the code written in the start of this long session where poorly directed for the solution that came out in the end.

What would the two programmers do if the task they had selected came out to take more than two hours? They would simply realise that they had taken too big a bite, throw away their changes, define a smaller task, and start over. To keep working would have been speculative, and you do not want speculative code in your repository. So, the changes where thrown away, but the insights where kept.

On the other hand, the third programmer would probably just keep guessing with less and less clue and desperately try to patch together his changes to something that could be committed. Because, you cannot throw away code-changes you have done – that would be a waste of work wouldn’t it? Unfortunately that causes a lot of strange code-changes without a clear purpose to enter the repository.

At some point of time even the commit-hard-ass programmers could not find something they thought could be finished in two hours and would lead in a productive direction. Then, they would go directly into speculative mode and play around with the code: trying some wild refactoring just to see how the code would move, or patching on some functionality to see if it would fit in the structure – and of course throwing away the changes whenever they had gained some insight leading them on track. Because, of course even these seemingly unstructured hacking sessions had a purpose: to learn about the code to be able to define a task that would constitute a productive step.

Know your next commit. If you cannot finish, throw away your changes, and define a new task you believe in with the insights you have gained. Do speculative experiment whenever needed, but do not let yourself slip into speculative mode without noticing. And never let speculative code enter your repository.