Back in 1995, I attended a software conference in Manhattan and Jim McCarthy was the keynote speaker. In a sea of suits, he showed up in a Hawaiian shirt and jeans with holes in them. He gave the best talk I've ever heard around software development. His first topic has always stayed with me, which was "Don't Know What You Don't Know." It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you are things you pretended to understand but didn't early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this "lucid ignorance," disaster will surely befall you.Human nature is such that we dislike not knowing things that are important to our well being. Since there is so much we don't know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their ignorance. You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. It requires mental and psychological strength to resist the normal human cravings for certainty and order. It especially difficult to believe in uncertainty when things have a veneer of orderliness, which is often the case. Pseudo-order is a maladapted defense against uncertainty. The organization surrounding you will undoubtedly abhor uncertainty, would infinitely prefer pseudo-order and will make countless attempts to magically convert your ignorance to knowledge. Your job is to make uncertainty an unshakable fact, and to coerce the reshaping of the surrounding organization to cope with the uncertain situation. The organization must learn to thrive in an uncertain environment for its own well being. You should expend a great deal of effort making sure that all the people on the project are aware of their ignorance rather than naively converting it to falsehoods. Bear down on them until they realize they haven't comprehensively assessed the unknowns. In the successful project, this is much easier in the early stages, or during times of change. This is no time for niceties. People ultimately prefer success even if disillusionment is a prerequisite. Genius.Today, as I continue to marvel at what I'm learning from each demo that I do and the feedback that I hear, I realize how much I don't yet know about the solution people need. But I also realize that I'm pretty far along in understanding what's needed. It's funny how often they'll ask a question just as I'm getting to that feature, and how often they'll remark that it flows really well. I can't take the credit for any of that. It's just me listening to a bunch of smart people telling me how I can help them succeed better. Always beware working with the person who refuses to admit ignorance. You'll pay dearly for it later. | 
