There are (number? 2) types of programmers in the world, those who understand the lambda calculus and those who do not. It is widely believed that the former are superior to the latter. Since success in your career depends on being viewed as superior to the other programmers who you compete against for jobs, raises and promotions, I'm going to teach you everything you need to know about the lambda calculus in five bite sized portions.
One of the most important things about functions in programming is that they implement abstraction, which helps us to manage complexity. If you have a library function that returns the square root of a number, you don't need to know how it's implemented. It doesn't really matter to the caller if the function calculates the square root directly, forwards the request to a different library function or sends a query to WolframAlpha as long as the desired result is returned in a timely manner.
Your function is to convince your manager that you're a valuable employee. Your manager doesn't need to know if you've accomplished this by actually doing a good job, bribing people to say nice things about you or by using relentlessly dishonest self-promotion. It does matter to you though, and you should remember that while doing a good job is hard and bribery is expensive, bald-faced lies are free and the consequences of can be avoided via Just-In-Time transfers to another group.
A good place to start is by convincing people that you have a thorough grounding in the theoretical underpinnings of computer science. Memorize the definition of the lambda calculus above and practice saying it in a way that implies you know what you're talking about. It may help to practice in front of a mirror.
The formal, academic definition of a functional programming language is Any language L such that the first program P that you learn to write in L is one such that P calculates a factorial instead of printing 'Hello, world'. One important implication of this definition is that gratuitous overuse of the phrase "such that" just screams "I have a PhD in computer science!" Another, more subtle implication is that functional programming uses recursive functions.
Of course, functional programming is not used in the real world because writing an infinitely recursive function will cause your program to run out of stack space and crash. Academics address this problem via a hypothetical construct called a "Turing Machine" that has an infinite amount of memory, allowing the infinite recursion to actually be infinite. This gets them tenure. Working programmers sneer at imaginary machines and use loops instead, a technique that enables them to write functions that never return on hardware that is generally available today. This gets them bug reports. This may seem like a bad thing, but since programmers are usually judged based on the number of bug fixes they do, it's critical that they produce code with lots of simple, but serious bugs that they can then fix.
You may be wondering why I'm talking about functional programming if you'll never use it. This leads me to my next point...
Dysfunctional programming is where you paste code you found on the internet into the middle of your function body and then fiddle with the curly braces until they match, all the while praying that A) it works and B) nobody is looking. Advanced dysfunctional programmers ask others for help with a problem in the hopes of tricking them into writing code. Hopefully you're smart enough to either avoid doing this on mailing lists your coworkers subscribe to or to use an assumed name, but eventually people begin to catch on.
Fortunately, dysfunctional programming is impossible in functional languages because the only code samples available on the internet are ones that show you how to calculate a factorial. It's also no use asking a functional programming expert how to solve a particular program, because he'll just invent a new functional language specially tailored to your problem and then show you how to calculate a factorial with it (this is why there are more functional languages than functional language users). It turns out that people who like functional programming are, without exception, idiot savants who believe that factorial calculation is a 5 billion dollar a year industry while simultaneously finding it trivial to derive techniques for doing network I/O from a factorial tutorial.
If people are beginning to suspect you of dysfunctional programming, you can allay their suspicions by casually saying something like "I was really excited about F# when it was announced, but now it just makes me appreciate the elegance of Monads in Haskell even more." Invariably they will gain a tremendous respect for you and wonder how they could have been so wrong. As before, it may help to practice this phrase in front of a mirror.
Back in the day, the good CS schools taught an introductory class on the lambda calculus, recursion and functional programming using the language scheme. Thus pretending to have learned scheme will imply that you went to a good school, as long as people don't know you well enough to realize that you dropped out of high school and spent your twenties getting fired for gross misconduct for reasons you can't remember because the whole decade is an impenetrable haze of Percocet and cheap bourbon. You know, hypothetically speaking...
Anyway, you can fake this by saying something like "I remember the enthusiasm I had as a freshman learning scheme. Some days I feel like that about my job, but today is not one of those days." Don't practice this one in front of a mirror as it's more effective when it seems spontaneous.
Don't get this wrong, people will know you're faking.
That's it; you're now an expert on the practical application of the lambda calculus.
Join me again next week as I demonstrate how to calculate a factorial in the new programming language I've been working on.