wrt Tech Mahindra a very senior engineer who used to work there told me that there have been so many layoffs there that, in some projects the Team Leads report straight to the VP. Newbies receive little to no training or guidance.
I was also skeptical till I noticed 2 huge deployments 1.Cafe Cofee Day is India's largest chain of cafes, sort of India's Starbucks. Their billing machines seem to be a custom Linux that boots into a console application (tastefully made)that's used for billing, taking orders at the counter, upload data etc. 2. Life Insurance Corporation (LIC) of India the country's largest Insurance company with thousands of branches has rolled out Linux desktops a couple of years back.
I would just like to add that in some cases linux can be better than windows at emulating old dos applications. I believe some large companies write application code based in the console because they stream the applications from some central server and not having a GUI puts less stress on the network, this is especially true for older companies. I worked at a call center for a while and we used multiple ancient dos applications running on windows xp to fill orders. The only other thing the desktops were used for was logging into your personal account and approving hours and looking at your schedule, which was done through some web app.
Thank you so much Doug. It has influenced me in so many ways and broadened my outlook Right now I'm reading John Markoff's "What the doormouse said", which is a fascinating account of the early days of silicon valley and how it was influenced by the sixties counter-culture. I decided to buy the book after hearing an interview with the author on Dr.Moira Gunn's program on itconversations.
They ship to a very large amount of places for free. My only complaint is that because it is shipping from another country it takes a while to get to you and you don't get any tracking codes from them.
Do not believe any programmer, manager, or salesperson who claims that code can be self-documenting or automatically documented. It ain't so. Good documentation includes background and decision information that cannot be derived from the code.
- Jef Raskin on self-documenting code
I find this kind of features is quite interesting, because API-doc is useful when you need a precise information ("I know there is a function for this, but what's the args order again ?"). When the only doc for a new project I am interested in is javadoc/doxygen, I usually run away.
As a reference, yes. I agree javadocs are little help for the big picture (or for the search problem of not knowing the term to look for).
However, it's much better than no documentation; and having it automatically derived makes it more likely to happen. It's much less work, and how much documentation would we have otherwise? Even if no explicit explanations are added, it's an improvement over nothing.
I think active docs, which you experiment with and see the behaviour as in the django story here, is even better again. (Although, there's little guidance and no explanation in these docs; and I got stack traces when I tried to add something.)
However, the big picture is what is missing - I wonder if there is a way to ease the documentation of this also? That shows the high-level interactions between things. I think part of the problem is that API docs show all the options, but often only 20% are used often, you can get by with even a smaller amount, and get something working with even less. That is, examples of concrete instances of API usage, not all the choices. For example, java.lang.String has a surprising number of methods, but most code doesn't use any of them (most code doesn't manipulate strings).
So, perhaps constraining docs in some way: maybe ranking methods by usage frequency; or designating examples, combining the used subsets of docs into one page. One might generalize this slightly, to show commonly used choices: this would give you the idea that this part is background that's always the same, and these parts are the foreground that changes. i.e. a grammar over the API, of common usage patterns.
This still wouldn't be perfect, but an improvement over purely reference docs; and making it much easier to produce would mean they'd be more of it.
An improvement over this would be game mechanics (I don't mean achievement unlocked BS, but a gradual learning curve, with feedback on how you are doing - puzzles, or active exercises IOW.
Programming by coincidence as the PragProg says (someone has already posted the link).It's extremely common here in most Indian companies, especially with freshers.
Also known as shotgun debugging, where you randomly poke at the relevant portion of the source code in the hope that the bug will magically vanish. I think the habit is formed early on, when most of the mistakes are things like syntax errors or off-by-one problems, where certain types of random tweaking actually can be somewhat effective.
pg seems to have said something alex'ish elsewhere:
"I once sat in a crowded hall and listened to Paul Graham give a keynote presentation about going big, doing it quickly, and getting tons of funding. During Q&A, someone asked what was wrong with instead of trying to go big with big money backers, you just went for profit and kept ownership to yourself and Graham said something like "you want to run a little business? Go run a shoe store then"
