Put the Mouse Down and Step Away from the Keyboard - Revision history

Kevlin at 10:48, 16 August 2009

Kevlin — Sun, 16 Aug 2009 10:48:50 GMT

←Older revision		Revision as of 10:48, 16 August 2009
Line 17:		Line 17:
	}		}

-	The same code appeared twice more, with appropriate changes to the character offset and upper limit, to test the minutes and seconds. The method ended with these lines to ~~test~~ for ''AM'' or ''PM'':	+	The same code appeared twice more, with appropriate changes to the character offset and upper limit, to test the minutes and seconds. The method ended with these lines to check for ''AM'' and ''PM'':

	if (!time.substring(9, 11).equals("AM") & !time.substring(9, 11).equals("PM")) {		if (!time.substring(9, 11).equals("AM") & !time.substring(9, 11).equals("PM")) {
Line 23:		Line 23:
	}		}

-	If ~~neither~~ of ~~the~~ comparisons failed ~~and returned~~ <code>false</code> ~~then~~ the method returned <code>true</code>.	+	If none of this series of comparisons failed, returning <code>false</code>, the method returned <code>true</code>.

	If the preceding code seems wordy and difficult to follow, don't worry. I thought so too — which meant I'd found something worth cleaning up. I refactored it and wrote a few unit tests, just to make sure it still worked.		If the preceding code seems wordy and difficult to follow, don't worry. I thought so too — which meant I'd found something worth cleaning up. I refactored it and wrote a few unit tests, just to make sure it still worked.

BurkHufnagel at 16:47, 10 August 2009

BurkHufnagel — Mon, 10 Aug 2009 16:47:10 GMT

←Older revision		Revision as of 16:47, 10 August 2009
Line 38:		Line 38:

	So the next time you hit a nasty problem, do yourself a favor. Once you really understand the problem go do something involving the creative side of your brain — sketch out the problem, listen to some music, or just take a walk outside. Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard.		So the next time you hit a nasty problem, do yourself a favor. Once you really understand the problem go do something involving the creative side of your brain — sketch out the problem, listen to some music, or just take a walk outside. Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard.
-
-	P.S. If you're interested in learning more about how your brain works, there's lots of sources available. My current favorite is Andy Hunt's book ''Pragmatic Thinking and Learning''.

	By [[BurkHufnagel]]		By [[BurkHufnagel]]

Kevlin at 13:32, 1 August 2009

Kevlin — Sat, 01 Aug 2009 13:32:26 GMT

←Older revision		Revision as of 13:32, 1 August 2009
Line 19:		Line 19:
	The same code appeared twice more, with appropriate changes to the character offset and upper limit, to test the minutes and seconds. The method ended with these lines to test for ''AM'' or ''PM'':		The same code appeared twice more, with appropriate changes to the character offset and upper limit, to test the minutes and seconds. The method ended with these lines to test for ''AM'' or ''PM'':

-	if (!time.substring(9, 11).equals("AM") & !time.substring(9, 11).equals("PM") ) {	+	if (!time.substring(9, 11).equals("AM") & !time.substring(9, 11).equals("PM")) {
	return false;		return false;
	}		}
Line 27:		Line 27:
	If the preceding code seems wordy and difficult to follow, don't worry. I thought so too — which meant I'd found something worth cleaning up. I refactored it and wrote a few unit tests, just to make sure it still worked.		If the preceding code seems wordy and difficult to follow, don't worry. I thought so too — which meant I'd found something worth cleaning up. I refactored it and wrote a few unit tests, just to make sure it still worked.

-	When I finished, I felt pleased with the results. The new version was easy to read, half the size, and more accurate because the original code ~~only~~ tested the upper boundary for the ~~hour~~, minutes, and seconds.	+	When I finished, I felt pleased with the results. The new version was easy to read, half the size, and more accurate because the original code tested only the upper boundary for the hours, minutes, and seconds.

-	While getting ready for work the next day, an idea popped in my head~~; why~~ not validate the string using a regular expression? After a few minutes typing, I had a working implementation in just one line of code. Here it is:	+	While getting ready for work the next day, an idea popped in my head: Why not validate the string using a regular expression? After a few minutes typing, I had a working implementation in just one line of code. Here it is:

	public static boolean validateTime(String time) {		public static boolean validateTime(String time) {
-	return time.matches( "(0[1-9]\|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)" );	+	return time.matches("(0[1-9]\|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)");
	}		}

	The point of this story is not that I eventually replaced over thirty lines of code with just one. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem.		The point of this story is not that I eventually replaced over thirty lines of code with just one. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem.

-	So the next time you hit a nasty problem, do yourself a favor. Once you really understand the problem go do something involving the creative side of your brain; sketch out the problem, listen to some music, or just take a walk outside. Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard.	+	So the next time you hit a nasty problem, do yourself a favor. Once you really understand the problem go do something involving the creative side of your brain — sketch out the problem, listen to some music, or just take a walk outside. Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard.

	P.S. If you're interested in learning more about how your brain works, there's lots of sources available. My current favorite is Andy Hunt's book ''Pragmatic Thinking and Learning''.		P.S. If you're interested in learning more about how your brain works, there's lots of sources available. My current favorite is Andy Hunt's book ''Pragmatic Thinking and Learning''.

Kevlin: Put the mouse down and step away from the keyboard moved to Put the Mouse Down and Step Away from the Keyboard

Kevlin — Sat, 01 Aug 2009 13:28:10 GMT

Put the mouse down and step away from the keyboard moved to Put the Mouse Down and Step Away from the Keyboard

←Older revision

Revision as of 13:28, 1 August 2009

Kevlin at 21:28, 31 July 2009

Kevlin — Fri, 31 Jul 2009 21:28:55 GMT

←Older revision		Revision as of 21:28, 31 July 2009
Line 1:		Line 1:
-	~~You’ve~~ been focused for hours on some gnarly problem and there's no solution in sight. So you get up to stretch your legs, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.	+	You've been focused for hours on some gnarly problem and there's no solution in sight. So you get up to stretch your legs, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.

-	Does this scenario sound familiar? Ever wonder why it happens? The trick is that while ~~you’re~~ coding, the logical part of your brain is active and the creative side is shut out. It ~~can’t~~ present anything to you until the logical side takes a break.	+	Does this scenario sound familiar? Ever wonder why it happens? The trick is that while you're coding, the logical part of your brain is active and the creative side is shut out. It can't present anything to you until the logical side takes a break.

-	~~Here’s~~ a real-life example: I was cleaning up some legacy code and ran into an ~~“interesting”~~ method. It was designed to verify that a string contained a valid time using the format ~~“hh~~:mm:ss ~~xx”~~, where ~~‘hh’~~ represents the hour, ~~‘mm’~~ represents minutes, ~~‘ss’~~ represents seconds, and ~~‘xx’~~ is either ~~‘AM’~~ or ~~‘PM’~~.	+	Here's a real-life example: I was cleaning up some legacy code and ran into an 'interesting' method. It was designed to verify that a string contained a valid time using the format ''hh:mm:ss xx'', where ''hh'' represents the hour, ''mm'' represents minutes, ''ss'' represents seconds, and ''xx'' is either ''AM'' or ''PM''.

	The method used the following code to convert two characters (representing the hour) into a number, and verify it was within the proper range:		The method used the following code to convert two characters (representing the hour) into a number, and verify it was within the proper range:
		+
	try {		try {
-	Integer.parseInt( time.substring(0, 2) );	+	Integer.parseInt(time.substring(0, 2));
-	} catch ( Exception x ) {	+	} catch (Exception x) {
	return false;		return false;
	}		}

-	if ( Integer.parseInt(time.substring(0, 2) ) > 12) {	+	if (Integer.parseInt(time.substring(0, 2)) > 12) {
	return false;		return false;
	}		}

-	The same code appeared twice more, with appropriate changes to the character offset and upper limit, to test the minutes and seconds. The method ended with these lines to test for ~~‘AM’~~ or ~~‘PM’~~:	+	The same code appeared twice more, with appropriate changes to the character offset and upper limit, to test the minutes and seconds. The method ended with these lines to test for ''AM'' or ''PM'':
-	if ( !time.substring(9, 11).equals("AM") & !time.substring(9, 11).equals("PM") ) {	+
		+	if (!time.substring(9, 11).equals("AM") & !time.substring(9, 11).equals("PM") ) {
	return false;		return false;
	}		}

-	If ~~none~~ of the comparisons failed and returned ~~“false”~~ then the method returned ~~“true”~~.	+	If neither of the comparisons failed and returned <code>false</code> then the method returned <code>true</code>.

-	If the preceding code seems wordy and difficult to follow, ~~don’t~~ worry. I thought so too; which meant ~~I’d~~ found something worth cleaning up. I refactored it and wrote a few unit tests - just to make sure it still worked.	+	If the preceding code seems wordy and difficult to follow, don't worry. I thought so too — which meant I'd found something worth cleaning up. I refactored it and wrote a few unit tests, just to make sure it still worked.

	When I finished, I felt pleased with the results. The new version was easy to read, half the size, and more accurate because the original code only tested the upper boundary for the hour, minutes, and seconds.		When I finished, I felt pleased with the results. The new version was easy to read, half the size, and more accurate because the original code only tested the upper boundary for the hour, minutes, and seconds.

	While getting ready for work the next day, an idea popped in my head; why not validate the string using a regular expression? After a few minutes typing, I had a working implementation in just one line of code. Here it is:		While getting ready for work the next day, an idea popped in my head; why not validate the string using a regular expression? After a few minutes typing, I had a working implementation in just one line of code. Here it is:
-	public static boolean validateTime( String time ) {	+
		+	public static boolean validateTime(String time) {
	return time.matches( "(0[1-9]\|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)" );		return time.matches( "(0[1-9]\|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)" );
	}		}
Line 36:		Line 39:
	So the next time you hit a nasty problem, do yourself a favor. Once you really understand the problem go do something involving the creative side of your brain; sketch out the problem, listen to some music, or just take a walk outside. Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard.		So the next time you hit a nasty problem, do yourself a favor. Once you really understand the problem go do something involving the creative side of your brain; sketch out the problem, listen to some music, or just take a walk outside. Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard.

-	P.S. If ~~you’re~~ interested in learning more about how your brain works, ~~there’s~~ lots of sources available. My current favorite is Andy ~~Hunt’s~~ book ~~“Pragmatic~~ Thinking and ~~Learning”~~.	+	P.S. If you're interested in learning more about how your brain works, there's lots of sources available. My current favorite is Andy Hunt's book ''Pragmatic Thinking and Learning''.

	By [[BurkHufnagel]]		By [[BurkHufnagel]]

BurkHufnagel at 12:38, 2 July 2009

BurkHufnagel — Thu, 02 Jul 2009 12:38:53 GMT

←Older revision		Revision as of 12:38, 2 July 2009
Line 1:		Line 1:
-	I was cleaning up some legacy code and ran into an ~~interesting~~ method. It was designed to verify that a string contained a valid time using the format “hh:mm:ss xx”, where ‘hh’ represents the hour, ‘mm’ represents minutes, ‘ss’ represents seconds, and ‘xx’ is either ‘AM’ or ‘PM’.	+	You’ve been focused for hours on some gnarly problem and there's no solution in sight. So you get up to stretch your legs, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.
		+
		+	Does this scenario sound familiar? Ever wonder why it happens? The trick is that while you’re coding, the logical part of your brain is active and the creative side is shut out. It can’t present anything to you until the logical side takes a break.
		+
		+	Here’s a real-life example: I was cleaning up some legacy code and ran into an “interesting” method. It was designed to verify that a string contained a valid time using the format “hh:mm:ss xx”, where ‘hh’ represents the hour, ‘mm’ represents minutes, ‘ss’ represents seconds, and ‘xx’ is either ‘AM’ or ‘PM’.

	The method used the following code to convert two characters (representing the hour) into a number, and verify it was within the proper range:		The method used the following code to convert two characters (representing the hour) into a number, and verify it was within the proper range:
Line 30:		Line 34:
	The point of this story is not that I eventually replaced over thirty lines of code with just one. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem.		The point of this story is not that I eventually replaced over thirty lines of code with just one. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem.

-	~~If you’re an experienced programmer, my story may sound familiar. It often goes like this: You’ve been focused for hours on some gnarly problem and there's no solution in sight.~~ So you ~~get up to stretch your legs, or to~~ hit ~~the vending machines~~, ~~and on~~ the ~~way back~~ the ~~answer suddenly becomes obvious.~~	+	So the next time you hit a nasty problem, do yourself a favor. Once you really understand the problem go do something involving the creative side of your brain; sketch out the problem, listen to some music, or just take a walk outside. Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard.
-		+
-	~~The trick is that while you’re coding, the logical part~~ of your brain ~~is active and~~ the ~~creative side is shut out~~. ~~It can’t present anything to~~ you ~~until the logical side takes~~ a ~~break. So~~ put the mouse down, and step away from the keyboard~~. The insights you gain may surprise you~~.	+

	P.S. If you’re interested in learning more about how your brain works, there’s lots of sources available. My current favorite is Andy Hunt’s book “Pragmatic Thinking and Learning”.		P.S. If you’re interested in learning more about how your brain works, there’s lots of sources available. My current favorite is Andy Hunt’s book “Pragmatic Thinking and Learning”.

BurkHufnagel at 03:20, 13 March 2009

BurkHufnagel — Fri, 13 Mar 2009 03:20:30 GMT

←Older revision		Revision as of 03:20, 13 March 2009
Line 1:		Line 1:
-	~~While~~ cleaning up some legacy code~~, I found a~~ method designed to verify that a ~~formatted~~ string contained a valid time~~. The expected~~ format ~~was~~ “hh:mm:ss xx”, where ‘hh’ represents the hour, ‘mm’ represents minutes, ‘ss’ represents seconds, and ‘xx’ is either ‘AM’ or ‘PM’~~. It seemed fairly long so I took a closer look~~.	+	I was cleaning up some legacy code and ran into an interesting method. It was designed to verify that a string contained a valid time using the format “hh:mm:ss xx”, where ‘hh’ represents the hour, ‘mm’ represents minutes, ‘ss’ represents seconds, and ‘xx’ is either ‘AM’ or ‘PM’.

-	The method used the following code to convert two characters (representing the hour) into a number, and verify ~~that~~ it was within the proper range:	+	The method used the following code to convert two characters (representing the hour) into a number, and verify it was within the proper range:
	try {		try {
	Integer.parseInt( time.substring(0, 2) );		Integer.parseInt( time.substring(0, 2) );
Line 12:		Line 12:
	}		}

-	The same ~~basic~~ code appeared twice more, with appropriate changes to the character offset and upper limit, to test the minutes and seconds. The method ended with these lines to test for ‘AM’ or ‘PM’:	+	The same code appeared twice more, with appropriate changes to the character offset and upper limit, to test the minutes and seconds. The method ended with these lines to test for ‘AM’ or ‘PM’:
	if ( !time.substring(9, 11).equals("AM") & !time.substring(9, 11).equals("PM") ) {		if ( !time.substring(9, 11).equals("AM") & !time.substring(9, 11).equals("PM") ) {
	return false;		return false;
	}		}

-	If none of the ~~previous code found a problem~~ and returned “false” then the method returned “true”.	+	If none of the comparisons failed and returned “false” then the method returned “true”.

-	If the preceding code seems wordy and difficult to follow, don’t worry. ~~Even an experienced Java developer might think the same~~; which meant I’d found something worth cleaning up. I refactored it and wrote a few unit tests - just to make sure it still worked.	+	If the preceding code seems wordy and difficult to follow, don’t worry. I thought so too; which meant I’d found something worth cleaning up. I refactored it and wrote a few unit tests - just to make sure it still worked.

-	I felt pleased with the results. The new version was ~~easier~~ to read, half the size, and more accurate because the original code ~~had~~ only tested the upper boundary for the hour, minutes, and seconds.	+	When I finished, I felt pleased with the results. The new version was easy to read, half the size, and more accurate because the original code only tested the upper boundary for the hour, minutes, and seconds.

-	While getting ready for work the next day, an idea popped in my head; why not ~~use~~ a regular expression ~~to validate the string~~? After a few minutes typing, I had a ~~new~~ implementation ~~that only needed~~ one line of code~~. It worked, but it felt too complicated so I split it in two to make it more readable~~. Here it is:	+	While getting ready for work the next day, an idea popped in my head; why not validate the string using a regular expression? After a few minutes typing, I had a working implementation in just one line of code. Here it is:
	public static boolean validateTime( String time ) {		public static boolean validateTime( String time ) {
-	~~String REGEX_PATTERN =~~ "(0[1-9]\|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)";	+	return time.matches( "(0[1-9]\|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)" );
-	~~return time.matches( REGEX_PATTERN~~ );	+
	}		}

-	The point of this story is not that I eventually replaced over thirty lines of code with just ~~two~~. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem.	+	The point of this story is not that I eventually replaced over thirty lines of code with just one. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem.

-	If you’re an experienced programmer, ~~this scenario~~ may sound familiar. It often goes like this: You’ve been focused for hours on some gnarly problem and there's no solution in sight. ~~You~~ get up to stretch your legs, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.	+	If you’re an experienced programmer, my story may sound familiar. It often goes like this: You’ve been focused for hours on some gnarly problem and there's no solution in sight. So you get up to stretch your legs, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.

	The trick is that while you’re coding, the logical part of your brain is active and the creative side is shut out. It can’t present anything to you until the logical side takes a break. So put the mouse down, and step away from the keyboard. The insights you gain may surprise you.		The trick is that while you’re coding, the logical part of your brain is active and the creative side is shut out. It can’t present anything to you until the logical side takes a break. So put the mouse down, and step away from the keyboard. The insights you gain may surprise you.
		+
		+	P.S. If you’re interested in learning more about how your brain works, there’s lots of sources available. My current favorite is Andy Hunt’s book “Pragmatic Thinking and Learning”.

	By [[BurkHufnagel]]		By [[BurkHufnagel]]

BurkHufnagel at 03:04, 7 March 2009

BurkHufnagel — Sat, 07 Mar 2009 03:04:03 GMT

←Older revision		Revision as of 03:04, 7 March 2009
Line 21:		Line 21:
	If the preceding code seems wordy and difficult to follow, don’t worry. Even an experienced Java developer might think the same; which meant I’d found something worth cleaning up. I refactored it and wrote a few unit tests - just to make sure it still worked.		If the preceding code seems wordy and difficult to follow, don’t worry. Even an experienced Java developer might think the same; which meant I’d found something worth cleaning up. I refactored it and wrote a few unit tests - just to make sure it still worked.

-	I felt pleased with the ~~rsults~~. The new version was easier to read, half the size, and more accurate because the original code had only tested the upper ~~bounds~~ for the hour, minutes, and seconds~~. Not bad for half an hour’s work~~.	+	I felt pleased with the results. The new version was easier to read, half the size, and more accurate because the original code had only tested the upper boundary for the hour, minutes, and seconds.

-	While getting ready for work the next day, an idea popped in my head; use a regular expression to validate the string. After a few minutes typing, I had a new implementation that only needed one line of code. It worked, but it felt too complicated so I split it in two to make it more readable. Here it is:	+	While getting ready for work the next day, an idea popped in my head; why not use a regular expression to validate the string? After a few minutes typing, I had a new implementation that only needed one line of code. It worked, but it felt too complicated so I split it in two to make it more readable. Here it is:
	public static boolean validateTime( String time ) {		public static boolean validateTime( String time ) {
	String REGEX_PATTERN = "(0[1-9]\|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)";		String REGEX_PATTERN = "(0[1-9]\|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)";
Line 29:		Line 29:
	}		}

-	The point of this story is not that I eventually ~~wrote two~~ lines of code ~~that did what the original didn’t quite accomplish~~ with ~~over thirty~~. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem.	+	The point of this story is not that I eventually replaced over thirty lines of code with just two. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem.

-	If you’re an experienced programmer, ~~you’ve probably had similar experiences~~. It often goes like this: You’ve been focused for hours on some gnarly problem and there's no solution in sight. You get up ~~for a bio-break~~, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.	+	If you’re an experienced programmer, this scenario may sound familiar. It often goes like this: You’ve been focused for hours on some gnarly problem and there's no solution in sight. You get up to stretch your legs, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.

-	The trick is that while you’re coding, the logical part of your brain is active and the creative side is shut out. It can’t present anything to you until the logical side takes a break. So put the mouse down and step away from the keyboard. The insights you gain may surprise you.	+	The trick is that while you’re coding, the logical part of your brain is active and the creative side is shut out. It can’t present anything to you until the logical side takes a break. So put the mouse down, and step away from the keyboard. The insights you gain may surprise you.

	By [[BurkHufnagel]]		By [[BurkHufnagel]]

BurkHufnagel at 02:49, 7 March 2009

BurkHufnagel — Sat, 07 Mar 2009 02:49:04 GMT

←Older revision		Revision as of 02:49, 7 March 2009
Line 1:		Line 1:
	While cleaning up some legacy code, I found a method designed to verify that a formatted string contained a valid time. The expected format was “hh:mm:ss xx”, where ‘hh’ represents the hour, ‘mm’ represents minutes, ‘ss’ represents seconds, and ‘xx’ is either ‘AM’ or ‘PM’. It seemed fairly long so I took a closer look.		While cleaning up some legacy code, I found a method designed to verify that a formatted string contained a valid time. The expected format was “hh:mm:ss xx”, where ‘hh’ represents the hour, ‘mm’ represents minutes, ‘ss’ represents seconds, and ‘xx’ is either ‘AM’ or ‘PM’. It seemed fairly long so I took a closer look.

-	The method used the following code to convert two characters (representing the hour) into a number, and verify that it was in the proper range:	+	The method used the following code to convert two characters (representing the hour) into a number, and verify that it was within the proper range:
	try {		try {
	Integer.parseInt( time.substring(0, 2) );		Integer.parseInt( time.substring(0, 2) );
Line 7:		Line 7:
	return false;		return false;
	}		}
-		+
	if ( Integer.parseInt(time.substring(0, 2) ) > 12) {		if ( Integer.parseInt(time.substring(0, 2) ) > 12) {
	return false;		return false;

BurkHufnagel at 02:47, 7 March 2009

BurkHufnagel — Sat, 07 Mar 2009 02:47:00 GMT

←Older revision		Revision as of 02:47, 7 March 2009
Line 29:		Line 29:
	}		}

-	The point of this story is not that I eventually wrote ~~one line~~ of code that did what the original didn’t quite accomplish with over thirty. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem.	+	The point of this story is not that I eventually wrote two lines of code that did what the original didn’t quite accomplish with over thirty. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem.

	If you’re an experienced programmer, you’ve probably had similar experiences. It often goes like this: You’ve been focused for hours on some gnarly problem and there's no solution in sight. You get up for a bio-break, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.		If you’re an experienced programmer, you’ve probably had similar experiences. It often goes like this: You’ve been focused for hours on some gnarly problem and there's no solution in sight. You get up for a bio-break, or to hit the vending machines, and on the way back the answer suddenly becomes obvious.