"subscribe" <sa************ @gmail.comwrote in message
news:01******** *************** ***********@u6g 2000prc.googleg roups.com...
How to conquer fear of programming?
....desensitisa tion training...
First day... approach your computer until you reach the limit of your fear.
You may not even touch the keyboard on the first try. Try not to raise the
tension level in the office by screaming. Sweating and trembling however are
ok, provided it doesn't disturb the guy in the next cubicle who really needs
his nap time.
Second day... go a little closer, maybe touch the spacebar, but for goodness
sake don't carry hot liquids like coffee to the keyboard yet... this is for
advanced recoverers ... unless you have one of those dandy industrial
waterproof keyboards (which also protect the keys from blood, sweat and
tears). You might observe a tingling sensation in your fingertips. Don't
worry about this, the keyboard is earthed.
Third day... try opening a code window and typing garbage. Don't be
scared... jump in... it's probably best if you try this in your own code
space... you might not be ready for modifying existing code yet, but feel
free to write some new stuff. If you feel confident enough, do a trial
compilation. Most likely it will fail, but ignore the failure. Remember...
every failure gets you closer to the solution. Try to fix any logical errors
by doing something completely different. If that doesn't work, go back to
the original, non-functioning code- there's no sense beating your head on a
brick wall, and someone else is bound to spot the error and fix it
eventually. If you can do all this without fear, you are almost there!
Fourth day... try fixing yesterday's errors. You might get a successful
compilation today! If not, just go and have a 'meeting' in the cafeteria.
There's bound to plenty of programming expertise there, and they'd much
rather big themselves up by talking about it and proferring unintelligible
advice, than actually doing it. Donuts and coffee are great mind-lubricants.
Fifth day... try copying and munging someone else's object or procedure to
do the exact opposite of what the original programmer intended. Don't be
scared. You might have to declare some globals, or create some byrefs into
another object or module that breaks the UML model to get it working. Don't
worry too much about commenting your changes, as any good team member will
be able to read your mind from the code you wrote. All this might break
other team members' code, but don't worry about this, another team
programmer is sure to fix it all up later, straight after the user
acceptance system fails after 10 embarassing minutes. Senior programmers are
used to having their carefully planned, written, tested and
performance-benchmarked code totally trashed by interns and work experience
kids, and they love helping when you get stuck.
If you work in a SQL environment, try reorganising or flattening a table
structure back to first normal, or even flat-file form to make your coding
day easier. Alternatively, try writing some code to get rid of that pesky
primary key constraint on the 'customer' table... space that could be used
for storing REAL data. DB analysts love it when you 'simplify' their work,
and you took a backup first, right? So what's the problem?
If you feel sufficiently confident, try introducing a new programming
language into the programming environment that no-one else in the office has
even heard of, much less has any expertise in, and use it to rewrite a
critical module or object so that it's more 'elegant'. This always makes
things more interesting, and may shorten your working day.
Sixth day... try to remove the stapler from your cheek that the Senior Prog.
put there yesterday, just before he tried to eat your cubicle and
spontaneously combusted. You may need medical assistance for this step.
Seventh day... delete everything and start again. If necessary, return to
day 1 of this training program.
If you follow this 'seven point' plan, you'll be cutting code with the best
of them in no time, no worries. It also cures arachnophobia.. . you know...
fear of the world wide web, 'cos you'll need the web to download and munge
other people's code. Don't forget to remove any copyright notices and use
restrictions from downloaded source code before using it.
Alternatively.. . Give yourself a simple programming task to do and jump in
with both feet. Don't leave the keyboard until it's working perfectly. This
might take a little time, so don't plan on driving for a while. Driving and
No-Doze are not a good mix. You need sleep to drive.
Keep polishing your code until it's so shiny that it's perfectly documented,
twice as fast, twice as robust and half the size of the previous version,
written by the Senior Prog. (S)he loves being shown up for the dinosaur that
(s)he is, and will appreciate your improvements to his/her code.
Another alternative... you could just take a course and be done with it. It
might take a little longer than 7 days, but the effort will be well worth
it. Universities always turn out first-rate programmers in the most 'widely
used' languages like Pascal, Fortran and Cobol, and the effort you put in to
learning the intricacies of these languages will be rewarded by a long and
prosperous career.
;)
