Like all of the good roundup podcasts it is just painful to not be able to chime it and add my 2 cents. This one pushed me over the edge, so here are my two additions to the already great discussion.
First, I have a very visual though process. With very hard problems I start with a blank sheet of paper and try to write down the problem in a clear manner. Sometimes the answer becomes apparent. Next, I draw pictures, write out steps, break down steps, plan experiments and generally try to capture many potential courses of action, then evaluate, and then execute. When part of the problem is a large pre-existing code base, I print lots of the interesting sections of code, draw, highlight, annotate and create a huge visual "context" that helps me see the big picture in a way that I can't see while flipping between screens. (It helps a lot to write a nice little script that pre-processes your code and adds line-numbers and file locations, maximizes margins, small font or two columns per page. etc.) The key is to capture as much understanding as possible as it occurs, so that a week later I can still look at my annotations and notes and don't have to figure it out again. Second, (Here is a previous discussion I had with another business programmer.) Programmers can be compared to optimization algorithms. In fact they actually are optimization algorithms once you think about it. Given a solution space, you can apply different classes of algorithms and get different results. In fact, the art is in figuring out the right balance of capabilities/costs for a given solution space. Consider the simple solution space of finding the high point in a mountain range. An iterator, will start walking uphill until he can't get any higher. Smarter iterators will look around and see if they can find a higher peak in sight and then head for it. However, a global optimizer will get dropped off in lots of different "random" locations and do quick surveys of the local terrain, aggregate the data to find the high point. And hybrids mix the two approaches. Iterators are very fast at climbing slopes to find the "closest" solution, but are unaware of the relative value of their solution or of existence of other solutions that you can't "see" as a modification of the current path. Surveyors are much better at finding new solutions, but can spend a lot of time looking, when the local solution is good enough. So it is with programmers. I find it troubling that people focus so much on the right process, without considering the big picture. For example, agile programming makes everybody better iterators, but at what cost? One of the best and most productive engineers I know is a phenomenal surveyor that can take ideas from other disciplines and apply them in very inventive ways. He can often find elegant solutions by questioning assumptions and re-framing thought processes. Iterators that work with him are sometimes threatened or baffled that he would dare mess with things that they all accept. They are especially horrified at the prospect of him not be able to predict accurately how long it will take to find the solution. Lucky for him, he has proved himself enough, that management tends to let him have enough space to work his magic. Management also sometimes uses him in parallel with the iterators so they can feel good about the predictable path, but hope for the breakthrough. As a coder, when I have an issue, I have started to consider if I should put on my iterator hat, or my surveyors hat. My surveyors hat is to help me find things that nobody else has done yet, but is slow, and requires lots of false trails and even complete reboots. As a surveyor, simple tests and easy prototyping are your friends. My iterator hat comes into play once the the problem is similar to what has come before. Roughly speaking, Surveyor = R&D, iterator = production. It is usually a very tough road to try to iterate your way to innovation. As a business owner/manager I think about what kind of programmer I need for a given job. One of my big (20K) mistakes was to bring in an exceptional iterator before my surveying was done. We got to 80% and had lots of exciting progress, but once there, it was impossible to reach the final goal. Love the podcast. (Love the Scala too, but please don't fry me with the Scala-flames) Cheers, James -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
