I focused on one at at time, making steady

This week I've been deep in an epic coding session, worthy of the rousing soundtrack you get in Hollywood hacker movies. It's fun. And something interesting: In working on this application (doesn't matter what it is), I was stuck on an important subsystem. It had to do with how my application integrates with a complex vendor API - but again, that detail doesn't matter. What matters is that, when I started, I could see four possible ways to implement it. And it wasn't clear which was best. So I invested a good chunk of time spec'ing them all out. Reasoning how each would fit in the app's architecture... And after, I still couldn't tell if ANY of them would work. Or all of them. Or only one. (Which one)? As you get better at coding, you encounter dilemmas like this less often. Like a master chess player, you get better at "pattern matching" increasingly complex coding situations, and able to reckon which choice has the best chance of working out well. But it still happens. So. What which of the four did I choose? I did all of them. That's right. I re-coded the same subsystem FOUR DIFFERENT TIMES, in completely different ways. And it's not the first time I did something like this. In fact, it's COMMON that I'll see two possible ways to code up a solution; realize I don't have the clarity and information to choose between them; and code up both to see what works best. So when I next encounter a similar situation, I will not have to guess which will work better. I'll KNOW. Are you starting to see the greater value of this? Of being WILLING to do this? (Coding up two possible ways is common for me. Three is uncommon. Coding up four is quite rare, but the same benefits and principles apply, for all N > 1.) What made it easier is that I didn't have to finish all four. I focused on one at at time, making steady progress until I hit a wall with that approach which seemed hard to deal with. I then took a break by switching to the next approach, and came back to the original later. And eventually, one of them "clicked". Doing all this clarified everything I didn't yet have clarity on, and I then could correctly identify which of the four approaches would (A) work, (B) work best. In the process, I got a superpowered, intense kind of practice-that-makes-perfect faster and more deeply than any other kind of coding. Not many developers are willing to do this. Are you? Because if you are, it's one of the most powerful ways I've found to accelerate and amplify your skill writing software. If you are not sure, know that you CAN be the kind of person willing to do that, just by deciding that you are. Nothing stopping you. The Powerful Python Newsletter is just for you. Like reader Charles Hayden puts it: "I have seen a lot of books, articles, and newsletters over the years and yours is one of the best. Not just what you say about Python, but how to go about learning." Article Source: http://EzineArticles.com/10423079