The document provides a collection of thoughts and ideas from various sources organized into sections on general thoughts, management thoughts, and software development thoughts. Some of the key ideas summarized are: it is better to focus on creating value rather than profits; expecting the best from people can lead to better outcomes than persistent pessimism; and that fixing errors often costs less than extensive prevention efforts. The document collects wisdom from diverse thinkers and applies to different domains like management, teamwork, and software development.

1. Collected Wisdom
Collected By Nitin Bhide
Till July 2017

2. Collected Wisdom
 Thoughts and ideas collected from
various source.
 Something that resonated.

3. Thoughts
 General Thoughts
 Management Thoughts
 Software Development Thoughts

4. GENERAL THOUGHTS

5. It is mainly the
incompetent
that don't like to show
off their work.

6. The conditions attached
to a promise are
forgotten, only the
promise is remembered.

7. “If you keep doing what you have
always done, you will keep getting
what you have always got”.
– W. Edwards Deming.

8. Teach principles not formulas
-- Richard Feynman

9. Common Sense is not
so Common

10. If only thing you have is a
hammer,
everything looks like a nail

11.  Some see things that are and ask why.
 Some dream of things that aren't and
ask why not.
 Some people have to go to work and
don't have time for all that crap.

12. Never Argue With Idiots.
They bring you down to their level
and then beat you by experience

13. Never attribute to malice that
which can be adequately
explained by stupidity
-- Hanlon's razor

14. ARGUE as if you are right
and LISTEN as if you are wrong
Karl Weick, Psychologist
University of Michigan

15. Disobedience, in the eyes of anyone
who has read history, is man's
original virtue. It is through
disobedience that progress has been
made, through disobedience and
through rebellion.
~ Oscar Wilde

16. One man's magic is another
man's engineering.
Supernatural is a null word.
~ Robert Heinlein

17. When you give food to the poor, they call
you a saint.
When you ask why the poor have no food,
they call you a communist.
~ Archbishop Helder Camara

18. Failure Sucks,
But Instructs
Bob Sutton

19. In theory, there is no difference
between theory and practice.
But, in practice, there is
- Yogi Berra

20.  Walt Disney’s mantra was, “I don’t make movies to make
money—I make money to make movies.” That’s a good way
to sum up the difference between Disney at its height and
Disney when it was lost. It’s also true of Pixar and a lot of
other companies. It seems counterintuitive, but for
imagination-based companies to succeed in the long run,
making money can’t be the focus.
 Speaking personally, I want my films to make money, but
money is just fuel for the rocket. What I really want to
do is to go somewhere. I don’t want to just collect more
fuel.
 - Brad Bird, Pixar

21.  To the optimist, the glass is half full.
 To the pessimist, the glass is half empty.
 To the engineer, the glass is twice as big
as it needs to be.

22. MANAGEMENT THOUGHTS
(GENERAL, PROJECT
MANAGEMENT, TEAM
MANAGEMENT ETC)

23. The Best Results Are
Produced
By Men and Women
Who Don’t Have To Be
Told What To Do

24. Never mistake motion for
action
- Ernest Hemingway (1889-1961)
(one should not confuse activity for progress)

25. Reward success and
failure.
Punish inaction
Bob Sutton

26. A players hire A players.
B players hire C players

27. A Fool with a Tool is still a Fool
(probably a more dangerous fool)

28.  Expect the best in people.
 They may occasionally disappoint you,
 But persistent pessimism hurts you more.

29. You get what you expect from people.
This is especially true when it comes to
selfish behavior; unvarnished self-interest
is a learned social norm, not an
unwavering feature of human behavior.
From Bob Sutton’s Blog

30. “Thinking is very hard work.
And management fashions are a wonderful
substitute for thinking.”
Peter Drucker ,
CIO Magazine, September 15, 1997

31. The individual can take
initiatives without anybody's
permission.
- R. Buckminster Fuller

32. You may be the boss, but
if you constantly have to
solve someone's problems,
you are working for him

33. Integrity means your
subordinates trust you

34. Give a good idea to a mediocre team, and
they will screw it up.
Give a mediocre idea to a great team, and
they will either fix it or come up with
something better. If you get the team
right, chances are that they’ll get the
ideas right.
- Ed Catmull, Creativity, Inc.

35. It is not the manager’s job to prevent risks.
It is the manager’s job to make it safe to
take them.
- Ed Catmull, Creativity, Inc

36. Trust doesn’t mean that you trust that
someone won’t screw up— it means you
trust them even when they do screw up.
- Ed Catmull, Creativity, Inc.

37. Be wary of making too many rules. Rules
can simplify life for managers, but they can
be demeaning to the 95 percent who
behave well. Don’t create rules to rein in
the other 5 percent— address abuses of
common sense individually. This is more
work but ultimately healthier.
- Ed Catmull,. Creativity, Inc

38. Do not fall for the illusion that by
preventing errors, you won’t have errors to
fix. The truth is, the cost of preventing
errors is often far greater than the cost
of fixing them.
- Ed Catmull, Creativity, Inc.

39. THOUGHTS RELATED TO
SOFTWARE
DEVELOPMENT

40. Quality happens only if somebody has the
responsibility for it, and that "somebody"
can be no more than one single person
-- Fred Brooks in Design of Design

41. The review is a failure
if the reviewed learn
nothing from it.

42. It takes one woman nine
months to have a baby. It
cannot be done in one
month by impregnating
nine women (although it is
more fun trying).

43. Too few people on a project
can't solve the problems –
Too many create more
problems than they solve.

44. Any problem in computer science
can be solved with another layer
of indirection. But that usually
will create another problem
David Wheeler
(Inventor of Subroutine and
BWT Transform)

45. Rule of 3 in Software Reuse
 There are two "rules of three" in
[software] reuse:
• It is three times as difficult to build
reusable components as single use
components,
• a reusable component should be tried
out in three different applications
before it will be sufficiently general to
accept into a reuse library.

46. “Debugging is twice as hard as writing the
code in the first place. Therefore, if you
write the code as cleverly as possible, you
are, by definition, not smart enough to
debug it.”
Brian W. Kernighan

47. Organizations which design systems … are
constrained to produce designs which are
copies of the communication structures of
these organizations
M. Conway
http://en.wikipedia.org/wiki/Conway%27s_law

48. When your wife is about to give birth,
it's not really a good idea to take apart
your car's engine.
Instead build a new one on the side
and don't hook it up until it's perfect
- Joel Spolsky

49. • Non-programmers THINK
programming is HARD.
• Average programmers THINK
programming is EASY.
• Good programmers KNOW
programming is HARD.

50. The model that really matters is the one
that people have in their minds. All other
models and documentation exist only to
get the right model into the right mind at
the right time.
-- Paul Oldfield

51. For a new software system, the
requirements will not be completely
known
until after the users have used it.
--- Humphrey's Requirements
Uncertainty Principle

52. An old-timer once told me that computer
science might have many fancy-pants data
structures, real-world software
development only has three:
stack, queue, and hashtable. :)
Chris Peterson (http://www.cpeterso.com

53. Software development is like building a house. You
can build a house in a few days...if your only going
to live there for say 48 hours you would say sure go
ahead and build it as fast as you can. On the other
hand if you want to live in that house for 20 years,
you probably want the contractor to take a little
more time, wouldn't you?
The point is we can build an application in a few
days or we can build an application in a few
months, which would you prefer?
- Joel Spolsky

54. “Adding manpower to a late software
project makes it later!”
Fred Brooks
Mythical Manmonth

55. “Any fool can write code that a computer
can understand. Good programmers write
code that humans can understand.”
Martin Fowler
In Refactoring: Improving the Design of
Existing Code

56. “It's OK to figure out murder mysteries, but
you shouldn't need to figure out code. You
should be able to read it.”
Steve McConnell
Author of ‘Code Complete’

57.  Why do we never have time to do it right,
but always have time to do it over?.