Characteristics of Great Coders

Following are the common traits of good programmers.

  • logical
  • curious nature
  • tenacious
  • patient
  • self-confident
  • detail-oriented
  • methodical
  • polite
  • creative
  • calm
  • analytical
  • cooperative
  • rational
  • ability to see the implications of a decision
  • desire to solve problems
  • seeks mental challenges
  • self-motivating
  • ability to focus
  • works well alone
  • focused 

Lifestyle & Habits

  • Are socially inept and “normal” people who expect things like stimulating and thought-providing conversation with them will be disappointed.
  • Struggle with a social life because they cannot place appearance above function. Body language, they believe, is too imprecise to be useful for communication.
  • Are fascinated with gadgets. Generally speaking, non-technical people believe the adage “if it aint broke, don’t fix it.” IT professionals believe that if it ain’t broke, it doesn’t have enough features yet.
  • Make clothing their lowest priority assuming the basic temperature and decency threshold has been satisfied. Anything more is a waste.
  • Are excessively honest even in the most awkward situations, except for white lies like “I won’t change anything without clearing it with you.”
  • Are exceedingly frugal because when it comes to money every spending situation becomes a problem of resource optimization.
  • Delight in sharing their wisdom even in areas in which they have no experience. They believe that their command of logic provides them with inherent insight into any field. Non-technical people, of course believe that knowledge comes through experience.
  • Have amazing powers of concentration. Of course this leads to devoting days to devising an elegant solution to a simple problem because they can hear the computer laughing at them.
  • Hate risk because managers make such a big deal out of one little mistake. Just look at the Hindenberg, Apollo 13, the Hubble space telescope, and the Space Shuttle Challenger
  • Knows that programming is a creative art and is anything but boring
  • Takes great pride in his work and gets great satisfaction from it
  • Tries to reduce the complexity of both the problem and the solution
  • Is in a hurry but is never too busy to help others learn
  • Seeks out constructive criticism and provides constructive criticism for others
  • Has worked on failed projects but has consciously learned from those failures
  • Is a master of his tools
  • Never stops learning and gets a thrill from the ‘aha’ moments

Three Great Virtues

  1. Laziness
    The quality that makes you go to great effort to reduce your overall energy expenditure. It makes you write robust, modular, well-documented programs so you can reuse the code.
  2. Impatience
    The anger you feel when the computer is being lazy, which happens when another programmer is not lazy. It makes you write programs that use minimal code so they’re fast, efficient, and anticipate what needs to be done.
  3. Hubris
    The pride that makes you write and maintain programs that you and your peers will admire. If hubris is uncontrolled or undeserved, it can also get you in trouble.

(Taken from various sources, including works by Larry Wall, Scott Adams, Richard Bandler & John Bentley)

Safari 3.1 Released

After having worked with Safari 3.x for Windows beta for the past few months, I’m glad that Safari 3.1 is finally released. I have tested it on an application with considerable javascript code and I do agree with Apple’s claims to have faster javascript processing.

“In addition to loading web pages 1.9 times faster than Internet Explorer 7 and 1.7 times faster than FireFox 2, Safari 3.1 runs JavaScript up to six times faster than other browsers”  – Apple.com

Generally, the browser feels more stable and polished then before, definitely worth keeping and using. 

Of course, there are a host of new features like HTML5 support and Google Gears type caching. 

How To Pick A Programming Language

This was written in response to one of the inevitable “Why programming language is better, x or y?” questions that pops up with great regularity on USENET.  I thought I’d take a stab at answering it for all time …Let L be the set of all programming languages ever conceived past, present, and future.  The meta-question, M, thus becomes:

     Among all members of L, which is the “best” and thus, which should I learn and use?

A variant of M, let’s call it M’, is:

     Is L(x) “better” than L(y)?

Let P be the purpose for which you wish to learn a “best” language.

Let A be the answer to M or M’ with condition P as a constraint.  A is thus the following set:
 

1) P = “I am interested in the design of languages and/or language theory.”

Learn as many members of L as time permits.  Do not pollute L with your own ideas until you really understand what you are doing and what has already been done.  Then do so only if you are convinced  you can materially add to the state-of-the-art with original and useful work.  The world does not need another language just so you can prove that you understand LR(1) grammars.  Implement a subset of at least one existing language yourself to see just how hard this is to do well.
 

2) P = “My current language is too slow/big in its appointed task.”

Most of the time, these problems have a lot more to do with poor programming and algorithm/data structure design than they do the language.  Really get under the covers of your programming style and design approach before you abandon the language you currently know best.  Read Bentley’s “Programming Pearls.”  Learn to use a profiler.  Consider optimizations which merely replace the slow/big portions of the code with something written in a naturally faster/smaller language.
 

3) P = “I have a specialty problem domain which is not well addressed by a general purpose programming language.”

Research what has already been done.  You can often find close enough matches to your problem within other problem domains to get something useful done.  If there really is nothing useful out there, strongly consider using one of the extant scripting languages to build a “little language” of your own which addresses your problem area.  If all else fails, ignore 1) above, and invent your own language, but keep it as small and simple as possible, or you’ll spend less time on your chosen problem area and most of your time maintaining your new language.
 

4) P = “I need to become/stay employable.”

Survey common practice in your profession of choice and determine the most common operating systems, GUIs, and languages already in use and the probable evolution of these items in the next several  ears.  Based on this information, you should select one procedural language, one object language, one scripting language, and, possibly, one assembly language which will comprise your core skill set.  In selecting these, also consider the availability of supporting tools like standard libraries, debuggers, language-sensitive editors, profilers, and so on.  If you have some choice of languages, always prefer those that share a common link format and have compatible inter-language calling APIs.  If it comes down to a tie, pick the older language because it will almost always have fewer bugs.
 

5) P = “I want to write ‘portable’ code.”

Warning: Computer Science Heresey follows.  I’ve already been burned at the stake in this matter, so put your matches away.

Code ‘portability’ is overrated.  Way more important is the portability of your programming skills.  Languages come and go (well, they never really go, do they), but a good programmer expresses themselves well in pretty much any language.  This comes with time, experience, reading other people’s very good code and doing it wrong over and over again.  The most portable language in the world can’t help you if you don’t understand algorithms, data structures, object decomposition, and how to trade off between them.  Writing truly ‘portable’ code has as much to do with your understanding of the underlying operating environments (hardware, OS, network, I/O, and GUI) as it does with the language in question.

There are, of course, cases where portability is very important.  For example, if you are writing commercial software which must run on lots of different platforms for your company to succeed.  In that case, first see if you can find cross-platform library support so you don’t have to do it all yourself.
 

6) P = “I want to make lots of money.”

Quit programming.  Become a rock star, actor, or corrupt politician.  The odds of getting rich in these fields, however slight, are probably better than in programming.
 

7) P = “I’ve heard that OO is the way to do things, so I want the best OO language.”

OO is one way to crack a problem.  It is not the only way.  More importantly,  it is often not a good way.  A solid OO language should be in your bag of tricks, but it’s not the only thing you will need.
 

8)  P = “I’ve heard that AI is the way to do things, so I want the best AI language.”
See 7) above.
 

9)  P = “I want to produce code faster.”
 

Type faster.  It doesn’t matter what you type because if speed is your goal you’ll just become expert at writing buggy code, so why bother with syntax and semantics at all?  Correct code is always produced by people who are thoughtful and deliberate about what they are doing.  Oh, and in the long run, they’re almost always faster getting things done too.
 

10) P = “I want the <gender/species> of choice to like me and be impressed enough to go out with me.”
 

See 6) above.
 

11) P = “The system I must use prescribes a vendor-defined language and tool set.  I want other choices.”
 

See if there are Open Source or alternative vendor choices for that platform.  If not, master the languages/tools on that plaform then broaden your horizons as a matter of professional pride and employability.  See 4) above.
 

12) P = “I’m very nerdy.  All I like to do is code on as many different platforms with as many different languages as I can.  My Resume’ is 14 pages long. I have not been out of the house since 1982.  Please help.”
 

Get a life.  Read some poetry, or better still, write some (without using curly braces or semicolons).  Learn a musical instrument that does not require electricity in any form.  Get a low-tech hobby like gardening or sewing.  You are an Addict – I feel your pain.  As a recovery strategy, consider volunteering your skills to a cause that’s worth your time and effort and which requires you to interact with people who have absolutely no clue how a computer works.  Try not to be a jerk when the local minister does not grasp the elegance of your finely tuned LaTeX macro for generating the Sunday Bulletin.  Do something good for your body and your spirit.  I strongly recommend at least one high-activity sport (channel surfing does not qualify) and shooting semi-automatic handguns (at paper targets in a legal manner) as excellent mind-clearing tools.  Collect something other than computer manuals.
 

13) P = “I want to be famous.”

Rob a bank and get caught.  OR  Write a ton of really useful code and then give it away.
 

14) P = “I’m bored, I need a new challenge.”

If you already know more than 5 languages, consider joining the Navy SEALs – they are very busy at the moment and are always looking for an Adventurer just like you.   If you are over 19 and this is therefore impractical, get married and raise children.  You will never be bored.

(Originally posted on comp.lang.python, 1 May, 2002)