A Thinker's Duty
- • A thinker has to be able to demonstrate that his artifact has the required properties. If this comes as an afterthought, it is certain that he can't meet this obligation. He should allow this obligation to influence his design. Posteriori verification puts the cart before the horse. As long as "development" and "quality assurance" are done by different teams, we get software without warranty.
- • Effective reasoning is simple and pretty straightforward. They need to be mastered with formal methods. Otherwise, we end up with a software crisis attracting charlatans in the form of software engineering and design pattern gurus, expert consultants, etc.
- • Factoring helps in constructive analysis, not reductive analysis. In the constructive phase, factoring the code helps in linearizing the ratio of length of code derivation to length of codes derived.
- • The problem with software business is there are many companies for which it is not clear that computer science can help them; their snubness may make computer science not try either.
- • The symbols we denote, the formalisms we use, shape us. A programming language is not worth learning if it doesn't change the way you see the world.
- • It is not the job of Computer Science to promote computerizations. It should stop producing demanding applications just to create a market for next gen hardware.
- • Being a creator, it is the job of a programmer to create a world of artefacts in which sound programming techniques are applicable. It is his only way to create a high quality design.
- • There is a dearth of simple proofs and terse programs. This is partly due to the politically correct pedagogical obsession for "the student's need to demonstrate a strong evidence of research potential in collegiate level maths and computer science education". It mostly attracts students to an unteachable form of math and comp. sci. research. The attraction to simplicity must be restored.
- • Science is not a social activity. User satisfaction is not the primary quality criterion for a software application. A philosophy of comp. sci. exists and it is intuitive, not calculational.
- • Software industry is only interested in a docile workforce and undemanding customers hooked on their bloated products. Academia offers high quality products to which most industrial products never match up. Industry is seldom interested in an educated workforce or an educated customer base. This divide has to narrow down.
- • West and the East approach comp. sci. differently. The East is more mathematical, more qualitative, not very machine oriented and not necessarily linked to application areas. The "how" is more pronounced in the West com. sci. thought, whereas "why" dominates in the East.
- • Attaining simplicity in a systematic manner is still an unsolved problem. A mathematical formulation for the complexity of interfaces between components of proofs and other discrete systems in lower bounds is still missing.
- • Tools training is masquerading as CS education mainly in India. Many training institutes have sprung up to train how to get some useful work done using a bunch of industrial software tools. Just because these products are made on a large scale does not mean they are sacrosanct. And just because these training institutes list the names of "celebrity" lecturers of this "education" circus does not mean they are not selling superficial fluff that isn't even worthy of printing.
- • Remember that all unfathomed depth of a thinker is already at play in the process of communication -- written or verbal.
- • Knowledge, insights and habits are transferred only by imitation, not by teaching.
- • If a function needs more than nine words, you are on the wrong track.
- • Come to grips with a large set of uncertainties by looking at a few; go immediately for the general case instead of a delayed assessment of a specific case.
- • Never resort to a pen/pencil and paper/diary combo. If you are writing what you are told, you tend to forget. People write to remember. Thinkers write to forget. Postponing writing forces you to explore the simple solutions first.
- • Don't deal with more than two things simultaneously. Multitasking is slow poison.
- • Because you need to take responsibility for large projects, which require management, you should know how to manage a project in its environment. Such an environment is regulated by schedules and budgets. Organizations are built around such environments. Laws of management science will be shoved down your throat by excellence seekers. Go with the ordering principle instead.
- • Programming's mathematical novelty is mainly centered around a hundred heuristics. Do not abandon such aphoristic approach to problem solving.
- • The only difference between mathematics and computer science is that the latter pays for every "if" case. Mind this gap.
- • A programming language's claims that it becomes easier, faster, reliable, less prone to errors, etc. speaks more about the programmer than the language. It is wiser to not make such claims and show methodological findings.
- • Never fall into the trap of having to worry about what fraction of the task responsibility that should be assigned to a programmer in order to keep him sufficiently involved and motivated to perform satisfactorily over months or years. It is your job to define the excellence metric, not seek it.
- • Small changes and small effects never go hand in hand
- • Always estimate time in terms of "at most". Always estimate effort in terms of "less than".
- • Creating value for companies by creating value for people is a roundabout way of valuing companies.
- • An average computer scientist faces two major professional concerns, the isolation of which seem often neglected:
- General acceptance of his artefact: "Nothing becomes true until a thousand people believe it."
- Concern for correctness and desirability of his artefact: "Your approach is wonderful, but it may be theoretical in a world of imperfection and partial information". The best action is to wait for the world to catch-up. Albert Einstein didn't fail because Theory of Relativity is difficult to understand.
- • If you are generally uneasy as to whether what you are doing really makes sense, sit down and formalize it. Prove that your approach works on paper. It is a form of intellectual hygiene.
- • Only silly people follow silly advice. 80% of the problems are trivial and 20% are unsolvable. The search for 80% triviality is an arduous task.
- • Systems people are hard to get, impossible to satisfy, scientifically dubious and hard to retain. There are practical people, then there are theoretical people. Systems people regard themselves as non-impractical and non-theoretical. Who the hell are they?
- • Be guided by necessity and not get subsumed by mediocrity that is an overwhelming phenomenon of systematic disqualification of competence in organizations.
- • Never belabour the obvious
- • The problem with likelihood reasoning is its lack of mathematical rigour. Never treat the same entities sometimes as logical expressions and sometimes as half-truths. Be careful when modeling expert systems.