Written Communication

I found the following in How To Ask Questions.

"Spell, punctuate, and capitalize correctly. Don't confuse “its” with “it's”, “loose” with “lose”, or “discrete” with “discreet”. Don't TYPE IN ALL CAPS; this is read as shouting and considered rude. (All-smalls is only slightly less annoying, as it's difficult to read. Alan Cox can get away with it, but you can't.)


More generally, if you write like a semi-literate boob you will very likely be ignored. So don't use instant-messaging shortcuts. Spelling "you" as "u" makes you look like a semi-literate boob to save two entire keystrokes. Worse: writing like a l33t script kiddie hax0r is the absolute kiss of death and guarantees you will receive nothing but stony silence (or, at best, a heaping helping of scorn and sarcasm) in return."

I found the link as a polite postscript to a response on a forum.

The article contains great advice from a uber hacker.

Dogfooding - at acmet's Tools BU

We built and RENOVATED compilers at the Tools BU.

But we never used them.

One of the other BUs did applications for the same customer for whom we had built - and were maintaining - a compiler. Unfortunately, the applications were for processors other than the target of the compiler.

We were not eating the dog-food we were making. If we had, our tools team would have been the better for it.

New Toys

Seth's post reminded me of something that I have seen quite often with software developers.

Software developers want to work on new projects. Given the choice between finishing a project and joining a new project, hardly anyone opts for the former. It is in the begining phases, when the product is still "plastic" , that work seems more like play. It is like being in kindergarten. But if all a person does is move from one begining  to another, the person will forever remain a beginner - no matter how many projects are put on the resume. The person will forever be in kindergarten.

It is only during the later phases, particularly the maintenance phase, that one gets to realize how things should have been done. That is when learning takes place. That is when one starts to become an expert. It takes time and reflection (hansei). There are no daily thrills. You do not get to play with new toys everyday. You have to study your old toy and learn how it should have been made. Then you can go and make better ones.

Documentation and Institution Building

MJ Akbar's article in yesterday's Times of India says, "Nehru and Patel wrote to each other when they sought to place a well-thought out policy position on record; they were, in a very real sense, creating precedence, administrative culture and an archive of an incubating government."

Nehru and Patel were part of a start-up. Their practice is worth emulating by other start-ups.

Hacker Culture & acmet's Tools BU

A few weeks ago GGanesh, sent me an email about what he considered were the strengths and weaknesses of acmet's tools BU. In that he mentioned:
"But an acmet thing which I remember most, is the way we encouraged getting the bad news early. We definitely had the hacker's attitude. We played with the code and got the bad news early."

Did we really have a hacker attitude? I wondered if I would ever have been comfortable working with a bunch of hackers.

GGanesh's mail led me to Paul Graham's essay on hackers.

One paragraph in the essay says:
"The latest intellectual property laws impose unprecedented restrictions on the sort of poking around that leads to new ideas. In the past, a competitor might use patents to prevent you from selling a copy of something they made, but they couldn't prevent you from taking one apart to see how it worked. The latest laws make this a crime. How are we to develop new technology if we can't study current technology to figure out how to improve it?"

If it is good for progress to look inside the competitor's product, should practices that facilitate poking around inside's one's own product not be instituted?  Poking around is reading (reviewing) code, poking values into variables while stepping through code, writing tests to see what breaks the code... Should not the product be constructed in a manner that makes future improvements easier? (The tag line for the Tools BU was "Software Maintenance as RENOVATION".)

So, yes I agree with GGanesh. And though the attitude was not strongly evident, it was getting stronger

Hindering Poking Around
This is my partial list of what hinders poking around.
* Inscrutable names of modules, functions, structures and data elements
* Prolific use of globals in the name of efficiency (a wolf in a sheep's clothes)
* Magic numbers
* Source code documentation that does not explain what sections of the code do and why it is required to be done, and what are the likely pitfalls.
* Undocumented pre-coditions and post-conditions
* Strong coupling between modules and weak cohesion within a module
* Cliques that discourage new generation of developers from getting to know the current code

Good Hackers
To make code easy to poke around, to bring up a new generation of developers, needs self-confidence and humility. Be critical of code, or ideas; not persons. I think most software companies would want such hackers. I definitely would have wanted more of them. That is the kind of hackers you want for a sustainable software process.

Teach Sparrows

I find it mentioned quite often that one must have great/good programmers.

Maybe in the US, with an educational system that allows for a great deal of flexibilty, with more opportunities to play around with computers at a very young age, with electronic hardware being a smaller fraction of the average household income (as compared to India), it may be possible to determine proggrammer suitability at induction.

Most Indian looking to become software professionals have not had these advantages. So looking for great programmers is not a viable course of action. What we have to look for is the desire to prove oneself; the fire in the belly. That was a belief of my late friend, and boss, RR (the late Wg Cdr R Raghavan). I do not remember him to have ever asked a single technical question of any inductee.

Many of the people whom we took in at acmet (and earlier at Ergo) could not make campus placement. I am sure I am not wrong when I say that, today, all are with the some of the best brands in the business of electronics and software. They had the desire to prove themselves acmet (and earlier Ergo) provided the opportunity.

Guru Gobind Singh, the tenth guru of the Sikhs, said, ""I will teach the sparrow to hunt the hawk" .(quoted from Khushwant Singh's article).

My friend RR taught sparrows.

Who Makes Product Specs?

Paul Graham in his essay on what happened to Yahoo says:

"I remember talking to some programmers in the cafeteria about the problem of gaming search results (now known as SEO), and they asked "what should we do?" Programmers at Yahoo wouldn't have asked that. Theirs was not to reason why; theirs was to build what product managers spec'd. "

Asking, "What should we do?" is not the same as, "Why is this required?" The programmers at Google were asking directions. They were not questioning the requirement.

The user requirement must come from the user. The product manager is the surrogate user.

But programmers too are users of software products. If they are building a search engine it should be one that they would willingly use. If the people making the dog food do not like it, neither will the dogs. And as far as finding out how the search engine could be misused, or gamed, the best inputs would come from programmers (if they are good programmers). In the absence of such converstaions what you have is a pin factory.

A good corporate culture would promote conversations between developers and users, or their surrogates. To get such a culture companies must select, and reward, persons who display this talent. Yahoo apparently did not.