> Write a book based on a selection of distorted anecdotes showing that instincts are superior to rational judgment and you get a best seller. Imagine how popular a book would be that urged people to engage in difficult study to develop their ability to think so they could rid themselves of the irrational and often destructive beliefs they now cherish. So, trying to get people to think is dangerous. Over the centuries, many have been killed in the attempt. Fortunately, when applied to programming rather than more sensitive subjects, preaching rational thought leads to polite indifference rather than violence. However, the small number of programmers who are willing to consider such a radical alternative to their current practice will find that thinking offers great benefits. Spending a few hours thinking before writing code can save days of debugging and rewriting.
I'm not sure I agree, though, ultimately. Sometimes too much up-front thinking about big huge complex systems is just not possible or productive. It's better to get in and start interacting the system, as that can also drive a more thorough understanding of the system.
I particularly liked the bit about Butler Lampson being the first to understand Paxos, mostly because I'm current in his distributed and concurrent systems class. It turns out that when Lamport wrote the paper The Part-Time Parliament, Lampson told him that nobody actually understood it. To prove him wrong, Lamport called a few colleagues and asked them a few elementary questions about the algorithm. They all got it wrong. That prompted him to write Paxos Made Simple.
It's good to know that it's not always my fault when academic papers are entirely inscrutable.
Well, out of fairness, The Part-Time Parliament is a story about a fake Greek society, replete with "Greek"-style reinterpreted names for researchers Lamport wanted to name check. Extended metaphor is not the standard academic approach. Not to mention, the math behind the paper is kind of beyond the grasp of most on the first few readings.
Lamport clocks is one topic that stood out most prominently in everything I took away from my excellent distributed systems class. I have no idea why, but the second I heard "Lamport clock," it got etched into my brain forever.
It is a good approach. The PLT Scheme textbook How to Design Programs walks you through a process for writing new code that more or less goes like that:
1. Write a comment describing the problem.
2. Write comments describing the form of all the data structures involved in the problem, and turn those comments into data definitions.
3. Then write a comment describing the input and output of a function, write the function header, use the form of the data structures defined above to sketch a function body with comments and a few bits of code; repeat for each operation.
4. Finally, fill in the gaps -- at that point it's almost obvious how each function should be written.
Steve McConnell advocates a similar thing in Code Complete 2, which he calls Pseudocode Programming Process, PPP.
The idea is that when first creating a method or function, you write out in comments what you're going to do in a 'why' level (eg, 'keep track of resources') rather than a 'how' level (eg, 'increase cntFooBar by 1').
You then start 'filling out' the code to do what you 'designed' via the comments. Hopefully you end up with a better designed routine, and you get free comments to boot as they now explain what the code is doing.
When I first read Code Complete as an impressionable teenager I tried it out and liked it, but I have since had a change of heart on this issue and other Code Complete wisdom. I rarely comment inside methods anymore.
> You then start 'filling out' the code to do what you 'designed' via the comments.
Another approach is to just drop the comment markers entirely, massage the pseudocode until it's valid syntax, and then write a DSL that does the right thing upon its execution. That way, all you ever really have is comments.
> Write a book based on a selection of distorted anecdotes showing that instincts are superior to rational judgment and you get a best seller. Imagine how popular a book would be that urged people to engage in difficult study to develop their ability to think so they could rid themselves of the irrational and often destructive beliefs they now cherish. So, trying to get people to think is dangerous. Over the centuries, many have been killed in the attempt. Fortunately, when applied to programming rather than more sensitive subjects, preaching rational thought leads to polite indifference rather than violence. However, the small number of programmers who are willing to consider such a radical alternative to their current practice will find that thinking offers great benefits. Spending a few hours thinking before writing code can save days of debugging and rewriting.
I'm not sure I agree, though, ultimately. Sometimes too much up-front thinking about big huge complex systems is just not possible or productive. It's better to get in and start interacting the system, as that can also drive a more thorough understanding of the system.