Author: josh

Here’s an unforeseen consequence of introducing a daily practice of writing publicly: I don’t just think about the blog when I sit down to write something for it. I think about it all day long.

When I have or hear an interesting idea now, it immediately gets put through a few new filters: Can this be a post? Would the audience find it interesting? Do I find it interesting? Is it broad enough to be a series of posts? Does it apply to something I’ve written about before? Is it a topic I know enough to be comfortable writing about? Do I want to dig deeper into the topic and maybe write about it down the road?

A few times I’ve even gotten a spark, stopped what I was doing, and written an entire draft, directly into my notes.

My mind carries around a set of rules about what it considers important. What’s important to notice, what I tend to think about by default, by habit. The rules are nebulous. I can’t list them for you. But this new daily practice has affected them. I like it.

Congratulations! You’ve learned a new thing. You’ve acquired knowledge, or maybe even wisdom.

But! Now that you know your precious new thing, as time passes, you’ll be less and less able you’ll be to understand the mindset of someone who doesn’t know it. This is true for everyone who knows the thing!

So you’ve actually become a really good candidate to teach the thing to somebody who doesn’t know it.

And! When you don’t understand the lecture, maybe you should ask the student next to you to explain it to you, rather than the professor.

Urgency is about how soon it will affect you. Importance is about how much it will affect you.

Urgent and important means it needs to be dealt with immediately and that not doing it (or not doing it well) will hurt, a lot. This is your mortgage bill.

Urgent but not important means an action needs to happen right now, but the wrong move won’t have huge effects. You can screw it up. You can even ignore it. This is your Netflix bill.

Important but not urgent means you can safely ignore it today and you won’t face any consequences. But if you do that every day, it’ll be really bad. This is your kid’s college fund.

And finally there’s not urgent and not important: Not doing the thing will not affect you at all, today or later on. This is checking Facebook.

Urgency and importance are not black and white, of course. There’s no such thing as 100% important or 100% urgent, or 0% important or 0% urgent. It’s all grey and subjective. Still, it’s useful when we make decisions and goals to consider these factors and to be conscious that they’re separate things.

Pure functions are mathy.

The sine function, sin(x), from your high school trigonometry class, is a pure function. The absolute value function is a pure function. Heck, adding two numbers together is a pure function.

Pure functions follow two rules:

1. No side effects. A pure function takes an input and returns an output, and has no effects elsewhere.

2. A pure function always returns the same thing for a given input. An addition function, given the inputs 2 and 3, never produces something other than 5.

Why should you care?

Rule number one means you can be confident that when you call a pure function, you won’t affect state elsewhere. It doesn’t write to a log or update a record in a database, or anything like that.

Rule number two means you can be confident that when you call a pure function, state elsewhere won’t affect you. Your result doesn’t change based on a configuration file or a property from another module, or anything like that.

This confidence makes pure functions easy to reason about. With no dependencies and no side effects to juggle, your brain is freed up to focus on the single thing your function is tasked with.

Pure functions lend themselves to simpler tests, too. With no dependencies to set up and no side effects to check, tests for a pure function tend to follow a simple pattern: send data into the function, check for the expected output.

Would you learn something better if I told you three examples that describe a pattern, or if I skipped that part and simply explained the pattern up front?

What if I explained the pattern up front, and then gave you the examples?

There’s not a right answer to this. People will have different answers. And we may not know ourselves well enough to give correct answers. Different answers might work better in different contexts, too.

How should this affect your strategy for teaching?

You’d want to know not just the thing you want to teach, but a bunch of meta information about the topic and the person and the situation and how that’ll all fit together well.

So maybe don’t be bummed if you don’t get it right on the first try.

As part of learning about a new library x, I’ll often do a Google search for “library x vs”.

The suggestions Google offers to complete my query are usually interesting, often valuable. They tend to show me popular alternatives. And the search results for any of those “x vs y” queries tend to give me good information about trade-offs. People on the Internet love to argue, especially about the relative merits of technical options.

Trying this right now with “underscore vs”, I can see it completes with “underscore vs lodash”. Entering “react vs” completes with “react vs angular”. “Scrum vs” completes with “scrum vs kanban”. “Mongo vs” completes with “mongo vs couch”. “C# vs” completes with “C# vs C++” and “C# vs Java”.

I can do this trick with concepts, too. “Dynamic language vs” completes with “dynamic language vs static language” and “dynamic language vs compiled language”. “Functional vs” completes with “functional vs object oriented”. “Recursion vs” completes with “recursion vs iteration”.

We all use search engines to give us general information about a term. This pattern is a way to ask a more specific question. I’d be interested in hearing about other useful patterns like this, if you have any personal favorites.

Here’s a situation I’ve encountered regularly for just about as long as I’ve been programming:

I try and try to solve an odd problem that just should not be happening. I don’t understand why the code is doing what it’s doing. I view and review it, step through it in a debugger, revert to a previous version. Despite all that, the root of the problem is still unclear. I’m banging my head against the wall all day.

At the end of the day, Nadya happens by and asks how I’m doing. Alright, I tell her, but I’m really frustrated with this issue. I start to describe my problem to her.

Thirty seconds into describing the problem, the solution comes to me. Nadya hasn’t said a word.

Sometimes just putting a problem into words can make us think about it differently. Describing it to someone requires us to consider the context and assumptions we have about it.

This pattern is known in some software development circles as rubber ducking, because I can just as easily describe my problem to a rubber duck sitting on my desk as to another human. It’s really a hack for my own brain.

Seth Godin’s blog is a favorite. And an inspiration. Here’s what I’ve learned from him:

“Write something for your tribe every day.” Every day. If you missed yesterday, who cares. Write today. If you come up with five things to write about on a given day, write them. Make a backlog. Then write again the next day. Write. Write. Write.

Your posts can be short. They just have to be valuable.

Post your writing publicly on a blog. The blog is a list of your posts, sorted by recency.

Create channels for folks to follow your blog content without having to remember to check your blog manually:

• Add an RSS feed to the blog.
• Add an email list to the blog.
• Create social media feeds that post links to your blog posts. (Some people want to follow you on their favored social media service, not via email or RSS.) This can and should be automated.

Make it easy for people to share your blog posts on social media.

Now you’ve created the following:

• Lots of content that you own.
• Multiple lists of people who’ve given you permission to put your new work in front of them.
• A destination for like-minded people looking for interesting content.

Recursion is when code calls itself.

In my first programming class, everyone thought recursion was hard. It’s hard for many of us to get our heads around at first. But we get used to it with a little practice.

The classic first recursive function is the factorial function.

(The factorial of a number n is the product of all positive integers less than or equal to n. The factorial of 0 is 1. The factorial of 1 is 1. The factorial of 2 is 2 * 1. The factorial of 3 is 3 * 2 * 1. The factorial of 4 is 4 * 3 * 2 * 1. And so on.)

Here’s an implementation of the factorial function in Javascript:

function factorial(n) {
    if (n === 0) {
        return 1;
    } else {
        return n * factorial(n - 1);
    }
}

A recursive function needs to avoid calling itself infinitely. It needs what’s called a “base case”, in which it does not call itself.

If I call factorial(0), no recursion happens. The value 1 is returned. This is the function’s base case.

The cases where the function does call itself are called “recursive cases”.

If I call factorial(1), n * factorial(n - 1) is returned. Since n = 1, this evaluates to 1 * factorial(1 - 1). That’s 1 * factorial(0), or 1 * 1. The value 1 is returned.

When this first recursive case gets hit, it calls the base case. The base case returns its value, and the recursive case gets that result and uses it to return a value.

If I call factorial(2), n * factorial(n - 1) is returned. Since n = 2, this evaluates to 2 * factorial(2 - 1). That’s 2 * factorial(1), or 2 * 1. The value 2 is returned.

This recursive case with n=2 calls the recursive case with n=1, which calls the base case, n=0, which stops the recursion. The n=0 case evaluates, which allows the n=1 case to evaluate, which allows the n=2 case to evaluate.

And so on. The call stack gets deeper when the numbers get higher, but the evaluation pattern just continues like this.

When I learned about recursion, walking carefully through the calls and evaluations helped me to understand what was going on. So I recommend that, if you’re new to the idea. Just working a few examples like this can quickly make you much more comfortable with the concept.

(Another simple, common recursion example you might try working through is a function that computes the nth Fibonacci number.)

“Users don’t care about software design.” – Straw man

Oh, but they do.

If your users care that your system will work tomorrow and the next day and six months from now and that it can be updated effectively and efficiently without stuff breaking all the time, then they care about good software design.

The factors that users know they care about are several steps removed from your design decisions, but the design vastly affects those factors. Indirect effects can still be enormous.