There are many facets to being a programmer (e.g. communication, pragmatism, etc.) but what technical skills do you think separate an average programmer from a jedi programmer?

Here are a few on my list:

  1. Know/understand a system level programming language like C/C++
  2. Know/understand a managed programming language like C#/Java
  3. Know a couple of scripting languages like Python/Perl/Bash
  4. Know a declarative language like XML
  5. Know how to use a debugger and do it well
  6. Continually update your personal knowledge portfolio (read, read, read)
  7. Be comfortable in different operating systems (Windows/Linux/Solaris/etc.)
  8. Master the ins/outs of your IDE
  9. Learn how to properly write unit tests
  10. Study design patterns
  11. Skilled with regular expressions when appropriate

...I could go on but I'm curious to hear what you guys think...

EDIT: A few people have scoffed at the list of languages as opposed to the conceptual skills. In the question, I specify technical skills - not just soft-skills.

Regardless, my opinion of "jedi" programmer has changed a bit. After reading Andy Hunt's "Pragmatic Thinking and Learning", I have a whole new sense of what it means to be an expert in a particular field. But again...this question is about technical skills within the knowledge portfolio itself.

25 accepted

The key to becoming a Jedi Programmer is the ability to think of a problem and multiple possible solutions at multiple levels of abstraction, and shift from level to level as appropriate. This can greatly enhance both your ability to understand the problem, ask the right questions, and arrive to solid solutions. An added bonus is that this will also make it easier to interface with other developers, management (and if your business requires: clients/customers).


The ability to always learn new things and be humble enough to accept criticism is crucial IMO.


Genuine enjoyment of what we do. If you don't have that natural drive to find new things to learn you'll stagnate. I know programmers who at one time were Jedi but life happened and now they're average programmers or trying to play catch up. As a previous commenter mentioned our industry changes quickly and it doesn't take long to get behind. It takes a lot of time to stay current and if you perceive that time as "work" and not "fun", you will eventually burn out, your skills will stay the same, the industry will progress, and as the expectations of a Jedi continue to increase - you'll become average IMO.


being able to wave your hand at the users and say "these are not the features you are looking for", and have them believe it... ;-)

seriously - and making wild assumptions about what you think a Jedi programmer is - from your list:

  • #1 is critical, I would add assembly language to it; you cannot master the machine if you do not understand it
  • 2,3, and 4 really don't matter - if you have mastered the machine then a hand-holding language is really no challenge
  • 5 is critical
  • 6 is critical
  • 7 is not really that important, as long as you understand O/S principles
  • 8 assumes that a Jedi uses an IDE ;-)
  • 9 is critical
  • 10 yes and no - Jedis create design patterns as needed, and rarely need to study them
  • 11 "when appropriate" is key - it is possible to have a fairly stellar career and never need them ;-)

The deep question, "what separates an average programmer from a Jedi", is not covered by any list of skills or tools, but by an innate comprehension of the symmetry and beauty of computational forces, by the ability to see in your mind the whole of the system as an animated organism yet still reach in and slice off a tentacle without causing pain.

I could go on, but this is getting too philosophical/abstract/silly.


Keep current, this industry changes far FAR too fast to let your guard down for even a few months.


Experience programming in imperative (Java, C++, etc.), declarative (XML, SQL, etc.), and functional (Haskell, F#) languages and the wisdom to use the right tool for the right job.


One word: recursion. More important than actually understanding the concept is knowing when to use it. Some programmers don't use it because they're afraid to. Others use it every other function so they can show off their 1337 programming skills.

  • know RegExps (insert obligatory XKCD here)
  • Have written code on a bare metal, without an OS (supposedly on some embedded settings).
  • can make anything compile. (not giving up on something because "it doesn't compile")
  • handle pointers (insert obligatory Joel on software link here)

Being able to program in both high level languages and Assembly.


Looking at the nature of a Jedi, one thing that is forgotten here is the attitude of a developer. You've got to be be able to pass knowledge and teach others while at the same time being productive and making sure the bigger picture is taken care of. Often you'll encounter more junior developers with heaps of raw talent and arrogance in abundance. They still need a helping hand.

I have also had the opportunity worked with fantastically bright people, but they have had zero (sometimes less!) ability to deal with other team members and to communicate. Definitely not a Jedi trait. I'd consider this a "soft" skill, but a skill nonetheless.

This ties in with a school of thought that suggests you don't know a thing, until you can teach a thing.


I just use "the force".


You should be intimately familiar with the workings of source/revision control.


Personally I believe that a Jedi programmer would be more about engineering the theory of the program and less about the languages involved. Blasphemy, I know but many great programmers that have sat down with me are less concerned about the language. It is like they see beyond and into another world, constructing systems and them binding them together with code.


The answer to becoming a Jedi programmer lies in the technologist, not the technology, just as the answer to Zen gardening lies in the gardener, not the garden.

More concretely, while you already see broadening your horizons as valuable, I would go even further: if you have familiarity with low-level languages, extend yourself into higher level languages, and vice-versa. If you prefer one IDE or source control, develop competence with one you don't like. Choose very different technologies, tools, and methodologies. Get a better view of the comprehensive landscape of what is available to programmers, and more importantly how technology changes over time. This will give you the best mental model for what tends to stay the same over time and what tends to change, and will allow you to switch seamlessly between technologies, and communicate with users of any of them at any level.