Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm a recent graduate and there are a few (three generally) languages I switch between based on the requirement. What I've found is I always have to look up syntax whenever I code. I know I'm not alone because Ryan Dahl, author of node.js, was not sure of JavaScript syntax during a demo. That's somewhat reliving to know.

On the other hand, companies recruiting (at least FB because that's what they have told me for the upcoming interview) expect you to quickly find the most effecient algorithm in your head first and then code it bug free. I don't know how much creative thinking one can do under pressure but for this question I'm concerned with the second part.

So my question,

How does one before proficient learn "inside workings", idioms and in general become proficient in a language?

If the advice is language specific, I love Python the most so how does become a Pythonista? I want to be able to code without having to look up syntax, know and use idioms wherever apt, follow the standard practices, etc.

Update

Those who suggest practice, practice only makes permanent. Practice reinforces what you already know. So that may work for syntax, but you have other issues like internal workings, idioms, not-as-expected cases, etc.

share|improve this question

migrated from stackoverflow.com Oct 11 '11 at 7:45

This question came from our site for professional and enthusiast programmers.

    
There is a difference between bug-free and syntactically correct. Everybody has to look up syntax specifics once in a while (or have their IDE do it for them). The more you actually write code, the less often you'll have to do this. But that's not the same as writing bug-free code at all. For starters, read the Python Cookbook (which is not quite current anymore but contains lots of examples how to write Pythonic code). –  Tim Pietzcker Oct 11 '11 at 7:36
    
@TimPietzcker: Seems a 2002 book. But a good place to start none-the-less. –  Jungle Hunter Oct 11 '11 at 7:43
4  
@JungleHunter: Don't overlook the merits of PRACTICE. Practice doesn't make permanent. Repetition makes permanent. Keep in mind, we're not talking practice like Allen Iverson talks practice where you're going through the motions and doing "drills". We're talking practice like doctors talk practice where you are using what you know to tackle problems you haven't attempted before in a useful scenario. Don't do the same things you already know how to do. Do new things. When you say to yourself "There's got to be a better way." -- look for it. –  Joel Etherton Oct 11 '11 at 12:07
    
totally agree with Joel .. Practice Practice Practice Practice Practice ... and then a little more practice ! :D –  Ritwik G Oct 11 '11 at 13:57
    
same way one gets to the Met, practice, lots of practice ... –  Jarrod Roberson Oct 11 '11 at 19:27
add comment

11 Answers

up vote 10 down vote accepted

Once upon a time, it was important to be able to recall syntax, language and frameworks at will. But the internet has changed the way our minds work. Recent research suggests that we, as a species, are now much better at remembering where information exists than what the information is. I know instinctively that this is true for me, particularly with programming, and it would appear so for Ryan Dahl, inventor of Node.js.

That said, there is no substitute for experience. There is always a problem with an online "memory" in that you never know what it is that you don't know. And you'll only find out by trial and error and working with better programmers than yourself.

share|improve this answer
    
Yep, that answers the part which deals with syntax. Could you also elaborate to cover guidance towards understanding internal workings, idioms, not-as-expected cases, etc. –  Jungle Hunter Oct 11 '11 at 7:55
5  
@JungleHunter: Internal workings and idioms are generally things I don't need to know until I need to know and I can find on Google. But not always. Example: I know that "NotANumber == NotANumber" is true for some languages and false in others. I don't need to remember which is which, cause I can find out. But if I didn't know that information at all, I could mess up badly, and I only know it from experience. Not-as-expected cases always fall into the "you never know what it is that you don't know" category. –  pdr Oct 11 '11 at 8:05
    
Hmm... and idioms? It's always better to use idioms right? And standard practices? I may be doing something in a way which works but that's not how a "native" speaker would do it, right? –  Jungle Hunter Oct 11 '11 at 8:07
    
@JungleHunter: Again, there are different types of idioms. Most are things you don't really even think of, like the casing of method names. Those you look up, without even thinking about it. But there are, again, ones that you don't know of until you see them and say "what's that?" Ruby's testing frameworks spring to mind, although they are spreading around other communities. Those you will get from experience. Reading code, as others have suggested, is a form of experience. I still say there's nothing quite like working with better programmers. –  pdr Oct 11 '11 at 9:09
add comment

In terms of idiomatic python, you've read Code Like a Pythonista, right? It's got tons of great tips on writing idiomatic python.

That said, you want to make sure that you're using the the language to write clear, readable, maintainable code. good, solid, code; code that anyone can read and tell what it does. When I'm learning a new language, I have to remind myself of this, because I think most of us have the tendency to want to use every part of the language, all the bells and whistles, when we are first picking it up.

share|improve this answer
    
+1 for Code Like a Pythonista. I had just uncovered this specific for Python. –  Jungle Hunter Oct 12 '11 at 2:43
add comment

Always think about your code/solutions and try to improve them as much as possible. You can read pragmatic programmer too.

share|improve this answer
add comment

It really depends on your memory skills. Some people are blessed with nearly an eidetic memory while others struggle to remember things, particularly in stressful situations like speaking in public. Improving your memory skills, probably one of the most important things you’ll learn in college, will help. When you understand how to manage how your brain best categorizes and retains knowledge, you’ll be able to memorize and repeat most anything well, within limits. It’s largely a journey of self-discovery because people do this in different ways so what’s worked well for me may not be ideal for you.

However, I’d say that it’s actually of limited value when it comes to programming. I did attain the level you’re talking about with VB6. I knew just about everything there was to know about it. I did it by programming in it extensively on some complex projects and answering questions online about it. However, that detailed knowledge is of limited value today. What really matters is understanding programming in general and how to turn a set of specs into a functioning application. My thinking today is more in line with Bruce Lee’s “Be water” speech and the description of the mentat generalist from Frank Herbert’s Children of Dune.

share|improve this answer
add comment

Go and live and work with the natives, also read the historical manuscripts with of the natives in the original language.

(So to learn ‘c’ with have to spend time living with a CPU, but to learn JavaScript you have to live with a front end web developer and a web hacker to get both sides of it.)

share|improve this answer
add comment

"I want to be able to code without having to look up syntax,"

You can't. A good programmer knows algorithms independent of language, knows what his favored languages are capable of and the general approach in those languages, and can competently - if not expertly - code in a handful of languages. You can't keep all that syntax, even for one language, in your head, and it would be inefficient to try. I've done C++ for 9 of the last 12 years, and I still have to look things up occasionally (Templates/STL in particular, and I still cannot remember without reference the syntax for declaring a class member function pointer, even though I use it about twice a year).

Knowing where to find the answer and what kind of answer you are looking for is the valuable skill, not the ability to memorize man pages. If an interview exercise requires you to come up with an algorithm, that's fine. If it requires pseudo-coding the answer, that's fine. If it requires you to code that algorithm in the basic mainline syntax of a language you are claiming expertise in, that's fine. If it requires you to have in your head some only occasionally used or arcane syntax, they're doing it wrong.

The 80/20 rule applies here. In your one or two main languages, you'll use maybe 80% of the syntax for 99% of your work. Know how to look up the other 20%, but don't even try to keep it all in your head.

share|improve this answer
add comment

Writing code in a particular language is important, but has a bootstrapping problem: how do you use the idioms of a language when you don't know them?

I suggest reading code, written by experts in the language. (For instance, if you were learning Clojure, read Rich Hickey's code).

share|improve this answer
    
For learning idioms, nothing beats reading. Writing code might eventually lead to reinventing the existing idioms, but that could take forever. –  user281377 Oct 11 '11 at 9:01
    
Excellent advice. Reading not only familiarizes you with the idioms and the syntax as put into practice, but with differing styles of coding, and approaches to problems that you might not think of on your own. –  kylben Oct 11 '11 at 12:09
1  
The problem with this is that there's an extreme amount of dung-code out there... –  Max Oct 11 '11 at 13:23
add comment

Code a lot. Have your code reviewed by others, so you know it's good code. Read and discuss your other people's code, and absorb their ideas and coding styles if they're good. Read about the language; understand its culture as well as the code (this is especially important for Python).

In other words, join an project. There are lots of open-source ones waiting for your contribution.

share|improve this answer
add comment

Practice...
Practice...
Practice...

Get your hand on as many programs and applications as possible, experiment with different idioms, take the language to its limit.

With that comes experience and with experience comes proficiency.

share|improve this answer
    
False. Studies show that. I would recommand reading stuffs like code complete for more informations about thoses stidies. Practice is important, but people with a lot of practice doing the same mistakes again and again and again are very common. –  deadalnix Oct 11 '11 at 7:59
    
@deadalnix: if you make the same mistakes again and again and again then you are not learning anything. Experience comes from a lot of practice. One year practiced 10 times does not equal 10 years of experience, so it depends on what your definition of practice/experience is. –  JohnDoDo Oct 11 '11 at 8:05
    
Agreed. But is it that common that it should be expressed explicitely. –  deadalnix Oct 11 '11 at 8:20
    
@deadalnix: Unfortunately yes, which then, even more unfortunately, translates to "bad programmers are common" :( –  JohnDoDo Oct 11 '11 at 8:27
add comment

I would say

  1. Code as much as possible
  2. Team up with people who know more than you (you learn a lot that way)
  3. Time (can't stress this one enough). Becoming proficient takes time

I would have said read books etc. but I personally learn more by doing than reading.

share|improve this answer
add comment

The best way to learn a language is using it often, very very often. Just try to come up with projects of your own. Little things you can try to create. Once you have made alot of these you will start to learn the language.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.