People are born every day who haven’t tried french fries yet. Lots of people have never ridden a bike, watched an episode of television, read The Lord of the Rings, written a line of code.
There are people who haven’t heard what you have to offer yet. If you find yourself thinking “everybody knows this”, you’re certainly wrong.
JavaScript has always allowed you to define default values for function parameters, but you had to jump through some hoops. You had to check whether an argument was provided. If it wasn’t provided, the parameter would be undefined. So you’d check whether the parameter was undefined, and if so, you’d set it to the default value you wanted.
Like so:
function addEndPunctuation(sentence, endPunctuation) {
if (typeof endPunctuation === 'undefined') {
endPunctuation = '.';
}
return sentence + endPunctuation;
}
ECMAScript 2015 introduces some nice new syntax for accomplishing the same result:
function addEndPunctuation(sentence, endPunctuation = '.') {
return sentence + endPunctuation;
}
Much cleaner.
Fun bonus: The new default parameter syntax allows you to use previous parameters as defaults!
Dig it:
function funkyFunc(foo = 'foo', bar = foo) {
console.log('foo: ' + foo);
console.log('bar: ' + bar);
}
funkyFunc(); // prints "foo: foo" and "bar: foo"
funkyFunc('bar'); // prints "foo: bar" and "bar: bar"
Neat.
When their problem is big, they might not want a solution.
They might not want to admit there’s a problem. It might make them look bad.
They might even be profiting from the problem’s continued existence.
Tread lightly.
If you’re a mathematician, a function is a sort of transformation, a mapping of a set of values onto another set of values. Each potential input value maps to an output value. I tend think of it as a little machine that turns its input into its output.
If you’re a programmer, a function is a subroutine, a named sequence of instructions. Some code you wrap up in braces and give a name to. You can call it.
It doesn’t feel like a stretch to suggest that the “functional” in “functional programming” refers to the mathematical definition. Functional programmers treat their subroutine-functions like math-functions: purity, no side effects, data-in-data-out.
It might even be useful to stop using the word “function” for procedures/subroutines. This’ll never happen, of course, but it’s an interesting thought. It could make these different concepts clearer.
Some advice for friends who’re thinking about giving conference talks in the near future: Make it yours. Add your voice to it, and not just a little.
If you don’t make your talk yours, it’ll be boring.
And when you do make it yours, you get to stop worrying about whether someone else would do a better job. Only you can give your talk when you put a piece of yourself into it.
Process often comes into existence as the result of a screwup. We put a rule in place to fix the problem next time. “We’ll prevent that from happening again,” we think. And maybe we will.
But perhaps we don’t consider the costs of having the rule, and whether they’re worth the safety. Especially long term.
Even less often do we take stock of all our process and consider whether we might benefit from getting rid of some of our rules.
When we add process reactively and only remove it proactively, we slowly bog ourselves down.
Have they come to you with a problem to solve, or with a solution to execute?
If they come to you with a problem to solve, they want your analysis and opinion. They want your expertise. That’s a lot of trust, and an opportunity to provide a lot of value. It’s a good gig.
If they come to you with a solution to execute, they’re not asking for your analysis and opinion. They want keystrokes, not expertise. That’s a lot less trust, and it’s less valuable.
You can try to give them your analysis anyway. You can ask why, ask what the problem behind the presumed solution is. But remember: That’s not what they’re asking for. It’s not what they want. You probably can’t help them if they don’t want your help.
That escalated quickly!
An earlier post describes how ECMAScript 2015 has introduced a new way to declare variables: let. A variable declared with let uses block scope instead of function scope.
ES2015 didn’t stop there, though. It also introduced another way to declare variables: const.
If you’re a programmer with a history in C/C++/C#/Java, the notion of a constant is probably familiar: A variable with a read-only value, a value that may not change.
Here’s a simple JavaScript const example:
const derp = 'foo';
derp = 'bar'; // causes an error
(The error I see in the Chrome console as I test drive this code: Uncaught TypeError: Assignment to constant variable. Nicely straightforward.)
Constants in typed, compiled languages are assigned at compile time. JS isn’t compiled, it’s interpreted. So const is a little different than we’re maybe used to. The value in a const doesn’t have to be known at compile time. It can be something dynamic. It just can’t change once it’s set.
function addDerp(target) {
return target + ' derp';
}
function foo(target) {
const result = addDerp(target);
return result;
}
console.log(foo('herp')); // works fine, prints 'herp derp'
Another thing to know about const: If you use it to declare an object or array, you can still perform operations on your variable without errors. You just can’t totally reassign to the variable.
With an object:
const obj = {
firstName: 'Joe',
lastName: 'Schmoe'
};
obj.firstName = 'Moe'; // works fine, assigns new value
obj = {}; // causes error
With an array:
const array = [];
array.push('it real good'); // works fine, pushes string onto array
array = []; // causes error
If you’re wondering: const uses block scope, like let.
Alright, so we’ve covered the what. Now to the why. To my mind, const is useful for two main reasons.
When the code says a value cannot change, we get to rule out the possibility of that value changing. This gives our brains a little break. Lots of little breaks like that add up.
When you can tell your compiler or interpreter that a value will not change, there are things it can do to optimize your code’s performance. (Disclaimer: I take this claim on faith a little bit. I don’t know much about the specifics of those optimizations.)
I’ve seen it suggested that const should be your default, let should be used only where you really can’t use const, and var should be used virtually never. I like the sound of that, but don’t feel strongly about it. (Yet?)
Even if you’re an employee, you can think of yourself as a free agent. Manage your career and your job on separate tracks. Your career is likely to last much longer.
It’s your responsibility to create a career for yourself, not your employer’s. Your relationship with any company is based on mutual interest. If they don’t have an interest in keeping you around, they won’t. You should remember that and approach the situation the same way.
You don’t have a job. A job is not a thing you have. A job is a thing you do. For now.
You have a set of skills. You have the ability to add to that set of skills, and to choose the direction in which you want it to grow.
You have a network and a reputation. You have the ability to add to that network. You have the ability to grow and improve that reputation.
The job is transient compared to the situation around it.
Explain Like I’m Five is simple: People ask questions, and people address them in simple terms, like they’re responding to a five-year-old. It’s wonderful.
If you want to teach somebody something, it’s helpful to put it in terms they’re comfortable with.
But it’s hard to take the perspective of someone who doesn’t know things that you’ve known for a long time. As you learn and layer knowledge on top of other knowledge, you take the lower-level stuff for granted.
Considering how you’d explain a thing to a five-year-old is a simple, brilliant shortcut to this kind of thinking. It doesn’t make the explaining easy, but it helps with focus. You center on what’s important and how to get it across in simple terms. You question your assumptions and your jargon.