The Boss’s Opinion

It’s called framing: The way you start a conversation sets its direction. The person you’re talking to reacts to the first thing you say. Unless your partner quickly responds with “whoa, let’s talk about something else” or “let’s approach this from a different angle”, the way you start a conversation strongly affects where it goes.

This is extra true when you’re in a position of authority. Your opening to a conversation still sets its context. But also: People are watching you, looking for your intentions and opinions. They’ll make best guesses about your perspective, and then they will be less likely to offer conflicting opinions. The more different an alternative is from your perceived preferences, the less likely it is that someone you have authority over will bring that option up.

People new to authority often say this drives them nuts. They dearly miss honest and direct feedback.

(To people without authority, of course, this trade-off tends to sound tolerable.)

Are You Serving The Project Or The People?

Working as a developer, you usually don’t own the product. Your involvement with it might just be a small part of its lifecycle. You join the project for a while, try to do some good, and eventually step out, moving on to the next thing.

This happens with people, too. You might work with someone for a long time or a short time, depending on their moves and your moves. You work alongside them for a while, try to do some good, and eventually step away, moving on to the next team.

That “try to do some good” part can involve helping the product get better, and it can involve helping the people get better. Those aren’t mutually exclusive, but sometimes they do conflict: Should we slow down a bit and help Bob learn this new thing, or do we really just need to get this work done, now now now?

And sometimes, on a terrible project, in an awful business context, you can still find great fulfillment by serving your teammates.

10x

  • A programmer could be ten times as productive as the average programmer in terms of lines of code produced over time.
  • A programmer could be ten times as productive as the average programmer in terms of quality code (whatever that means) produced over time.
  • A programmer could be ten times as productive as the average programmer in terms of features (whatever that means) delivered over time.
  • A programmer could be ten times as productive as the average programmer in terms of business value (whatever that means) produced.
  • A programmer could be a good leader or mentor, raising the technical game of those around her, and thus raising the output of a whole team.
  • A programmer could be a good manager or communicator, raising the game of those around her by identifying bureaucratic hurdles and clearing them for a team doing important technical work.
  • A programmer could be a good analyst, raising the game of a business. For example, by discovering that a problem a team is working on doesn’t need to be solved with code, or doesn’t need to be solved at all to accomplish the real goal.

Not Perfect Yet

Here’s an excuse for not finishing that will always work: It’s not perfect yet.

I can’t publish the article because I want to think of a better way to structure this one paragraph, so people will get it.

I can’t release the product because it might need this one last little feature for people to want it.

We’re holding off having a kid because the time isn’t quite right yet.

The time is never just right. Perfect isn’t a thing. Good enough is a thing.

Perfectionism is a sneaky form of procrastination. It’s sneaky because you won’t feel like you’re procrastinating when you’re actively working. Especially when you’re working hard.

When you work well past the point where you should ship, when you think of reason after reason not to be done when you should be done, you’re postponing needlessly. You’re procrastinating. You’re denying yourself valuable feedback that you can use to decide what you should do next, rather than gold plating the last important thing.

Tagged Template Literals

Tagged template literals let you direct the output of a template literal using a function:

function myTag(strings, firstName, lastName) {
  return strings[0] +
    firstName +
    strings[1] +
    lastName;
}

let first = 'Davy';
let last = 'Crockett';

console.log(myTag`First Name: ${first}, Last Name: ${last}`);

// prints "First Name: Davy, Last Name: Crockett"

Another way of thinking about this: untagged template strings do string concatenation, and tagged template strings do something else. That something else is defined by the function you use as a tag. Your something else may include string concatenation. It doesn’t have to, though.

The first argument passed to the tag function will be an array of the string parts of the template literal. The subsequent arguments will be each of the evaluated expressions. In the above case, strings holds all the strings, firstName holds the value that comes from ${first}, and lastName holds the value that comes from ${last}.

Let’s get fancy. Here’s a tag function that does the same thing as an untagged template:

function concatTag(strings, ...values) {
  let result = '';

  for (let i = 0; i < strings.length; i++) {
    result += strings[i];

    if (values[i] !== undefined) {
      result += values[i];
    }
  }

  return result;
}

let first = 'Davy';
let last = 'Crockett';

console.log(concatTag`First Name: ${first}, Last Name: ${last}!`);

// prints "First Name: Davy, Last Name: Crockett!"

Note that we’ve used the rest parameter ...values in this new tag. This gives us a convenient array of all the expression values passed into the tag function so we can handle any number of them.

We can thus loop through all the strings and values to construct our result.

Now let’s get a little more practical. Let’s write a tag that actually does something useful. What if I want to make sure my dynamic values are HTML-escaped?

function escapeHtml(target) {
  return target.replace(/</g, '&lt;')
    .replace(/>/g, "&gt;");
}

function htmlEscapeTag(strings, ...values) {
  let result = '';

  for (let i = 0; i < strings.length; i++) {
    result += strings[i];
    if (values[i] !== undefined) {
      result += escapeHtml(values[i]);
    }
  }

  return result;
}

let first = '<span>Davy</span>';
let last = '<span>Crockett</span>';

console.log(htmlEscapeTag`First Name: ${first}, Last Name: ${last}`);

// prints "First Name: &lt;span&gt;Davy&lt;/span&gt;, Last Name: &lt;span&gt;Crockett&lt;/span&gt;" Nice.

Continuous Partial Inattention

Turn off your notifications.

Designate time to check things if you must. But don’t let them drive you from minute to minute.

If you try to pay attention to everything, you’ll pay too little attention to anything.

When you say yes to everything, you spread yourself thin. You don’t focus on what’s important. You don’t do anything as well as you could. You’ll just get through your day.

Set aside time to go deep with the important stuff. And turn off your notifications so they can’t drag you kicking and screaming from the important back into the merely urgent.

JavaScript Template Literals

When you compose a string from multiple other strings and values in JavaScript, things can get ugly.

function logError(error, date) {
  console.log('Error: ' + error.message + ', ' + date.toString());
}

logError(new Error('Something went wrong!'), new Date());

This is already not pleasant with two values. It gets even worse as you introduce more.

ECMAScript 2015 introduced template literals, which can help make this sort of thing a bit more readable:

function logErrorTemplated(error, date) {
  console.log(`Error: ${error.message}, ${date.toString()}`);
}

logErrorTemplated(new Error('Something went wrong!'), new Date());

Pretty straightforward: A template literal uses backticks instead of quotes, and you can embed expressions into it using ${}.

You can also use newline characters in a template literal without having to insert \n.

console.log('Line one\nLine two');

…can become…

console.log(`Line one
Line two`);

…or if you prefer…

console.log(`Line one\nLine two`);

All three of these produce the same output.

Destructuring JavaScript Configuration Objects

Destructuring Assignment In Javascript introduces the concept and syntax of destructuring assignment, but leaves an important question unanswered: Why should you care?

Here’s one scenario where it might be nice: when you’re using configuration objects.

Lots of JS functions take a single object with multiple optional properties. You might think of these as “configuration objects” or “options parameters” or something along those lines.

Think about when you do this:

$.ajax({
  url: 'https://localhost/getSomeStuff',
  cache: false,
  dataType: 'json',
  timeout: 5000
});

You’re passing a bunch of values into $.ajax via properties of the single object you pass into it. Each of those properties is optional. (But $.ajax does have default values for all those things.)

What does $.ajax have to do to handle those things? (I’ll butcher this. Bear with me.)

function ajax(options) {
  options = options !== undefined ? options : {};
  let url = options.url !== undefined ? options.url : '';
  let cache = options.cache !== undefined ? options.cache : true;
  let dataType = options.dataType !== undefined ? options.dataType : 'text';
  let timeout = options.timeout !== undefined ? options.timeout : 0;

  // now do stuff...
}

It takes the single options parameter and defines a bunch of local variables from properties of options, falling back to default values when those properties aren’t present. Then it does its AJAX-y magic, blah blah blah.

Destructuring assignment and default parameters can make this a little cleaner:

function ajax({
  url = '',
  cache = true,
  dataType = 'text',
  timeout = 0
} = {}) {
  // now do stuff...
}

This version of ajax replaces the options parameter from our first implementation with a destructuring assignment that defines and initializes the local variables url, cache, dataType and timeout. Clearly there’s much less code here. Lots of folks will find this version preferable.

Two Ways Your Writing Has Value

Writing is good for structuring your thoughts. That part of it is value to you.

The other part is value to someone else. For them to get that value, they have to read what you wrote and understand it.

Both of these things end up better if you work hard to clarify. The second requires perspective-taking.

Twitter Tricked Me

Twitter tricked me into thinking all I need to do to absorb wisdom is click a little star. (Or a heart.)

That’s not how it works. Wisdom is hard-won. And fleeting. It can’t just be handed to you. You can’t just read an aphorism or a quote or a blog post.

Then Twitter tricked me into thinking all I need to do to absorb an idea is express it in 140 characters.

Also not how it works. I get more out of expanding an idea than I do out of expressing it elegantly. Thinking about examples or ways to restate it forces me to chew on it.