Ucc Make0.2
ucc make (0.2)
part of the ucc make columns series...
So You Wanna Code?
Really? Why? I mean, that's actually a couple of questions, but maybe just a "Are you sure?" would suffice as a beginning. It's not the rock star lifestyle the hollywood movies make it seem, trust me. Only a couple of coders really look like Hugh Jackson and they went into consulting a long time ago.
If you think you want to code, you should be able to answer yes to at least 4 of the following questions:
- Do you find yourself making comparisons between the TV show CSI and debugging?
- Do you spend more time thinking about how to solve a problem than actually solving it?
- When you tell someone "that will take me ten minutes", does that refer to the ten minutes you actually take to physically do it, and not the three hours you spent researching it?
- Can you name more than three Smurfs? (more relevant than you think)
- Do you think Young Sherlock Holmes was at least as cool as Young Indiana Jones?
- Did you do poorly in a foreign language class because 'the syntax wasn't logical'?
- Related: Do you think Yoda talks pretty normal?
- Related: Do you know what
Hungarian notation is? - When asked who the *real* captain of Star Trek was, do you secretly think 'Spock'?
- You know who Stephen Hawking is?
- Are people asking you to fix their computer?
- Are manuals for sissies?
- Does it take you half the time to find things on the internet than other people you know?
- Related: Do you use google as a verb?
If you couldn't answer more than 3 of those, it's quite likely the rest of this isn't going to interest you.
If you did, then here is a crash course on a few things you should know before getting dirty with your first programming or scripting language.
Learn Your Virtues
Perl was the first language I ever really tried to learn. BASIC didn't count, I was just copying from books. Even my gaming handle is from this wonderful language. Naturally, Larry Wall (Father of PERL) has a place in my heart. So I quote from °Programming Perl, 2nd ed., by Larry Wall, Tom Christiansen, and Randal L. Schwartz.
The Three Great Virtues of a Programmer
Laziness
The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer. Also, hence this book. ["This book" = Programming Perl. -GGC-]
Impatience
The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least that pretend to. Hence, the second great virtue of a programmer.
Hubris
Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about. Hence, the third great virtue of a programmer.
(see also
LazinessImpatienceHubris)
And I am lazy, impatient, proud person.
In those three qualities, though, you have the foundation of being the person to write good, if not great code. Born from laziness and impatience comes effiency and economy. You get into the practice of trying to learn how to write something in three lines, not five - because then your overall program might be only three hundred lines, not five hundred. Hubris is the virtue of programmers who want other people to use their code. For some, it extends even past that - it makes you write actual code people will be willing to look at. Anybody who thinks that coders are, by average, disorderly, unkempt, raggedly people has never listened in on a hour-long debate about indentation. (Bean:Amen)
It's the impossible triangle. You will write it fast. You will write it smart. You will write it better than the next guy. It's not likely to turn out that way, but it's a neat goal anyway.
If all of this is still sounding like your thing, then you should gather yourself around with the basics of programming. When a lot of people start out, they generally buy a lot of books. Books are good reference material. They're good to go to when there is something you know exists, but can't quite remember what it is.
The problem with programming, though, is that it's almost purely logical. It's my personal theory that this is why most of the coders I know self-taught, learning by struggling through tutorials and examples rather than straight from books. Books can provide the primer, the foundation, the answers to early questions, but it's difficult to understand the logic unless you interact with it, poke it, make it fail a couple of times.
Learning from mistakes is part of learning to code. Thinking in reverse if often the way around a problem - it isn't what isn't working, but what is. Sometimes, it's not what you can prove, but what you can't disprove. The best way to find out if that pillar is a support for the whole is, well, to remove the pillar. Many subjects are based on memorization, but memorizing something would never ask you to take out the pillar to see if the house would fall down.
So if you grok Yoda, are lazy and proud, and have no problems with taking out a pillar to test the solidity of a foundation, wait till next week when we ask:
You wanna mod?
Other ucc make columns
please reserve edits to minor changes and comments – RegularX
