Been listening to a couple of inspirational songs that need a special mention.
1) Umeed-e-Sahar (Artists: Laal)
Link: http://www.youtube.com/watch?v=OjaNQFChkCY&feature=fvst
Lyrics: English subtitles
2) Aik Alif (Artists: Noori ft Saaein Zahoor)
Link: http://www.cokestudio.com.pk/episodes/episode01/aik-alif/
Lyrics: Couldn't find the proper lyrics to this one anywhere on the net, so figured them out (with alot of help, of course)!
[Saaein Zahoor] Wooooo...
[Saaein Zahoor] Oooooooooooooo...
[Saaein Zahoor] Oooooooooooooo...
[Saaein Zahoor] Parh parh alim te fazil hoyo...
[Saaein Zahoor] Te kade apne aap nu parya naii...
[Saaein Zahoor] Bajh bajh varnaye mandar-e-maseet e...
[Saaein Zahoor] Te kadi mann apne vich varya naai...
[Saaein Zahoor] Larna roooz...Shaitaan de naal
[Saaein Zahoor] Te kaday nafs apnay naal larya naai...
[Saaein Zahoor] Bulley Shah, asmaani udhiyaan pharo...naai...
[Saaein Zahoor] Ve jera ghar betha, unhun pharayao naa...
[Saaein Zahoor] Bas karee Oh yaar...ilmnu
[Saaein Zahoor] Bas karee Oh yaar
[Saaein Zahoor] Bas karee Oh yaar...ilmnu
[Saaein Zahoor] Bas karee Oh yaar
[Saaein Zahoor] Aik alif tere-o darkaar...
[Saaein Zahoor] Aik alif tere-o darkaar...haq
[Saaein Zahoor] Bas karee Oh yaar...ilmnu
[Saaein Zahoor] Bas karee Oh yaar
[Hymn] Allah Saieenya X 5
[Ali Noor] Niiiii...mein
[Ali Noor] Jaana...
[Ali Noor] Nii mein jaana...
[Ali Noor] Jaana...
[Ali Noor] Jogi de naal
[Ali Noor] Ho, Ni mein jana
[Ali Noor] Ni mein jaan...
[Ali Noor] Jogi...de naal...
[Ali Noor] Ni mein jana...
[Ali Noor] Jogi de...naal...
[Ali Hamza] Jo naa janay...
[Ali Hamza] Haq ki...taqat
[Ali Hamza] Jo na janay...haq ki taaqat
[Ali Hamza] Jo na janay...haq ki taaqat
[Ali Hamza] Rab na deway...us ko himmat
[Ali Hamza] Rab na deway...us ko himmat
[Ali Hamza] Hum mann ke darya mein doobay
[Ali Hamza] Hum mann ke darya mein doobay
[Ali Hamza] Kaisi naiyya, kya manjhdar...haq
[Ali Hamza] Bas karee Oh yaar...ilmnu
[Ali Hamza] Bas karee Oh yaar
[Ali Hamza] Bas karee Oh yaar...ilmnu
[Ali Hamza] Bas karee Oh yaar
[Hymn] Allah Saieenya X 5
[Saaein Zahoor] Allah...
[Saaein Zahoor] Allah...
[Saaein Zahoor] Allah...
[Saaein Zahoor] Saaeinya...
[Hymn] Allah Saieenya X 5
Both these songs are amaaaaazingly inspirational; tried translating the second one to English for the non-punjabi speakers but I couldn't do justice to the original poetry. I'd appreciate if someone can contribute something that conveys the soul of the message. Hope you have as much fun as I do listening to these all day :)
Wednesday, 17 June 2009
Thursday, 29 January 2009
Ten Commandments for Good Programming
Know more than you “need” to know.
Knowing a programming language and being able to program in it is not enough. In today's IT industry it is hardly enough to qualify you for doing a few loose projects at home.
You are working on a computer, that computer has both hardware and software components. You need to have a working knowledge and understanding of both. It is highly unlikely that you'll be working on a stand-alone computer, so you also need to know at least the basics of networking.
So, when will you know enough? The answer is simple...NEVER!
Learn at least one new thing every day!
Every successful programmer I've ever met, has made learning new things on a daily basis an art form.
The IT industry moves at a ridiculous pace, make peace with the fact that you will never catch up with the current scene of all the available technologies. Be aware of the fact, that if you do not learn new things regularly, you will be useless outside your current place of work within 18 months.
Getting it to work is NOT ENOUGH!
Take pride in what you do. Honestly, just because you finally got your program working, does not mean it is done. Clean up your code, comment it where needed and test the damn thing thoroughly.
Consider those that come after you.
Think of the guy that has to maintain your code, as a homicidal psychopath, that knows where you live. Write your code in a way that would make sure he never gets the urge to seek you out.
Too many programmers write their code in a way understandable to nobody other than themselves and the compiler or translator they happen to be using at the time. Don't be one of them and when you find one, bang them over the head with a clue-bat.
Download some source code from a reputable open source project and look at it, compare what you produce to it and you'll quickly find where you can improve.
Document what you do.
With applications like Javadoc and doxygen, there are no more excuses.
If you don't document your applications you can not, by the biggest stretch of imagination, call yourself a programmer. At best, you are a glorified typist.
Follow, respect and take responsibility for the development process.
The development process from requirement gathering, through testing, deployment and maintenance has been developed by those you are now learning from. They had to learn it from the school of hard knocks.
Respect this experience and use their knowledge.
So when exactly are you done? Only once the application is deployed, running and requires no more changes, can you say you are done. Before you reach that point, you can not factually state that you have finished your work.
Respect your peers.
Throughout your career you will be working with many other programmers, developers, software engineers etc. etc. etc. You might reach a point where you are factually the most experienced or trained individual on a team. This is when you need to be doubly careful. Do not allow yourself to become arrogant.
In years gone by, it was possible for a single programmer to see to an employers needs. Now, you'll have to learn how to work with others. Nobody likes an arrogant SOB, no matter how good he is. This will eventually lead to that individual's downfall.
The IT industry is one of the few where a good reputation can get you far beyond the level of your formal education. A bad reputation on the other hand, will see you getting stuck at the bottom of the pile, regardless of how many degrees or certificates you spam your CV with.
Respect the user.
Yes, there will be times when you think the user is the most irritating, uneducated, short-sighted being produced by this universe, for the sole purpose of making your life hell.
I've found, that when you respect the user, listen to their opinions and grievances while taking action to improve their lives, you invariably end up with someone, that will listen to you and take your advice.
Over the short term, this could take a lot of work and effort. But over the span of a career, those users are the best references you can possibly gather. They are the ones that will tell your future employer, that they are absolutely devastated at seeing you leave and that they don't understand why your current employer can't make a plan to keep you.
Demand the best of yourself.
Do what you have to, check it, improve it, check it again, read some relevant material on what you have to do, check it again, test it to death, clean up your code, test it again, do your documentation and... test it again.
Even after you have done this, you can be sure there is at least one more thing to do. Find it and do it. Do all of the above to the best of your ability.
Demand the best from your peers.
You will never survive if you are the only one doing all the things needed in order to make sure your product is a good one.
Your peers share responsibility with you, if they are not doing their best it will come back to bite you when you least expect it. Do not tolerate incompetence, but also help and educate where needed.
Source: http://www.bothaclan.co.za/?q=node/1
Knowing a programming language and being able to program in it is not enough. In today's IT industry it is hardly enough to qualify you for doing a few loose projects at home.
You are working on a computer, that computer has both hardware and software components. You need to have a working knowledge and understanding of both. It is highly unlikely that you'll be working on a stand-alone computer, so you also need to know at least the basics of networking.
So, when will you know enough? The answer is simple...NEVER!
Learn at least one new thing every day!
Every successful programmer I've ever met, has made learning new things on a daily basis an art form.
The IT industry moves at a ridiculous pace, make peace with the fact that you will never catch up with the current scene of all the available technologies. Be aware of the fact, that if you do not learn new things regularly, you will be useless outside your current place of work within 18 months.
Getting it to work is NOT ENOUGH!
Take pride in what you do. Honestly, just because you finally got your program working, does not mean it is done. Clean up your code, comment it where needed and test the damn thing thoroughly.
Consider those that come after you.
Think of the guy that has to maintain your code, as a homicidal psychopath, that knows where you live. Write your code in a way that would make sure he never gets the urge to seek you out.
Too many programmers write their code in a way understandable to nobody other than themselves and the compiler or translator they happen to be using at the time. Don't be one of them and when you find one, bang them over the head with a clue-bat.
Download some source code from a reputable open source project and look at it, compare what you produce to it and you'll quickly find where you can improve.
Document what you do.
With applications like Javadoc and doxygen, there are no more excuses.
If you don't document your applications you can not, by the biggest stretch of imagination, call yourself a programmer. At best, you are a glorified typist.
Follow, respect and take responsibility for the development process.
The development process from requirement gathering, through testing, deployment and maintenance has been developed by those you are now learning from. They had to learn it from the school of hard knocks.
Respect this experience and use their knowledge.
So when exactly are you done? Only once the application is deployed, running and requires no more changes, can you say you are done. Before you reach that point, you can not factually state that you have finished your work.
Respect your peers.
Throughout your career you will be working with many other programmers, developers, software engineers etc. etc. etc. You might reach a point where you are factually the most experienced or trained individual on a team. This is when you need to be doubly careful. Do not allow yourself to become arrogant.
In years gone by, it was possible for a single programmer to see to an employers needs. Now, you'll have to learn how to work with others. Nobody likes an arrogant SOB, no matter how good he is. This will eventually lead to that individual's downfall.
The IT industry is one of the few where a good reputation can get you far beyond the level of your formal education. A bad reputation on the other hand, will see you getting stuck at the bottom of the pile, regardless of how many degrees or certificates you spam your CV with.
Respect the user.
Yes, there will be times when you think the user is the most irritating, uneducated, short-sighted being produced by this universe, for the sole purpose of making your life hell.
I've found, that when you respect the user, listen to their opinions and grievances while taking action to improve their lives, you invariably end up with someone, that will listen to you and take your advice.
Over the short term, this could take a lot of work and effort. But over the span of a career, those users are the best references you can possibly gather. They are the ones that will tell your future employer, that they are absolutely devastated at seeing you leave and that they don't understand why your current employer can't make a plan to keep you.
Demand the best of yourself.
Do what you have to, check it, improve it, check it again, read some relevant material on what you have to do, check it again, test it to death, clean up your code, test it again, do your documentation and... test it again.
Even after you have done this, you can be sure there is at least one more thing to do. Find it and do it. Do all of the above to the best of your ability.
Demand the best from your peers.
You will never survive if you are the only one doing all the things needed in order to make sure your product is a good one.
Your peers share responsibility with you, if they are not doing their best it will come back to bite you when you least expect it. Do not tolerate incompetence, but also help and educate where needed.
Source: http://www.bothaclan.co.za/?q=node/1
Ten Commandments for Curing Bad Programming Habits
Thou shalt really understand the requirements driving your work (not make them up or not bother to read them and/or not ask questions when necessary)
Thou shalt deliver what the customer needs (not that which is easy to implement)
Thou shalt not just comment out code because it causes the test to fail (without understanding why it was there in the first place)
Thou shalt understand the implications of thy work with respect to others on the team
Thou shalt understand the implications of thy work with respect to other areas of the system as a whole
Thou shalt not regard communicating with other members of the team as an unnecessary and tiresome overhead that can be ignored
Thou shalt not deviate from the "agreed" development approach without a good reason that has been thought about
Thou shalt understand that the external image of the development team is important (even though it does not contribute to your daily work)
Thou shalt understand that sometimes thou must do things because they are important to other people's jobs (thou art not the only person in the universe)
Thou shalt understand that getting the software out there, so others can see something has actually been done, is important (we're not just doing this as an intellectual exercise)
Source: http://ww.softwarereality.com/soapbox/commandments.jsp
Thou shalt deliver what the customer needs (not that which is easy to implement)
Thou shalt not just comment out code because it causes the test to fail (without understanding why it was there in the first place)
Thou shalt understand the implications of thy work with respect to others on the team
Thou shalt understand the implications of thy work with respect to other areas of the system as a whole
Thou shalt not regard communicating with other members of the team as an unnecessary and tiresome overhead that can be ignored
Thou shalt not deviate from the "agreed" development approach without a good reason that has been thought about
Thou shalt understand that the external image of the development team is important (even though it does not contribute to your daily work)
Thou shalt understand that sometimes thou must do things because they are important to other people's jobs (thou art not the only person in the universe)
Thou shalt understand that getting the software out there, so others can see something has actually been done, is important (we're not just doing this as an intellectual exercise)
Source: http://ww.softwarereality.com/soapbox/commandments.jsp
Wednesday, 28 January 2009
Ten Commandments for Ego Free Programming
Understand and accept that you will make mistakes
The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
You are not your code
Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
No matter how much "karate" you know, someone else will always know more
Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
Don't rewrite code without consultation
There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
Treat people who know less than you with respect, deference, and patience
Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
The only constant in the world is change
Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
The only true authority stems from knowledge, not from position
Knowledge engenders authority, and authority engenders respect -- so if you want respect in an egoless environment, cultivate knowledge.
Fight for what you believe, but gracefully accept defeat
Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
Don't be "the guy in the room."
Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
Critique code instead of people - be kind to the coder, not to the code
As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.
Source: The Psychology of Computer Programming by Jerry Weinberg
The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
You are not your code
Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
No matter how much "karate" you know, someone else will always know more
Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
Don't rewrite code without consultation
There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
Treat people who know less than you with respect, deference, and patience
Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
The only constant in the world is change
Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
The only true authority stems from knowledge, not from position
Knowledge engenders authority, and authority engenders respect -- so if you want respect in an egoless environment, cultivate knowledge.
Fight for what you believe, but gracefully accept defeat
Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
Don't be "the guy in the room."
Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
Critique code instead of people - be kind to the coder, not to the code
As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.
Source: The Psychology of Computer Programming by Jerry Weinberg
Ten Commandments for Stress Free Programming
Thou shalt not worry about bugs
Bugs in your software are actually special features.
Thou shalt not fix abort conditions
Your user has a better chance of winning state lottery than getting the same abort again.
Thou shalt not handle errors
Error handing was meant for error prone people, neither you nor your users are error prone.
Thou shalt not restrict users
Don't do any editing, let the user input anything, anywhere, anytime. That is being very user friendly.
Thou shalt not optimize
Your users are very thankful to get the information, they don't worry about speed and efficiency.
Thou shalt not provide help
If your users can not figure out themselves how to use your software than they are too dumb to deserve the benefits of your software anyway.
Thou shalt not document
Documentation only comes in handy for making future modifications. You made the software perfect the first time, it will never need modifications.
Thou shalt not hurry
Only the cute and the mighty should get the program by deadline.
Thou shalt not revise
Your interpretation of specs was right, you know the users' requirements better than they do.
Thou shalt not share
If other programmers needed some of your code, they should have written it themselves
Source: Email Forward
Bugs in your software are actually special features.
Thou shalt not fix abort conditions
Your user has a better chance of winning state lottery than getting the same abort again.
Thou shalt not handle errors
Error handing was meant for error prone people, neither you nor your users are error prone.
Thou shalt not restrict users
Don't do any editing, let the user input anything, anywhere, anytime. That is being very user friendly.
Thou shalt not optimize
Your users are very thankful to get the information, they don't worry about speed and efficiency.
Thou shalt not provide help
If your users can not figure out themselves how to use your software than they are too dumb to deserve the benefits of your software anyway.
Thou shalt not document
Documentation only comes in handy for making future modifications. You made the software perfect the first time, it will never need modifications.
Thou shalt not hurry
Only the cute and the mighty should get the program by deadline.
Thou shalt not revise
Your interpretation of specs was right, you know the users' requirements better than they do.
Thou shalt not share
If other programmers needed some of your code, they should have written it themselves
Source: Email Forward
Sunday, 4 January 2009
The Odds of Dying
Tuesday, 16 December 2008
Driver Installation Sequence [OS: WIndows]
1) Desktop/Notebook System Software
Contains special patches, updates and fixes to the raw operating system, so, if available, should be the first thing to be installed.
2) Chipset Drivers
Contains drivers for motherboard components and controllers. Storage (IDE/ATA/SATA) drivers, USB support drivers/updates and PCMCIA/Smartcard controller drivers also fall within this category.
3) Modem Drivers
Drivers for your dial-up modem. Allows you to connect to the internet over your modem.
4) Audio Drivers
Drivers for your audio device. Enables/enhances system sound.
5) Video/Graphics Drivers
Drivers for your graphics card. Enhances your system's graphics capability.
6) Network Drivers
Enabless the NIC for network access. Allows you to connect to a LAN.
7) Wireless Drivers
Enables your wireless network card to function properly. Allows you to connect to wireless networks.
8) Bluetooth Drivers
Enables your system's bluetooth hardware. Allows you to connect with other bluetooth devices.
Contains special patches, updates and fixes to the raw operating system, so, if available, should be the first thing to be installed.
2) Chipset Drivers
Contains drivers for motherboard components and controllers. Storage (IDE/ATA/SATA) drivers, USB support drivers/updates and PCMCIA/Smartcard controller drivers also fall within this category.
3) Modem Drivers
Drivers for your dial-up modem. Allows you to connect to the internet over your modem.
4) Audio Drivers
Drivers for your audio device. Enables/enhances system sound.
5) Video/Graphics Drivers
Drivers for your graphics card. Enhances your system's graphics capability.
6) Network Drivers
Enabless the NIC for network access. Allows you to connect to a LAN.
7) Wireless Drivers
Enables your wireless network card to function properly. Allows you to connect to wireless networks.
8) Bluetooth Drivers
Enables your system's bluetooth hardware. Allows you to connect with other bluetooth devices.
Monday, 8 December 2008
Which Trait from Which Parent?
I recently got a bit curious as to what trait of mine I had received from which parent, so, I did some looking around in genetics and biology and found out that the answer wasn't as simple as x items in the "Dad" column and y in the "Mom" column.
Apparently, all organisms can be classified into prokaryotes (organisms lacking a cell nucleus or membrane-bound organelles) and eukaryotes (organisms with complex structured membraned cells containing complex membraned organelles like nuclii, mitochondria and chloroplast). Bacteria are commonly known prokaryotes while animals and plants are the most notable eukaryotes. The nucleus in every cell of a eukaryote is responsible for carrying the genetic material or DNA of the organism, while in case of prokaryotes, this material is just roaming around in the nucleoid of the cell almost free.
Coming back to eukaryotes and more specifically, humans, every human nucleus has 46 chromosomes which actually carry the tightly bound DNA. 44 of these chromosomes are autosomes (or chromosomes that handle characteristics other than the gender) and 2 allosomes (or heterosomes or sex chromosomes or the highly famous X and Y chromosomes that are responsible for gender determination). Men have XY allosomes while women have XX; since during reproduction, the female will always donate an X allosome, gender of the baby is always determined by whether it receives an X or a Y from dad.
Now, these normal eukaryotic cells containing 46 chromosomes containing DNA undergo gametogenesis (spermatogenesis or oogenesis) in the gonads to make the gametes (sperms or eggs). When they fuse to form a zygote, the zygote gets one set of chromosomes from each gamete during cell fusion, and then goes on to become and embryo and so on and so forth...
This is where Mendelian Segregation comes in; each gamete gets only 23 of the chromosomes (or one allele) of it's parent cell while it's brother gets the remaining 23 (or the second allele). So, every 23 chromosomed human gamete is chosen randomly from 23 pairs of parent chromosomes (or 8388608 possible combinations). Now, Mendelian Independent Assortment has it that when two haploid (or 23 chromosomed) gametes are fusing to form a diploid (or 46 chromosomed) zygote, they do so randomly and then there's chromosomal crossover that adds even more to the randomness of the whole thing.
So, the obvious answer to my question is, it's all random; you could be getting some characteristic from your mother, some from your father, some from your grand-father, and maybe even some from your great great great grandfather, it all depends on what share of random you got in your final zygote form and which genes in those 46 pairs of chromosomes turned out to be the dominant ones :P
Apparently, all organisms can be classified into prokaryotes (organisms lacking a cell nucleus or membrane-bound organelles) and eukaryotes (organisms with complex structured membraned cells containing complex membraned organelles like nuclii, mitochondria and chloroplast). Bacteria are commonly known prokaryotes while animals and plants are the most notable eukaryotes. The nucleus in every cell of a eukaryote is responsible for carrying the genetic material or DNA of the organism, while in case of prokaryotes, this material is just roaming around in the nucleoid of the cell almost free.
Coming back to eukaryotes and more specifically, humans, every human nucleus has 46 chromosomes which actually carry the tightly bound DNA. 44 of these chromosomes are autosomes (or chromosomes that handle characteristics other than the gender) and 2 allosomes (or heterosomes or sex chromosomes or the highly famous X and Y chromosomes that are responsible for gender determination). Men have XY allosomes while women have XX; since during reproduction, the female will always donate an X allosome, gender of the baby is always determined by whether it receives an X or a Y from dad.
Now, these normal eukaryotic cells containing 46 chromosomes containing DNA undergo gametogenesis (spermatogenesis or oogenesis) in the gonads to make the gametes (sperms or eggs). When they fuse to form a zygote, the zygote gets one set of chromosomes from each gamete during cell fusion, and then goes on to become and embryo and so on and so forth...
This is where Mendelian Segregation comes in; each gamete gets only 23 of the chromosomes (or one allele) of it's parent cell while it's brother gets the remaining 23 (or the second allele). So, every 23 chromosomed human gamete is chosen randomly from 23 pairs of parent chromosomes (or 8388608 possible combinations). Now, Mendelian Independent Assortment has it that when two haploid (or 23 chromosomed) gametes are fusing to form a diploid (or 46 chromosomed) zygote, they do so randomly and then there's chromosomal crossover that adds even more to the randomness of the whole thing.
So, the obvious answer to my question is, it's all random; you could be getting some characteristic from your mother, some from your father, some from your grand-father, and maybe even some from your great great great grandfather, it all depends on what share of random you got in your final zygote form and which genes in those 46 pairs of chromosomes turned out to be the dominant ones :P
Tuesday, 11 November 2008
My GRE Experience - The Entire Walkthrough
Well, the GRE is an entirely different ball game compared to the IELTS/TOEFL. If you've read my IELTS blog post, you'll probably know that you can get a decent score there even if you haven't prepared quite diligently. The GRE, unfortunately, pays no heed to diligence or persistent hard work. It's more a test of an over-functioning vocabulary, mathematical acuity and most importantly, keen time management. In order of priority, the three things that need to be sharp as a scalpel are:
1. Time Management
2. Vocabulary
3. (Extensive) Mathematics Practice
I decided to put in about 2.5 to 3 months into the Barron's GRE book, since Barron's helped me achieve a decent score the first time around in my SAT's. About two thirds of these 90 days went into roting the 3500 words on the Barron's GRE Word's List. I went at a rate of about a word-list a day and devoting a good 50 odd days to the vocabulary. Once I had the basics covered I moved on to the real prep. My schedule was something like:
1. Time Management
2. Vocabulary
3. (Extensive) Mathematics Practice
I decided to put in about 2.5 to 3 months into the Barron's GRE book, since Barron's helped me achieve a decent score the first time around in my SAT's. About two thirds of these 90 days went into roting the 3500 words on the Barron's GRE Word's List. I went at a rate of about a word-list a day and devoting a good 50 odd days to the vocabulary. Once I had the basics covered I moved on to the real prep. My schedule was something like:
I was, of course, going through the general tips in each section and completing all the exercise questions that followed. My average scores for the section/chapter are in the parenthesis. I assumed that to be thorough enough prep at the time. Once the verbal section was catered to, I turned towards the quantitative section.
I had been reviewing my vocabulary throughout; reading up on a plethora of novels, frequently testing myself on freerice.com (and scoring consistently above level 45 out of 60). Anyways, pleased with my quantitative preparation, I started one final revision before getting into practice exams.
Generally good scores on the practice exams, a good vocabulary rating from freerice, comprehensive verbal preparation and a 3 time review of maths left me with quite an air of confidence. I was beaming the day I reached the test site to take my exam.
.::GRE Day::.
The air of confidence shattered, I flunked one of the most important exams of my life; scored a meager 1210 (Q670 V540) out of 1600. I had the bad luck of getting 4-5 questions in my quantitative section from the same topic that were completely alien to me, and I suspected the analogies to be the culprit in the verbal section; nevertheless, I flunked and flunked real bad.
I’d scored much better than this in my SAT’s with less than 15 days of prep, so, I really couldn’t comprehend the fact that I had messed up my GRE with 3 months of prep. This fact settled in a good 3-4 hours after I got my score. So, I decided to retake the exam on the simple grounds that I had worked too hard to leave with a lousy 1210.
Got home, googled up bad GRE scores, and eventually stumbled on this chap's comments who had coincidentally scored a 1210 on his GRE on the first attempt. According to his comments, he'd gone through an almost identical regimen of Barron's as I had and ended up with a result identical to mine as well. His opinion was that ETS had upped the complexity level of the questions in the GRE the previous year and an update in preparation material was needed to fetch the coveted 1500 or more. He recommended adding GRE Bible and Arco to the preparation plan, along-with excessive timed practice tests. The guy claimed a score of 1560 on his GRE retake so I took his advice :P Here's an abstract of the time table I followed for my re-prep:
My focus during this time was definitely elevated compared to my previous prep and it's a fact that is shown by the increased percentage in practice questions as well as a much more thorough and extensive preparation timeline. After the preparation, I spent almost 10 days on only taking practice tests in timed environments to narrow in on my weaknesses. Here’s my practice test schedule.
Analogies were, evidently, the recurrent weakness in an otherwise extensive preparation. I found that I was messing up badly on the Reading Comprehension questions sometimes as well. On the quantitative section, the data interpretation questions seemed to be causing problems. In both sections, I was prone to making careless mistakes in a hurried attempt to move on to the next question. By the time I had taken about 20 of these timed practice tests, I had fine tuned my time management/guessing and addressed the problems I was facing before. I entered the GRE Retake phase with an overall sanguinity.
.::GRE Day::.
Desired Score: 1500/1600 (Q800 V700)
Probable Score: 1390/1600 (Q710 V680)
Actual GRE Re-take Score: 1450/1600 (Q790 V660)
Prep Material Used:
• Books
o Barron’s GRE Test Book 15th and 17th Editions (not much of a difference btw)
o Kaplan’s GRE Verbal Workbook
o GRE Secrets (special thanks to my friend, Farhan Mughal)
• Software
o GRE Bible 2.1 (special thanks to the Indian electronics/comm. engineer)
o ETS Power Prep 3.1
o Amit Shrestha’s Vocabulary Builder 1.33
• Websites
o www.freerice.com
Lessons Learned:
Key Lesson 1 – Update your prep material: The ETS people aren't idiots. Expect updated content on your test no matter when you are going to take it. The conventional method of prep has no guarantee of getting you the same good scores your seniors at university or elder bro or sis got. So, size up your GRE accurately before starting preparing for it.
Key Lesson 2 – Learn to manage your time effectively: Knowing the vocabulary list and having sharpened maths skills is not going to get you a good score. Time management is the most pivotal aspect tested.
Key Lesson 3 – Practice, practice, practice: Once the vocabulary and maths is handled, never-ending practice tests will guarantee that you get used to the GRE pattern enough to manage your time well and go through the exam calmly. Moreover, it's an excellent ground for testing and tweaking your GRE strategies. The significance of this cannot be stressed enough.
Hope this helps! Best of luck with your GRE's :)
Monday, 27 October 2008
My IELTS Experience - Quick Hints & Tips
Every exam buries it's own set of apprehensions in your mind. I've been reasonably confident of my English throughout most of my life but I got the jitters just before my IELTS and I thought I might as well prepare for it a bit :)
I searched online for a few minutes and managed to find some prep material for IELTS. If you want to dig for more stuff, by all means, but I'm sure this stuff is more than what you or anyone will need!
- The ETS IELTS Handbook
- Cambridge Practice Tests for IELTS Books 1, 2 & 3
The ETS Handbook gives you an excellent idea about the different sections in the IELTS and what you can expect to find in them. They are, of course,
- Listening
- Reading
- Speaking
- Writing
Once you've gone through the handbook, the Cambridge Practice Tests pretty much cover almost everything you might face on your exam day. There's plenty of tests to get your hands-on experience. I suggest always taking practice tests under time constraints to get you better used to the routine. I've got my own tidbits of tips for each section. Here you go!
Listening: The one section that, quite seriously, had me the most worried since i was expecting some extinct Scottish accent taping that was incomprehensible to any but the most adept of English understanding people. However, the Cambridge practice tests allayed that fear and I found that the accent in the IELTS tapes is as British/Australian/American as can be. I doubt anyone would have trouble understanding it if they've had even the briefest of stints of speaking English with others. (Critical Tip - Never lose track of what the speaker is saying. The speaker speaks almost exactly in synch with the sequence of questions you'll be getting, so don't worry about synchronizing. The Listening section is all about how good you can maintain your concentration and not about checking on complex vocabulary or syntactical intricacies. If you miss a question, let it go; better that than to miss the next 3 questions trying to find the answer to the first one.)
Reading: The passages are fairly easy to assimilate and the questions aren't any different than the reading comprehension questions we've been tested on since the first grade. The vocabulary again is very basic (if you've prepared for the GRE already :P). So, The only way possible to mess up in this section is to not know how to title passages correctly, or to somehow be able to misinterpret the passage almost entirely. (Critical Tip - Read the passage as quick as you can, without skipping or skimming. Absorb as much of it as you can. Read once, thoroughly, and then move on to the questions. Make sure you answer the question asked and feel free to refer back to the passage for each question)
Speaking: The Speaking section involves you sitting down with a person who'll be interacting with you. The topics discussed are very mundane, so don't expect to make riveting speeches or have an earth shattering debate. Just take it easy, and speak. (Critical Tip: Find a British/American person and start conversing with them regularly so you can catch some of that accent and rub it off during the test. Fluency, vocabulary, grammar and accent; all have points.)
Writing: It seems pretty simple. Describe one graph or table, and give your opinion on the topic presented. Yet, somehow, this is the section I managed to mess up myself. So, I won't be giving you any tips on my behalf. Although, the general opinion seems to be to maintain the fluency within your writing and making sure that there are no abrupt changes. Again, vocabulary and grammar have points.
With about 1 day of prep, which basically included reading through the ETS handbook and then completing 3 Cambridge Practice Tests, I managed to score 8 bands out of 9 (Reading 9 Listening 9 Speaking 7.5 Writing 6). I"m sure with 2 or 3 days of prep, I could've secured more than that, but I suppose i'm going to have to live with the 8 and hope it get's me admitted into a good masters program :)
Hope this helps!
I searched online for a few minutes and managed to find some prep material for IELTS. If you want to dig for more stuff, by all means, but I'm sure this stuff is more than what you or anyone will need!
- The ETS IELTS Handbook
- Cambridge Practice Tests for IELTS Books 1, 2 & 3
The ETS Handbook gives you an excellent idea about the different sections in the IELTS and what you can expect to find in them. They are, of course,
- Listening
- Reading
- Speaking
- Writing
Once you've gone through the handbook, the Cambridge Practice Tests pretty much cover almost everything you might face on your exam day. There's plenty of tests to get your hands-on experience. I suggest always taking practice tests under time constraints to get you better used to the routine. I've got my own tidbits of tips for each section. Here you go!
Listening: The one section that, quite seriously, had me the most worried since i was expecting some extinct Scottish accent taping that was incomprehensible to any but the most adept of English understanding people. However, the Cambridge practice tests allayed that fear and I found that the accent in the IELTS tapes is as British/Australian/American as can be. I doubt anyone would have trouble understanding it if they've had even the briefest of stints of speaking English with others. (Critical Tip - Never lose track of what the speaker is saying. The speaker speaks almost exactly in synch with the sequence of questions you'll be getting, so don't worry about synchronizing. The Listening section is all about how good you can maintain your concentration and not about checking on complex vocabulary or syntactical intricacies. If you miss a question, let it go; better that than to miss the next 3 questions trying to find the answer to the first one.)
Reading: The passages are fairly easy to assimilate and the questions aren't any different than the reading comprehension questions we've been tested on since the first grade. The vocabulary again is very basic (if you've prepared for the GRE already :P). So, The only way possible to mess up in this section is to not know how to title passages correctly, or to somehow be able to misinterpret the passage almost entirely. (Critical Tip - Read the passage as quick as you can, without skipping or skimming. Absorb as much of it as you can. Read once, thoroughly, and then move on to the questions. Make sure you answer the question asked and feel free to refer back to the passage for each question)
Speaking: The Speaking section involves you sitting down with a person who'll be interacting with you. The topics discussed are very mundane, so don't expect to make riveting speeches or have an earth shattering debate. Just take it easy, and speak. (Critical Tip: Find a British/American person and start conversing with them regularly so you can catch some of that accent and rub it off during the test. Fluency, vocabulary, grammar and accent; all have points.)
Writing: It seems pretty simple. Describe one graph or table, and give your opinion on the topic presented. Yet, somehow, this is the section I managed to mess up myself. So, I won't be giving you any tips on my behalf. Although, the general opinion seems to be to maintain the fluency within your writing and making sure that there are no abrupt changes. Again, vocabulary and grammar have points.
With about 1 day of prep, which basically included reading through the ETS handbook and then completing 3 Cambridge Practice Tests, I managed to score 8 bands out of 9 (Reading 9 Listening 9 Speaking 7.5 Writing 6). I"m sure with 2 or 3 days of prep, I could've secured more than that, but I suppose i'm going to have to live with the 8 and hope it get's me admitted into a good masters program :)
Hope this helps!
Subscribe to:
Posts (Atom)
