I find myself aiding novice programmers relatively often; explaining why their code won't work when they ask, suggesting solutions and the like. The people I'm helping do have a formal education in programming from a first-year degree-level module, in Java, but I feel like I can't communicate with them very well.

For example: one might write a function but not understand why it isn't executed, not realising they forgot to call it. If I use phrases like "(make a) call (to) the function/it" and "pass it the.." I get blank looks.

My normal process then would be to find some place in their code where they call a function from the language, and tell them they can call their own functions in the same way as they called this other function. Sometimes even that gets blank looks.

Are there other pieces of vocabulary that are more suited to (better for?) helping novice programmers? Or is this not an issue of communication?

  • 5
    Spreadsheet users know how to call a function. Many can write their own. There's something fundamentally wrong here.
    – JeffO
    Feb 24 '12 at 3:02
  • @JeffO I had been feeling something was amiss, but wanted to give that module and those people the benefit of the doubt
    – Andy Hunt
    Feb 24 '12 at 3:07
  • 7
    Wait, what? Programmers you're working with don't know what 'calling a function' and passing arguments means? That's as basic as you can go without drawing them pictures and using metaphors involving cats and dogs. This goes beyond a communication issue and unfortunately might be an issue with lack of knowledge. I reread your question and it seems like they basically took an introductory level course and that's it?
    – 逆さま
    Feb 24 '12 at 3:55
  • 3
    @AndyBursh: how did such students get it to the second year? Hope they won't pass the exams and choose a job outside software development.
    – Doc Brown
    Feb 24 '12 at 7:16
  • 3
    Perhaps sock puppets would help
    – MattDavey
    Feb 24 '12 at 10:03

They'll have to learn the proper terms eventually, the sooner the better.

Use them correctly, and explain them whenever you get a blank stare. Just try to send the right signals, that it's OK to ask about anything they don't understand - the only stupid questions are those you don't ask.

  • 2
    I was about to post almost exactly the same response then yours loaded. :) +1 Feb 24 '12 at 9:06
  • Don't bring explanations down to their level, bring their level up.
    – Bent
    Jul 1 '18 at 10:23

In general

When a person doesn't understand you, you have two alternatives:

  1. Adapt the vocabulary according to what the person knows or not,

  2. Explain to the person the terms she doesn't understand.

The first case works well when the person knows already the technical vocabulary quite well, but not enough, or not in your domain.

For example, you may use the term method in C# or Java, and the person who mostly works with some other language would not understand this term. You will then explain that in C# or Java, method is referring to what we usually call function (for example in C), and that there is no such a thing as function in C# or Java. In PHP, for example, both methods and functions exist, and have a different meaning. If the difference is too painful for the person, you will talk about functions for the sake of simplicity.

In your precise case, you can hardly choose the first one: "make a call to the function" cannot be reformulated in any simpler way. A call is a call. You can't simplify this more.

This means that you have to choose the second way: explain to the person each technical term.

  1. Either point the person to a dictionary or Wikipedia, which works very well for basic concepts and terminology.

    I would choose this for commonly used terms. For example, I would rather invite the person to read Wikipedia to understand what is polymorphism, or what are covariance and contravariance. Those terms are already explained very well, so don't need to reinvent the wheel here.

  2. Or explain in your own words.

    I would choose this for terms which are specific to the context and/or accepting wide range of definitions. For example, Wikipedia is not very helpful to understand the Microsoft's vision of cloud computing, and I would rather explain myself what is cloud to somebody who will be working on a Windows Azure application.

In your particular case

The people you are talking to are lacking the most basic concepts and terms used in programming. They can't continue without learning this core vocabulary, because they are unable to communicate at all: they can't read books about programming or blogs, they can't listen to their colleagues, and they even can't really ask questions on Stack Exchange websites, since nobody will understand what they are asking.

In your case, rather than searching for suitable vocabulary, I would spend a few days or weeks teaching them some core programming concepts and the commonly used terms. After a few days, you will be able to talk to them without being required to constantly "draw them pictures and use metaphors involving cats and dogs".


Instead of functions, start with subroutines. Tell them that a program is just a list of instructions, a recipe to tell the computer how to do something. And that it is being executed one instruction after another (with a possibility to make some steps in parallel, but more about that later).

Some tasks are quite common and repetitive, so it would be terrible if we had to always write them down again and again, so we write them just once and make a "smaller program" out of it – a subroutine, that can be reused by other parts of the program. In order to be able to execute it more than once, we give it a meaningful name in our program. And then we can use that name when we want to execute this "little program" as part of a bigger one, by calling it by that name.

Calling a subroutine is like summoning a demon who knows how to perform that task, by the name of that demon. So when we want to do that particular task in our program, we write "call the demon named Argoth", and the demon shows up and does the task for us as we instructed him to do, and then goes away and we can continue our job.

Sometimes the demon requires some additional information without which he cannot decide which of the tasks to perform, or what we really want from him. E.g. if the demon is supposed to build a castle, he may need to know where he is supposed to build it, or how big, etc. Those are the arguments passed to the demon... I mean, the subroutine, which now becomes parametrized.

Parameters are those pieces of information that are missing, but required, in order to do the task. They change what the subroutine can do by a little bit. They are like blank slots in the recipe that need to be filled in before we could execute it.

Arguments, on the other hand, are the actual information (values) that we supply for these parameters.

As for parallel execution, we can think of it this way: there's always someone (or something) that is executing the program (the list of instructions). It's either another human being (did you know that "computer" was once a name for a person who was performing the computation?), or a machine. A program is just a list of instructions, it doesn't work on its own. There must be someone or something who will do the computational process (perform these actions from the list). And sometimes these actions can be done in parallel – we can distribute the copies of the list to several people and let each of them do a different set of tasks from the list, as long as they don't interrupt each other, or don't have to wait for the results of someone else's work. That's multithreading for you ;)

As for the difference between functions and subroutines (also called procedures), the usual difference is that a function is being called to calculate a certain value which it returns as a result of its execution, while procedures are being executed just for fun ;) AKA for their "side effects" – just for the sake of the operations performed from the list.

But if calling a procedure or function causes some trouble at first, you can use another term that was once popular: jumping. One can jump into a subroutine, which means that you stop executing whatever you're doing right now, and "jumping" to another place on the list (or another list whatsoever) – the subroutine – in order to perform its tasks. Then, when you finish, you "jump back" – that is, you return to the place you've been interrupted, so that you could continue with your previous task. The difference between calling and jumping is that now you are the demon.

As for methods mentioned here by someone, or the fact that some languages "doesn't have functions, only methods" – that's not quite correct, because methods are functions! – a special kind of them: they are functions that are being used to retrieve some information encapsulated inside an object, or operate on them. They are a "method of operating on those data". The name came from object-oriented paradigm in which data are enclosed withing objects and cannot be operated directly, only by special functions called "methods".

A method is special in a certain other way: it has to know which particular object it is supposed to operate/be called on (the "this" object). That's why methods are usually embellished with an additional hidden parameter that stores information about the object upon which it has been called (the "this" pointer). This complicates the way the function is being called a bit, but it's an "implementation detail" a programmer shouldn't bother much, as long as he knows what he's doing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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