When people ask me how many programming languages I know, I am usually hesitant and say something like "Many." and then tell them the projects I have worked on and the languages they are written in. My CV lists eight languages that I am familiar with. But at what point can you say you know a programming language?
If somebody says they know C, how much can you trust this statement? C has so many pelicularities and as soon as you start to dig into something a little deeper, things get complicated very fast (link1, link2, link3, link4, link5).
If somebody says they know Java, for me, this raises more questions than it answers. Have they built a desktop GUI, developed mobile apps? Have they worked with threads, developed web applications, distributed applications? Have they used reflection or aspect-oriented programming? These are all things that can be done in Java.
Does knowing a language mean I can read code that others have written in that language. If I am nasty, and put a little time and effort into it, I am sure you can't read the code I produce or get a totally wrong impression of what it does (link). Does knowing mean I know how to get my programs past the compiler?. If this is the case, I'd say you can learn any language on a lazy sunday afternoon and put it in your CV.
You might say that years of experience matters the most. But what does years of experience mean exacty? If you say you have "2 years" of Python experience, did you use Python literally 730 days in a row? Or did you use it once every week, when you needed a quick script, to delete some files? Or did you build a website (2 years ago) using a Python framework where you copied most of the code from the tutorials?
When can you say you know a language? Or are we asking the wrong question?
Top comments (10)
I'd say I know a language when I have an understanding of the syntax, I know the important fundamentals of the language, like its type system etc. and that I have built anything in it and I wasn't just following along with someone else.
I also might lower this barrier if I'm familiar enough with languages like it and have a good idea of what getting going with it might be like. I'm pretty sure I've never written a line of Python in my life, but I feel like I know the language from coming across it so often and it being pretty straightforward.
If I feel like I could take on a task with the language without a really long ramp up time, I'd say I know the language.
If you asked me to write something in Haskell, I would have no idea where to start, and could not guarantee I'd be up and running any time soon. Even though I know what the languages is about, I can confidently say I don't know the language.
I think the thing that throws people is the difference between the language and the frameworks and standard patterns and practices that are used in the language. I would expect most people can learn the syntax of a new language in a few days (obviously that might change depending on the language).
My personal "main" language is C#. I expect anyone with a background in C-style languages could probably figure out any normal C# code with just a little bit of time. Figuring out the innards of how to use C# to make a WPF app or an ASP.NET Core Web application suddenly requires significantly more research and time. I'm using .NET examples here, but you can replace C# with Java and WPF and ASP.NET with Swing and Tomcat pretty easily.
The short of it: when you feel comfortable answering questions about the language (which implies you've spent some time with it and know a fair deal about it). I know python and ruby, but not everything there is to know about it; I could probably be stumped by the implementation of python's
enumerate()function in C (which I also "know"), but I know whatenumeratedoes and what it's good for.If you're looking to solidify your resume, think about this. You mostly want to have on your resume the things that you want to work with. Then people will ask you things about the language in interviews and if you don't know the answer, that's fine. At that point you can just find out what the answer is (possibly from the interviewer) and now you have it for the next time you get asked. That's what I did last time I was job hunting. I learned a lot from my interviews.
I also wouldn't be afraid to put something like "some C" on a resume, if you're looking to improve upon it. It'll make for a conversation in interviews.
Short answer: I consider I know a language when I'm able to look at code I didn't write and either understand and enjoy it, or come up with a way of doing its task better (or properly at all).
Because then it means I understand enough of the language to make educated technical choices to solve whatever task I'm working on.
I think understanding the idiomatics of a language is when you can say you really know it. I could probably write a script in Python that would get past the interpreter and accomplish a task, but I know there are things that make for elegant Python that don't flow out of my fingers the way that idiomatic Ruby or Javascript does.
I recently helped a colleague improve some Ruby code. He had done a good job with identifying some pain points and making some steps toward making it better, but his code didn't read like idiomatic Ruby. I wouldn't say that he "doesn't know" Ruby necessarily, but his code lacks the clarity and concision of more elegant code. This is fine and not a denigration of this person, who is one of the smartest programmers I have ever worked with, but just to say that Ruby is not a strong language. I don't think I would be speaking out of turn to say that he probably wouldn't put extensive Ruby experience on his resume just because he knows that Ruby uses
classanddefkeywords. If someone asked him about it or it became part of his job, he'd get up to speed quickly, but that's not his core competency right now just like my core competency right now is not Mac development like it is his. I can read code and make changes, but I have to think a lot about what I'm doing since I am so out of practice with it.I think we should really think of programming languages like we do other forms of expression like spoken languages or musical instruments. I have been speaking Spanish since high school. I can have a functional conversation at the taqueria and get around town as a tourist, but I don't claim to be fluent. Beyond that, I can read some German and French (academic work mostly) and I know some very basic conversational phrases. I definitely would not say I know these like I know Spanish and Spanish less than English, obviously.
Likewise, I have been playing tuba since my freshman year of high school. I can play other (mostly brass) instruments, but I don't know those instruments the way that I know tuba. If someone handed me a trombone or euphonium, I'd be less comfortable but probably functional. A trumpet or French horn I can cause to make a sound but it's not pretty and will have a lot of people cringing and plugging their ears. But, I do know their transpositions and some of the common challenges associated with playing the instrument thanks to taking a brass technique and method course in college. I would say I know tuba. I would say I'm passable with trombone and euphonium and familiar with trumpet and French horn.
Whether I know a language isn't really that interesting to me and if I were looking for a job, I would hope it wouldn't be that interesting to the hiring people. What's more interesting is if I know programming and whether I could pick up how to express programming in some variety of language just like it is more important that I be able to communicate almost regardless of which language I happen to be speaking. Do I know how to convey ideas and reach people? It's more important that I understand music and how musical composition works and how an ensemble plays together than that I play a particular instrument. If you can figure out how to convey that you know programming and that the rest is just an implementation detail, the languages don't really matter that much.
I think, "knowing a programming language" is to have a basic understanding of that language, and their syntax, and what compiler to use to run that specific program in that language. That can be sum up saying that somebody knows a programming language.
However, there would be the follow-up questions on his understanding level of that language:
1) How depth your knowledge of that specific programming language?
2) what is your experience in that programming language? What are the applications you have developed by using that programming language?
That would gauge somebody's understanding level of a programming language.
Just the same as for spoken languages. You'll never know foreign language perfectly, but people are usually start saying that they speak it when they're able to communicate. So, when you're able to communicate your intent using that programming language in question, you can say that you know it. There is a lot of levels of knowing of course, :) just the same as for spoken languages.
That is a good question to consider. I like Ben Halpern's answer.
I would not put on a résumé a language that I've learned for fun, since I've rarely done nothing more than some toy work with the language. So although I really like F# and D a lot (a whole lot of a lot!), I would not include it in my skill set.
If there was a position that used those languages, I'd still happily apply for the position even without that skill "under my belt". (I'm not in the market for looking for a new position. It's just hypothetical.)
I'm to the point in my career that I would also omit from my résumé any language that I never want to program in again. For example, I would not list Assembly, BASIC, FORTRAN, Pascal. Nothing egregiously wrong with those languages, just not ones I would want to work with anymore.
I think the application of a language is a great litmus test for knowing it. When is it appropriate to use Java / Scala / C / JavaScript etc? There are places I wouldn't use certain language and to me, understanding that is valuable.
That said, if I can read the code comfortably and I can grok the nuance of what the idiomatic stuff does, I consider myself learning the language. If I can connect the pragma with the performance, I consider myself conversant. The closer I get to the assembly, IL, bytecode, what have you, the closer I get to "knowing" the language.
A bit provocatively I would say: never!
For example, you could say you know Ruby maybe because you've developed Ruby on Rails applications for years. But have you used Ruby in all its possible applications? Odds are saying that no, you haven't. In that context, you know the syntax, but probably not much more than that, since the context is so different to what you're used to.
What do I mean by that? That it's a bit pointless to say "I know language X" because it's a temporary and secondary skill: I was very proficient in Python, but I haven't used it for a while so now I have to look up the documentation constantly; if I started working daily with it I would get back to "expert" level very quickly.
What is more important is: are you experienced in that domain? For example if you are familiar with the formalities of Functional programming, learning Haskell, Erlang, Scala or Clojure wouldn't take you a long time/effort. If you know the concurrent/parallel computing domain does it matter that much if you have to write Go, Rust, Java or C(*)?
Programming languages don't tell you much. The kinds of problems you solved with them tell much more about you and the potential you can have in a certain field. Do hiring companies agree? Sadly quite often they don't...
(*) In the case of C you have the added problem of memory management, which of course is not really secondary. This is the trade off of lower-level languages, and the only language-related aspect that really matters. It is a domain in itself, and it's special because C/C++ are the only common programming languages with manual memory management that are still around.