I had some feedback

"I have a theory that the skills required to structure good software programs are similar required to those required to structure and negotiate good financial agreements, but we can leave that for another day."

Yesterday, I made a throwaway comment about the similarities between software programming and structuring and negotiating legal agreements, but I let it pass because I thought no-one would be interested, but I was wrong, so here goes. The arguments here apply more to large software projects, not something you might knock together to play hangman, and similarly to the sort of big financing documents that fill boxes, such as project finance agreements, not your employment contract, although many of the principles apply

• The endgame in programming is to create a piece of software that is fit for its purpose and is robust, the same is true for a set of legal agreements. The robustness of software is assured by testing and code walkthroughs. The robustness of legal agreements is assured by careful review and negotiation. Both are improved by good design.
• Software programming depends on the use of a set of primitives and language. Legal documents are built on defined legal terms and principles. In both cases, the best results are obtained from the best and clearest use of the underlying tools and methods. Precise use of language can often be critical to outcomes in both.
• Portability and reusability are key to both. Do you really think that the first draft of the 200 pages of documents that your lawyer rustled up in a week was drafted from scratch? No, it wasn't, but neither did he do a global edit of the names in last week's deal.
• Design is often critical to maintenance and adaptation. A simple amendment in a poorly structured legal agreement may require several changes in many documents. The same is true in programming. In both cases the possibility of errors or omissions are significant, and the risks can be minimised by good design. Programmers call it encapsulation. Lawyers call it "chucking it in the Definitions section".
• We all know of software geeks who stay up half the night writing code. The good ones can still write good code at half past three in the morning. Same for lawyers.
• You can pick up "good" software and understand it from cold, find your way around it etc. The same is true for "good" legal documents.

I could go on, but I think you get the message. If there any lawyers or programmers who fancy a career change, I know at least one assembler/comms programmer who successfully applied to Harvard Law School and a QC specialising in intellectual property who enjoys writing software in his spare time, so I would say "Go for it", but Edgar Dijkstra probably wouldn't approve.