Do You Really Know Your Programming Languages?

Question

I am often amazed at how little some of my colleagues know or care about their craft. Something that constantly frustrates me is that people don't want to learn any more than they need to about the programming languages they use every day.

Many programmers seem content to learn some pidgin sub-dialect, and stick with that. If they see a keyword or construct that they aren't familiar with, they'll complain that the code is "tricky."

What would you think of a civil engineer who shied away from calculus because it had "all those tricky math symbols?"

I'm not suggesting that we all need to become "language lawyers." But if you make your living as a programmer, and claim to be a competent user of language X, then I think at a minimum you should know the following:

• the keywords of the language and what they do
• the valid syntactic forms
• how memory, files, and other operating system resources are managed
• where the official language specification and library reference for the language is

The last one is the one that really gets me. Many programmers seem to have no idea that there is a "specification" or "standard" for any particular language. I still talk to people who think that Microsoft invented C++, and that if a program doesn't compile under VC6, it's not a valid C++ program.

Programmers these days have it easy when it comes to obtaining specs. Newer languages like C#, Java, Python, Ruby, etc. all have their documentation available for free from the vendors' web sites. Older languages and platforms often have standards controlled by standards bodies that demand payment for specs, but even that shouldn't be a deterrent: the C++ standard is available from ISO for $30 (and why am I the only person I know who has a copy?).

Programming is hard enough even when you do know the language. If you don't, I don't see how you have a chance.

What do the rest of you think? Am I right, or should we all be content with the typical level of programming language expertise?

---

Update: Several great comments here. Thanks. A couple of people hit on something that I didn't think about: What really irks me is not the lack of knowledge, but the lack of curiosity and willingness to learn. It seems some people don't have any time to hone their craft, but they have plenty of time to write lots of bad code.

I don't expect people to be able to recite a list of keywords or EBNF expressions, or to spend their free time browsing through specs, but I do expect that when they see some code, they should have some inkling of what it does.

Few people have complete knowledge of every dark corner of their language or platform, but everyone should at least know enough that when they see something unfamiliar, they will know how to get whatever additional information they need to understand it. It should be seen as an opportunity to learn something new, not an opportunity to complain about "language lawyers".

Answer 1

I usually try to learn everything about a language that I use regularly, like C#, Visual Basic, or JavaScript. But then there are languages that I don't use that often, like Python, about which I probably don't know everything. I still try to find out at least what's possible to do with the language so if I ever have the need to do something that I don't know the syntax or idiom for, I'll know that it exists and look it up.

But the bare minimum for any language is declarations, operation definitions, operation invocation, common types, conditional construct, and loop construct.

If you know only that much but know everything there is to know about the programming library you care about then you can probably do just as much in the library's domain as someone who knows all about a language and how to best implement various algorithms but knows next to nothing about the library.

Have a look at Java: most Java programmers probably don't even know or care much about generics but they can do a lot with Java's class library as well as knowing the numerous frameworks at their disposal.

Answer 2

You seem like a switched on and passionate. Two attributes I would consider important in this profession. If your co-workers aren't as passionate as you, consider looking for employment elsewhere where you can find like-minded people who care about their profession as much as you do. I think you'll have a lot more fun and wouldn't need to rant so much :)

Answer 3

I've been using C# for the past four years and I'm still learning new things about both it and the .NET system libraries everyday. It's not so much as I was irresponsible but one has to balance work, e.g., learning what is necessary, with learning what is new, cool, and nifty.

Knowing this when C# 3.0 came out last year I made an active effort to learn everything (well, almost) new about the language, and I can say that I have a fairly good grasp of what is available. I'm spending a lot of time teaching/sharing these to colleagues, especially lambda expressions/LINQ, which are essentially basic concepts for the language but hard to grasp for people who have been programming imperatively all their career.

Answer 4

Since this is a bit of a longer question / rant I'm going to break things up a bit.

What are all the keywords of the language?

I think that you would be hard pressed for find someone that can name every single keyword and what they mean for all of the languages that they work with off the top of their head. However, I think that if you specialize in a given language (e.g. A C++ programmer), this should be the case. In the case of someone that works with several languages on a daily basis, knowing all of the major ones and being able to quickly find documentation on the rest of them should be sufficient.

What are all the valid syntactic forms?

Likely depends on the language you are working with - if you are working with Perl, where there is more than one way to do it, then I definitely hold it against anyone to not know anything. However, this is also another area where I think that a good programmer should know the major syntactical forms and be able to look-up the rest of them if need be. At a bare minimum they shouldn't think that it is invalid just because it doesn't follow the most common syntax.

How are memory, files, and other operating system resources managed?

This is one area where I agree with you in that I think that you should have a good understanding of how these things work in the language you are working with. When I first started working with ASP.NET I encountered a number of bugs in my applications that were entirely due to me not fully understanding the page life cycle; however, once I took the time to read up on it, I was able to better understand things. Also, this becomes even more important in some environments where an algorithm might not be as fast as you thought it might be due to how the system is storing arrays.

Where is the official language specification and library reference for the language?

In this day an age with so much information being only a Google search away, I would likely raise an eyebrow at someone that was a programmer and couldn't find this information.

As for the larger part of your question, in some cases I don't think you should be entirely content with some of the programming language expertise; however, in the case of some junior developers I think that it is just something that you have to expect and perhaps even mentor them to develop this expertise. Once you start to get more experience under your belt though and make the transition away from being a junior developer, you lose some of this expectation and indeed you should be able to expect an experienced developer to know most of these things. As such, I think that the more experienced you are as a developer, the more that is expected of you in terms of knowledge and it is reasonable for an experienced developer to have a good, but not necessarily perfect, understanding of all of these things.

Answer 5

I would say that you need to take it even a step further and learn everything you can about the environment around your language: the operating system, the hardware, the database, networking, everything. Some engineers are always learning, constantly buying books, constantly improving. Some aren't. Some people are content to stick with what they know if they are getting their job done with it. But give it some time, and those are the people who are sitting down in cubicle #8 waiting for you to tell them what to do next. It's not a mentality that you can force on someone, but it is a mentality that is rewarded in this field.

Answer 6

This is a wrong question to ask at the wrong place. I bet everyone in the stackoverflow beta care about the tools of their trade to some extent.

Answer 7

Kristopher, I do admire your passion around this issue and empathize. I do tend to be more in line with Rob's thinking, specifically the use of Google/the Internet for accessing information about your language when needed.

In perhaps a tangential manner of thinking in relation to this issue, I generally feel most junior programmers are way out of touch with the underpinnings of how things work with languages, environments, protocols, even computers in general -- you name it. I think that underlying knowledge is so critical to designing well performing systems and writing good code, and goes back to having an understanding of why something is done a certain way as opposed to only how it is done.

I think it's become easier since Visual Basic ushered in the era of RAD development to the masses to screw things up more. This was a critically important event in software development, no doubt, but I think this path of evolution, while making good developers more productive, allows others to be productive enough without necessarily fully understanding what they are doing. Am I making sense?

I've always been a believer that if someone was a student of computer science, then they ought to be able to code in any language and understand the importance of knowing the nuances of differently languages. I think this may be perhaps more important than knowing all the keywords and syntactical forms (with Rob's notable exception).

So, I too have similar frustration with programmers who don't quite get what's really happening. I could add to your list of items:

• How many of those programmers don't know how HTTP works in its simplest form? How many of them don't know you can get RFC's online that specify all of these protocols and roll your own clients and servers and mail readers, etc?
• How many of those programmers don't understand why it's important to minimize your database calls or get as much data as you need in one round-trip to the database and ideally no more than is required? (Or for any remote call for that matter!)

These are a couple of my pet peeves. I'm sure there are more.

Answer 8

and then there's the question of either being a flexible coder, of a hardcore coder..

Answer 9

Having programmed for 28+ years and in many many languages I don't believe there are any that I knew every keyword (maybe C and Action) or all valid syntactic forms. I'm really strong in the environment that I work on (Windows) but there is a lot I don't now about management of memory, files, and OS resources in general.

I would say that a better way to look at it is not what they know, but how they behave when they don't know something. If your co-workers give up and complain then maybe it's definitely time to look for another job. If they do their best to learn and then ask for guidance/assistance, cut them some slack and help them out. You'll learn by doing that and so will they.

Answer 10

I'd say that perhaps one shouldn't know every keyword and valid syntactic form of the language they are working with, but they should know all the common ones, and when they encounter something new they should have a willingness to learn more about the particular keyword or syntactic form.

Having the correct reference material on hand, and using google to search for and learn about unfamiliar language features or implementation is important. I don't personally have a copy of the ISO C++ specification on hand, but because I write applications for Windows using C++ I always have a link to MSDN on hand.

God developers have a willingness to learn and have proper references at hand. I don't think every developer need be an expert, but they should at least have that quality and those resources.

Answer 11

I think I know the Java language very well. I work with it every day. I have 2 Sun certifications - one is directly related to language syntax, the other is about threads issues and how the heap is managed. And I always have the Java 1.6 javadoc page open.

Sadly, Java is the only language I know well, follow far behind by PL/SQL.

Answer 12

I think you're looking at the wrong criteria. Specifically, 3 of the 4 that you mention( keywords, syntax, official spec) are, I think, not terribly applicable to day-to-day work. For example, asking someone to identify all keywords would be a pointless question in a job interview, and a terrible measure of someone's skill level (I'm talking here only about detail - anyone who claims to know or uses daily a language without understanding its basic constructs is incompetent). I'd agree with you about knowledge about the languages environment/mem useage, etc.etc.

For example, years ago I took the (first) sun java cert. All language nitpick questions, totally pointless. Is it really necessary to know how 'a + b * c / d (x)' evaluates? Wouldn't you be more concerned with someone who wrote the statement out that way instead of writing clearly?

A better measure, I think, would be idiomatic use of the language and knowledge of common libraries and useage patterns. I wouldn't be concerned with someone who didn't know some aspect of a language as much as I'd be with someone who was busy re-inventing the wheel because they weren't aware of established libraries or practices.

Doesn't remember order of operations - who cares? Writing your own Queue implementation because you don't know the available library? scary.

Answer 13

To me in many ways it's the libraries. It's weird because you expect if you know the syntax works you should be able to figure out the rest easily.

But I recently taught myself python, and in terms of its syntax and structure it took me about half an hour to learn, if that. And I would think most competent programmers would be similar.

But if you asked me to write a complex program I would be constantly going to google to figure out how do I do something.

The simple truth is library discoverability in most environments suck. You have to get a feel for how they are structured, at that point you can start figuring out where things are by yourself, and you rely less on google.

This leads to an interesting point about .NET, I know the libraries really well, so I can pick up a new language, which uses those libraries really quickly. But if I can use Iron Python and write a complex program, but constantly rely on the .NET library, can I really say I'm competent in python?

To me, no. There must be a solid understanding of the standard libraries.

Answer 14

This is totally the wrong community to make this comment, but let me try anyway.

Even as you are frustrated with these coders for declining to make an effort to learn the details of your favourite programming language, they are getting frustrated with you for your wasting time becoming overly-expert in, what to them is, pointless arcana.

While learning the language may indeed make your code 20% smaller or run 20% faster (Caution: made up figures!), there is an opportunity cost involved in learning those details.

While you are reading ISO standards, your colleagues may be learning more general concepts that will help them throughout their programming career. I've lost track of the number of programming languages and operating systems I have produced code for. Some of them, I was a language lawyer for. Fat lot of good knowing the details of a programming language I haven't used in 15 years does me now. Whereas the time I spent learning more general skills continue to pay dividends: for example, Object Orientation, clear writing, and how to use a spreadsheet.

Your colleagues may be learning how to make better estimates. Many project managers would prefer a slower programmer who hit targets more precisely.

Your colleagues may be learning how to make a GUI more intuitive. Many customers would prefer a program that makes sense to them than one that is faster.

Your colleagues may be learning how to interact with each other. Many team members would prefer a friendly colleague than a ruthlessly efficient one.

Your colleagues may be spending more time with their loved ones. Many families would prefer a loving family member than one that can code 20% faster.

I am not arguing everyone should become a generalist. (It is great to have a language-lawyer on the team to consult when necessary.) However, neither should everyone become a specialist, and certainly they should not all be specialised in the same Language-Of-The-Day.

Answer 15

Man, I feel you. Really.

Let me share a piece of my life with you.

I work in a very small software house, that is, the owner, me and another colleague. The owner is a bit older than us, and left programming to take care of management and other stuff. His programming skills end with assembler and VB6.

My colleague is a former commercial employee who 3 or 4 years ago decided "hey, I will read some programming tutorials and tell around I'm a programmer" and so he got the job here. He says he's a C# programmer.

Then there's me. I did my first coding at the age of 6 on my C64. I kept on improving, studied all sort of new languages across the years, and now I'm quite good with OOP, software architecture, web standards and some other skills. My main language is C#. I got in this software house some time after my other colleague, that is, 2 years ago.

I'm the kind of person who thinks that what I coded yesterday sucks, and what I'm coding now is great, but tomorrow will suck too. I keep on studying best practices, paradigms, design patterns, I try to stay up to date as much as possible, I'm eager to use the new version of the .Net Framework everytime it's released.

My colleague uses .Net 3.5 or even 4.0 as if it were turbo pascal. No objects whatsoever, no ORM, no layer architecture, no resuable code, no Linq (he goes ballistic if I dare say Linq, and I still don't know why) just a lot of spaghetti code and copy and paste, with sql strings in the button clicks.. you get the picture. He calls himself a programmer. If I were to choose, I wouldn't give him a job as a programmer even if he was the last "programmer" in the world.

Still, my boss thinks he's a "precious resource" and also thinks that "I waste time with too much reasoning, checks, architecture, etc" and he hates when I want to use something new because "It's new, we don't know it, it's risky". He almost ate me when I dared do a small app in WPF instead of using the old WinForms.

So, what of all of this? I'm not that great programmer, I know so many who could teach me so much, but I'm sure I'm at least a billion times better than my colleague. Still, he looks like "more valuable" than me.

Makes you think, doesn't it?