The Obvious...

Its 23:36 hrs, almost close to midnight. I should be asleep in my bed but here i am writing this post. Since its getting kinda late - Here's the deal - Read the paragraph below and try to interpret what exactly does it describe. Trust me you already know the answer. So use some brain muscles and try to figure it out. Answer at the bottom of course (cheaters)...

"Two individuals proceeded towards the apex of a natural geologic protuberance, the purpose of their expedition being the procurement of a sample of fluid hydride of oxygen in a large vessel, the exact size of which was unspecified.

"One member of the team precipitously descended, sustaining severe damage to the upper cranial portion of his anatomical structure; subsequently, the second member of the team performed self-rotational translation, orientated in the same direction taken by the first team member."


















































































Answer:
Now i know most of you will not even stretch a single brain muscle to think and scroll down here
for the answer - which i will not tell, which is when you will turn to google where the answer will
be quiet obvious...so if you wanna know the answer comment on this post....GREs shame on you..

C Programming Completely Dereferenced.

Time for C programming !!. This section will highlight my experience with C (whatever)and of everyone around me and in the “Indian” context.

I’ve seen a concept called “Hand-running”. Now believe me this was some pathetic technique to run the C program on paper. I mean come on, people invest millions of dollars to create high end C compilers and here we are running the code on a piece paper!!!?? Seemed a pretty crappy job. Ok fine for beginners, but hello, for how long, not every program, come on!!. So the moral of the story: Time wasted in stupid hand running could have been invested in going down with the program on the computer, doing it more practically rather than too theoretically. This is the problem I will be highlighting all the way along: too much theory less practical = no-innovation & no discoveries & no product = pathetic service oriented industry.

Ok so now turning to them interview questions in C. I really don’t understand what the companies expect by giving haphazard questions. Now every question has a origin, it is the person who is ground-zero, the one who thought of the question and penned it down. Now I bet that fellow did not think out of the blue in a dream or something about the question it happened so because it was practical experience, the Q was framed after numerous trials on the computer to verify its validity. Now here the same Q is set in the placement papers and is supposed to be solved by the individual just by looking at it in them darn “What will be the output of the following program ? “ type questions. Now I do not object to such Q’s only that sometimes they are too crappy looking to be solved by hand without computer aid. And why should someone be given the task to write a program in 2 hrs without aid from whatever, when the person at ground-zero i.e the source of the Q, did in 3 or less hrs or so using full aid of Uncle Google or so.. This is a listing of a few “questions” you will most definitely come across (Ctrl + Ced):

a) What is the output of following code?

int i = 7;

printf( “%d”, i++ * i++ );

b) What would happen to the array after executing the following statements?

int a[5], i = 1;

a[i] = i++;

c) What is the value of i after the execution of the following statement?

int i = 7;

i = ++i;

Could have written more but running short of space… ;)

These idiotic questions are very often asked in Indian Programming world. The outputs are undefined. Even if such questions are asked, the right answer will be “the result is undefined”. For the above program, you may get some output. But it is wrong. You have to understand that compilers may not check ‘Undefined’ grammars...

So if you really want to get a good know-how of C, screw or get rid of Let Us C or whatever book you’ve got. The original book - The C Programming Lang. By Kernighan & Ritchie is the best. And for curious-kitties Advanced C by Peter D. Hipson is another awesome book, atleast I’ve used these for long and they rock……trust me ladies and gentlemen production C code looks more horrible than any other code u've ever seen and its written by someone else who is probably tanning on the beach in Hawaii whilst you sweat at office...

An Audience Classified ...

Ever been in a workshop, attended a conference with lots of people, lots of types of people, well then its time to classify such audiences.

The 4 P's of an audience:

P - One - Participants - The ones who have actually come of their own free will to gain some knowledge from the discussions.

(Typical dialog: Hey cool check it out....)

P - Two - Prisoners - The ones who have been forced to attend the conference by their superiors, and had / have no interest in the contents of the conference.

(Typical dialog: Arre yaar, ye kab khatam hoga...)

P - Three - Protesters - The highly acclaimed critic. Bring it on types challenging / criticizing everything told by the presenter. At times asking nasty irrelevant questions.

(Typical dialog: ...what are the advantages of such technology...won't it flop ... can i blink an LED with your multi-million dollar processor)

P - Four - Picnickers - The ones who are neutral, they have no idea what the conference is all about, they are here just for the free food during the break, usually accompany one of the types above ...

(Typical dialog: ....khaaneka time hogaya kya...aur kitnaa time baaki hai...)

So thats it ... next time you go such places, be ready to identify like a pro ... or
Which one have you been eh ?? :-P

:D

Dunning-Kruger Effect

This explains a lot.

The Dunning-Kruger effect describes the phenomenon whereby people who don’t know anything about something think they know more than those who do. The peculiar part is that those who lack the expertise are often far more confident and forceful when they discuss the issue than those who are knowledgeable.

This is because those who are knowledgeable know enough to know what they don’t know, whereas the pseudo-experts do not. The effect ends up being that the idiots with only partial knowledge come off as forceful and confident, while those who are more educated end up hesitating and appearing less versed on the topic.

Here are some main findings:

1. Incompetent individuals tend to overestimate their own level of skill.
2. Incompetent individuals fail to recognize genuine skill in others.
3. Incompetent individuals fail to recognize the extremity of their inadequacy.
4. If they can be trained to substantially improve their own skill level, these individuals can recognize and acknowledge their own previous lack of skill.

So the question for all of us is simple: how often have we been this guy? How many people do we know who are still this guy? And how do we avoid being this guy in the future? It’s issue when the public is watching two people debate in order to determine who is better qualified in a particular area.

The Project ...

The Project....

The first iteration: Partitioning

In 1946 programmers created software for the ENIAC machine by rewiring plug-boards. Two years later the University of Manchester ’ s Small-Scale Experimental Machine, nicknamed Baby, implemented von Neumann ’ s stored program concept, for the first time supporting a machine language. Assembly language soon became available and flourished. But in 1957 Fortran, the first high level language, debuted and forever changed the nature of programming.

In the 50 years since programming fi rst appeared, software engineering has morphed to something that would be utterly alien to the software developer of 1946. That halfcentury has taught us a few pivotal lessons about building programs. Pundits might argue that the most important might be the elimination of “ gotos, ” the use of objects, or building from patterns.

They ’ d be wrong. The fundamental insight of software engineering is to keep things small. Break big problems into little ones. For instance, we understand beyond a shadow of a doubt the need to minimize function sizes. No one is smart enough to understand, debug, and maintain a 1000-line routine, at least not in an effi cient manner. Consequently, we ’ ve learned to limit our functions to around 50 lines of code. Reams of data prove that restricting functions to a page of code or less reduces bug rates and increases productivity.

But why is partitioning so important?
A person ’ s short-term memory is rather like cache—a tiny cache—actually, one that can hold only 5–9 things before new data flushes the old. Big functions blow the programmer ’ s mental cache. The programmer can no longer totally understand the code; errors proliferate.

The Second Iteration: Productivity Crash

But there ’ s a more insidious problem. Developers working on large systems and subsystems are much less productive than those building tiny applications.

Programmer productivity plummets by an order of magnitude as projects grow in scope! That is, of course, exactly the opposite of what the boss is demanding, usually quite loudly. The growth in communications channels between team members sinks productivity on large projects. A small application, one built entirely by a single developer, requires zero comm channels—it ’ s all in the solo guru ’ s head. Two engineers need only one channel.

The number of communications channels between n engineers is:

n(n-1) / 2

This means that communications among team members grow at a rate similar to the square of the number of developers. Add more people and pretty soon their days are completely consumed with email, reports, meetings, and memos.

Interruptions kill software productivity. Other work has shown it takes the typical developer 15 minutes to get into a state of “ flow, ” where furiously typing fingers create a wide-bandwidth link between the programmer ’ s brain and the computer. Disturb that concentration via an interruption and the link fails. It takes 15 minutes to rebuild that link but, on average, developers are interrupted every 11 minutes. Interrupts are the scourge of big projects.

(click on the image)

A maxim of software engineering is that functions should be strongly cohesive but only weakly coupled. Development teams invariably act in the opposite manner. The large number of communications channels makes the entire group highly coupled. Project knowledge is distributed in many brains. Joe needs information about an API call. Mary is stuck finding a bug in the interface with Bob ’ s driver. Each jumps up and disturbs a concentrating team member, destroying that person ’ s productivity.

Coming up.....
The project in "Embedded Mode" ...

Referenced from:
The Art of Designing Embedded Systems
By Jack Ganssle