I particularly like:
Principle 1 – There is much to be gained by sharing your experiences, ideas, and problems with your peers.
I like it for a number of reasons:
Firstly, who are the best folks to estimate how long a piece of software will take to write? Answer: the folks who’ll be writing the software in the first place. Sharing your experiences, ideas and problems with your peers will ultimately improve your estimating ability and that has to be a good thing. There’s more about this topic in this blog post: #5 – Whose schedule is it anyway?
Secondly, a problem shared in a problem halved. Share your problems and other folks might/will come up with answers. It’s a good idea to make sure that you air your problems in a suitably qualified peer-group, otherwise you might get some poor answers. But nonetheless, problem sharing is a good thing, there is much to be gained from it.
Thirdly, it helps focus the mind such that you solve the right problem. All too often, and this is especially true if you find yourself isolated or working alone for period of time, your mind will play tricks on you and make you believe that you’re solving the right problem…when in fact you’re not…you’re off solving the wrong problem. Simply talking about a problem can be a real eye-opener and can result in a “seeing the light” moment whereupon you recognise that you were about to spend time working on something that wasn’t part of the solution.
If you don’t fancy reading the original article and are just a tiny bit curious about what the second principle was, here’s the spoiler:
Principle 2 – Managers HATE to see software practitioners conversing with one another.
I might write more about principle 2 later, however in the meantime, I would recommend that you read the article: Two Principles of Conversation.