Lifelong Learning

The Triumph of Complexity

Alan Greenspan's testimony to congress on Oct 23, 2008, has been amply dissected. Many people, including the congressional questioners, were downright hostile, and eager to place blame for the financial meltdown at Greenspan's feet. You can read tons of such analysis all over the web.

What struck me most listening to Greenspan was his humility, and honesty.  Many people would not make the admissions he made. That his lifelong philosophy was flawed, although he would admit to only partially flawed.

The statement that struck me most, and seems to have escaped most analysts, was his astounding admission that, "If all those extraordinarily capable people were unable to foresee the development of this critical problem ... we have to ask ourselves: Why is that? And the answer is that we're not smart enough as people.  We just cannot see events that far in advance". 

Now this is the man that had just finished talking about the Nobel prize being awarded for the discovery of pricing models. He has also talked about how competent and smart the economic modelers and forecasters at the Federal Reserve were. What he fundamentally said was that we were defeated by complexity. When the top minds in the financial world are "not smart enough", that is not lack of brain power, or education. It is the sheer scale of the complexity. This is a lesson the world better heed. Complexity can almost literally destroy us. Global complexity of the financial system is a topic that will be dealt with in the years to come by the best financial minds in the world, if we are to avoid a repeat of the tsunami that Greenspan thinks is a once in a hundred years event.

Complexity in our profession, system development and IT, can destroy systems, and destroy hopes of completing systems, and managing their development and operation.

A very conscious effort to slay the complexity monster, and a relentless focus on simplicity must be the concern of everyone in our profession. What Greenspan's testimony illustrates is that conquering complexity must at the forefront of all the managers of our economy, and our world.

My Favorite Quotes

Anyone who stops learning is old, whether at twenty or eighty. Anyone who keeps learning stays young. Henry Ford.

Successful conversation will take you very far. Badfinger.

You can't always get what you want. But if you try sometime, you might find, you get what you need. Mick Jagger.

Great minds discuss ideas. Average minds discuss events. Small minds discuss people. Eleanor Roosevelt.

Simplifying and simplicity are never simple matters.  Hans Hofmann.

Simplicity and communication have a wonderful mutually supporting relationship. Kent Beck.

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.  Alan Perlis.

One person's simple is another person's complex. Kent Beck.

What is simplicity? Delete everything that doesn't have a purpose. Kent Beck.

The principle of economy requires that representations of structure contain no more than the necessary elements. Noam Chomsky.

Minimalism derives from a need for simplification. Noam Chomsky.

Lets not combine ignorance with inaudibility. Speak up! Mrs. Cook, my freshman English Professor

Dealing with complexity is an unnecessary waste of time, attention, and mental energy. Edward de Bono.

There is never any justification for things being complex when they could be simple. Edward de Bono.

If you put something simply, you are at the mercy of those who understand neither the subject nor simplicity. Edward de Bono.

It is only when you have a headache that not having a headache is such a very high value. Edward de Bono.

Outside of art, complexity for the sake of complexity has no value whatsover. Edward de Bono.

There is a huge overlap between creativity and simplification. Edward de Bono.

Simplicity is not easy. Edward de Bono.

There is no natural tendency towards simplicity. Edward de Bono.

Simplicity needs a determined effort - it does not just happen. Edward de Bono.

There is a natural tendency for systems to increase in complexity over time. Edward de Bono.

Creativity is the description of a result. Lateral thinking is the description of a process. One can only admire a result, but one can learn to use a process. Edward de Bono.

Complexity sells better. Edsgar Dijkstra.

Elegance is not a dispensable luxury but a factor that decides between success and failure. Edsgar Dijkstra.

Simplicity is prerequisite for reliability. Edsgar Dijkstra.

The lurking suspicion that something could be simplified is the world's richest source of rewarding challenges. Edsgar Dijkstra.

Lets not let the facts bother us. One of my computer science professors at GA Tech.

All models are wrong. Some models are useful.- Bruce Eckel.

A genius is a talented person who has done all his homework. Thomas Edison.

The ability to simplify means to eliminate the unnecessary so that the necessary may speak. Hans Hofmann.

A good programming language helps programmers write good programs. No programming language will pervent its users from writing bad programs. Kees Koster.

Simplicity is the ultimate sophistication. Leonardo da Vinci.

Making the simple complicated is commonplace. Making the complicated simple, that's creativity. Charles Mingus.

Communication is a thought process, not the production of sound waves. Michel Thomas.

Don't get sidetracked by the sound waves.  Michel Thomas.

All generalizations are false, including this one. Mark Twain.

Most problems in computer science can be resolved by another level of indirection. David Wheeler.

People seem to misinterpret complexity as sophistication. Niklaus Wirth.

Asking for LinkedIn Endorsment

There is a good way and not so good a way to ask for a LinkedIn endorsement. The obvious, and not so good way, is to simply shoot out an email requesting the endorsement, with the prepared text from LinkedIn.

A much more effective way is to do two things (both, not one or the other):

1. Write an endorsement first. Give before you take.  If you know the person well enough to request an endorsement, then you know them well enough to write an endorsement for them. If you're not sure how to write an endorsement, read my post on Writing a LinkedIn Endorsement.

2. Help the person in the writing task - particularly if the relationship is not recent, and you've worked with the person years ago. Even if the relationship is recent or current, you want the endorsement to focus on some things and to de-emphasize other things, and you want it to be either general, suitable for many purposes, or specific, suitable for a specific purpose that is important to you at this time. You don't have to write your  own endorsement, but help the writer get started. It is always easier to revise  than to write from scratch - the dreaded blank page. So send your friend a basic skeleton of the endorsement you're looking for along the following lines:

    Can you endorse me? I am thinking of running for President of the USA (or maybe something slightly less ambitious, like I am making the transition to academia as professor of computer science), and I think it would help me if you can say a few words about my abilities and qualities relevant to that kind of position.

     As you know, we worked together on projects, x, y, and z, and we collaborated on tasks a, b, and c.  We have worked together for X years on the XXX team.  While on the XXX team I accomplished this, that, and the other, and I was instrumental in achieving xxxx and yyyy that contributed to the success of the team.

The above is similar to writing a resume paragraph. List the work and your accomplishments for that period.

Your friend, if she knows you well, and agrees with the basic facts of your narrative, will then have enough to go on and add her bit by describing your general and specific qualities:

       Xxx is a gentelman and a scholar. He's more intelligent than Einstein,  a better writer than Hemingway, and a better technical innovator than Steve Jobs, etc., etc.

These two rules should help when you are asked for an endorsement. What you should respond with, if you find that it is hard for one reason or another, to respond quickly, is to simply send the link to this post! You can then add, "I observe Nabil's Rules for LinkedIn Endorsements".  First, endorse me, and I'll be happy to return the favor. Second, send me a skeleton, along the lines Nabil suggests, to get me started.  You may find that you won't have to write that endorsement after all.  This response, in many cases, would make people just go away. There are people who are so averse to writing that they will not write that endorsement for you. Many people just want to take, they don't want to give. Sad but true.

Writing a LinkedIn Endorsement

Seems like a few people have a block when it comes to writing a paragraph or two to endorse a friend on LinkedIn. I guess there may be some psychological forces at play here, but I don't want to venture into pop psychology. I will approach this as a writing task that some seem to fear.

Of course, engineers are notorious for their hatred of "documentation". And here they are asked to "document" their opinion of a colleague and publish it to a small audience of 16 million people, and have it attached to their profile.

First, a very simple principle. Honesty is of the utmost importance. It must be avoided at all costs (as Linda Radnor says - not sure of her name - Vegas comedian ). Not really. Your endorsement must be honest, factual, and accurate. But there is some subtlety to be noted here. Feelings intrude! You may say to yourself: he's a good professional, but I don't like him! He is blah, blah and not blah, blah. Last year he did blah and said blah, blah which upset me.

That's where professionalism comes in.You can work with someone as professionals. You don't have to like them to endorse them! You are a professional, that's the meaning of professionalism. You just write a factual review documenting how you knew the person. You don't need to get into personal feelings and relationship issues.

Ok. Now that we got the "honesty" issue out of the way, how do we proceed? Isn't it amazing, many of us develop supremely complex products, write thousands of lines of code, and produce prodigious architecture and design documents, yet we freeze when it comes to this simple task of endorsing a colleague.

Here is a proposed, simple method:

1. Get the facts down. How do you know this person? How long have you known him/her? In what capacity? What projects did you work on together? What where his contributions? What were his good qualities (ignore bad qualities and bad situations or confrontations - not relevant to the task at hand). So here you have the basic facts. Just the facts, Ma'am!:

I have known Zultan for X years. We worked together on Blibity Blip project and Blobity Blop framework. Zultan brought knowledge of blips, blops, and frombozing to the team. His knowledge of blips and blops, and frombozing was amazing. He is the most knowledgeable person I have met in this area. In addition to knowing about blips and blops, Zultan has extensive experience in weaving blips into blops, bla bla. Facts, facts, projects, tasks. This should be a simple matter of making a list. A list you can abstract from.

2. Write about general abilities, and general team/collaboration characteristics: intelligence, hard work, problem solving ability, perceptiveness, ability to quickly narrow down options, etc. etc. Collabortion, sharing knowledge, helpfulness to others, jumping in, etc. Attributes you have noticed that Zultan shines in. Try to suppress your thoughts that sometimes he can be an ass, or a know-it-all, or whatever other negatives! Leave all negatives out. You can think them, and even have them in your draft. But they stay out of the endorsement, and they don't stop you from completing it. Again, you don't have to love the person, or even like them, as long as you respect, value, and can honestly endorse their work and work-related personal attributes. Stay professional.

3. Write a general endorsing blurb, that does endorse, and not leave the write up in a wishy-washy non committal place. "I would love to work with Hephzebah again". "It would be a pleasure to work with her again". Resist the negative thoughts about, "I never want to work with this ... again, if I can help it".

If you still find you have a block, go back to college and take a course on remedial English - you are hopeless. An easier course of action would be to call your colleague and politely say, "sorry, can't do this, my grandmother died , our entire neighborhood does not have electricity, or my camel is having a baby - or any other equally lame excuse you can muster to hide the fact that you can't write a paragraph! Another, equally lame thing to do, is to resort to an "endorsement generator". Yes, you can write an endorsement with one click, followed by Ctrl-C, Ctrl-V. Google that.

My rule of etiquette for LinkedIn endorsements is to return the favor in under 24 hours. I try to do it within hours, of receiving the notice. If someone endorses you, and you don't return the favor, you are rude. If they ask you explicitly for an endorsement, and you ignore them for days, or weeks, then you are beyond rude. You clearly don't want the person to be in your contacts list. The honest thing to do is to remove them and break off the connection. I remove people like that from my contacts list. That's the LinkeIn acid test. If someone won't give you an endorsement when you ask for it, what point is there in having them as a contact?

Writing for Programmers

Many programmers don't like to write. They think of it as the dreaded "documentation". They just want to write code. But what is writing code? It is a form of writing. I maintain that good programmers are good writers. The problem is that writing that is not coding does not appeal to them. But if you approach a writing task like you do a programming task, you'll notice a definite rise in the quality of your writing (to match the quality of your code). I am sure you'll challenge someone to the death if they dare imply that your code is not the greatest!

So what ideas can we bring to writing from the world of programming?

1. Test Driven Writing. If your coding can be test driven, why not "test drive" your writing? The "unit"
test for a written paragraph is your eyes and ears. Does it sound right? Does it look write? The "acceptance" test for a written piece, is someone else's eyes and ears.

2. Refactoring. You develop code by successive little refactorings till you are pleased with it, have removed all the redundancies, and "it works". Why not "refactor" your writing until "it works"? Look at your sentences and paragraphs and ask, "does this smell right"? In refactoring we go by "code smells". We have a catalog of things that "smell bad", and we attempt to remove them. Do the same with your English prose. Writers have practiced refactoring for centuries. They call it "editing".

If you're a fan of pair programming, there is a parallel there too. But if you're a solo developer, you'll be a solo writer also.So we'll leave pairing aside.

Some resources that can help with the writing task:

- BUGS in writing, A Guide to Debugging Your Prose. A delightful book by Lyn Dupre.

Follows the theme that writing may contain bugs, just like coding. Her main premise is, "the simplest way to improve your writing is to learn to avoid a limited set of common errors". Her main intent, as she states in a "Read Me" (instead of a Forward!), is "My intention is to convey to you the basic principles of good writing, and thus help you to develop ear ....". That is a key skill, "Ear" - a sensitivity to what good prose sounds like. Not different from detecting bad smells in code. The author develops a series of examples and presents them in a BUGS system: Bad, Ugly, Good, and Splendid. A Bad construction contains obvious mistakes and would be embarrassing. An Ugly construction is technically correct, but is not acceptable for one reason or other - well, it is just ugly. A Good construction is acceptable and correct, and would be fine - but you will want to do better. A Splendid construction demonstrates an improvement over a given good solution. The author's contention is that, "once you have developed ear, you will be able to tell without hesitation what constitutes correct syntax, style, and semantics, and will be equipped to communicate effectively with your fellow humans".

- Technically - Write! By Ron S. Blicq.

Good manual for technical writing. A little dated by now, but still a very helpful guide to technical writing with focus, brevity, and clarity. It goes over various forms of technical writing (technical correspondence, informal reports, formal reports, technical description, scientific papers, technical papers, etc.). It has a good section on technical speaking (briefing, papers, meetings, etc.).

- Line by Line - How to Edit Your Own Writing. By Claire Cook.

A good manual on editing.

- The Elements of Style, William Strunk, and E.B. White.

Strunk and White is the granddaddy of style manuals. A masterpiece of concise writing itself. A little book that is a must have, if you're serious about your writing.

Writing to Learn

Writing is a great way to learn (whatever subject you're interested in), and of course, to learn to write well. I used to do a lot of "private writing" and just tuck it away in the file system. I don't have much patience with the editorial and publishing process. Blogging gives me a chance to resurrect what otherwise would be dead pieces. And there is no editorial process!

I highly recommend writing-to-learn, the process, even if you don't blog, or publish. I recommend William Zinsser's book of the same title. Even if you don' blog, try "private writing". It sharpens your knowledge, sharpens your thinking, and you'll have a ready inventory of writings, should you decide later to blog or publish.

Nonsense

Nonsense. Red Herrings, Straw men, and Sacred Cows: How We Abuse Logic in Our Everyday Language. By Robert J. Gula.

From the forward to the book: "Robert John Gula had a relatively short life of forty-seven years. But he wrote or co-wrote seventeen books ranging from Mythology: Greek and Roman to Precision: A Reference Handbook for Writers., and taught Latin, Greek, algebra, geometry, chemistry, English composition, and logic at the Groton School, one of the best secondary schools in America."

Bob Gula described why he wrote Nonsense, a handbook of verbal logic. "Nonsense came about because of my frustration in seeing how people, even highly intelligent people, are often simply unable to communicate when in a group. Having seen many meetings and discussions that floundered, I began to wonder why. That wonder led to a course on informal logic, and that course led to Nonsense."

Nonsense was intended to be the best compilation and study of verbal logical fallacies available anywhere, and it is that and more. On one level, it is a handbook of ways that people deceive themselves and others. On another level, it is a short course in nonmathematical logical thinking, a form of thinking that all of us use and often abuse everyday.

Great little book!