Graham's thoughts

When building role-based access control (RBAC), roles are not "attributes" on users. They are connections between users and resources.

Is this user an "admin"? No, they are an admin at this organization.

Is this user an "editor"? No, they are an editor on this project.

Roles get a lot of attention, but ultimately they are join tables. That's how we should think about them.

Most software engineers with a couple years of experience know that Rewriting Is Bad. But we go ahead and do it anyway. Why?

Was just reading this piece by Tim Cochran of ThoughtWorks -- it's interesting, although definitely uses its fair share of buzzwords. One thing that rings extremely true is the idea of "quick feedback loops".

As a developer, you want to be able to make changes and test that they work in as little time as possible. When builds take a long time, even 15 seconds, you lose focus: you check slack, you switch terminals to check on something else, you open your phone.

It can seem like a waste of time to spend many hours or even weeks optimizing a 15-second build to take 3 seconds (after all, it's only a difference of 12 seconds), but you're not just saving 12 seconds on every build -- you're saving your flow. Every time you make a change, you stay on task. You may even find yourself making more changes, testing more cases, and writing better code.

Optimize your build times!

Programming is just parsing input, crunching data, and formatting output.

Reading is more about time than it is about page count. What’s important is to let yourself think fully about the content of the text for a long period of time. Skimming doesn’t give you this.

We don't need 5 options when rating most things. Most people either give one star (I didn't like it), 5 stars (I liked it), or they give something between 3-4 (not perfect, but I don't want the rating to change).

Really, we should only give users those three options: Bad, Good, Don't Care. In other words, I want the rating to go down, I want it to go up, or I want it not to change.

I've started using quotes a lot (maybe too much) in my written communication:

Every day a process runs that moves users to the phase they “should” be in.

Instead of editing the spreadsheet directly, it's easiest to “fork” it by making a copy.

We could write some sort of listener that waits for each “service” to be ready.

I've been trying to think about exactly what I mean when I do that.

They're not strictly required--all of those sentences make some sense without quotations. But, I think they help communicate that a word does not map directly to its definition in the English language, but rather to some arbitrary concept that we've assigned meaning to.

Users don't always end up in the phase they should be in: they end up in the phase they "should" be in. You're not really forking the spreadsheet when you make a copy of it: you're "forking" it. We're not really talking about services: we're talking about "services". These are concepts that perhaps don't officially exist here, but the quotes allow them to exist with a temporary definition for this particular communication.

Programming doesn't take a long time; making decisions takes a long time. Convincing others that your decisions are correct takes the most time of all.

Black lives matter

If you're building a feature that requires a database migration, ship the migration first in as small a change as possible. If you can, write just enough code to make the old system compatible with the new schema.

Then, once the migration is safely applied, build the actual feature.

Code reviews are easier when additions >> deletions OR deletions >> additions, but not when they’re both large. If you can, separate big additions from big deletions.

MySQL everybody:

SELECT "hello" = "Hello";
# => 1

Only rewrite a system you know front to back.

If you're refactoring some code you wrote a week ago, you can write 1000 lines in an afternoon. If you're tweaking a feature in a 10-year-old codebase whose author left the company, even a one line change can take a whole day.

Programming speed doesn't come from skill. It comes from familiarity with the system. Skill just helps you get familiar with more systems faster.

For some reason it never occurred to me until my new job that you can count children using a JOIN instead of a subquery. It's useful for filtering results that do or do not have children.

Finding all parents with no children:

SELECT parent.id
    FROM parent
    JOIN child ON child.parent_id = parent.id
    WHERE child.id IS NULL;

I look forward to looking back on these thoughts and judging my past self.