Reading Notes, August 2019

Article: “Using a Custom OAuth Provider with NetlifyCMS” by Tyler Gaw

To use a GitHub backend with NetlifyCMS, you have to have your own server to handle OAuth. This is a requirement of GitHub’s authentication flow. The good news about that, is that it’s a standard OAuth flow. The bad news about that, is that it’s a standard OAuth flow.

This is what I love about Tyler’s writing. So approachable. He writes how my brain thinks and my heart feels when I’m trying to wrangle computers to do stuff.

What I needed to do was build my own server to handle the OAuth flow. This is a thing I’ve done and written about before. OAuth is like that for me. I set it up. Deploy it. Forget it. Then have to give myself a refresher to do again. That’s what the server example in this post is.

If you’re not following his writing, you should.

Article: “Career Path & Promotions” by Jen Dary

There is no path. Even in large organizations that have salary bands and matrices…there is no path. There are precedents that have been set by other humans, but none of those are your path. Your path is the only one that’s authentic to you, the one that gets you excited on a Sunday night about the next morning. Your path is super-connected to your values, the way you appreciate the world and the vision you have for your contribution to it. What are you here to do? And how can you be doing more of it?

Always excellent advice from Jen. You should follow her writing too.

Article: “Education of a Programmer“

Just a couple little excerpts that stood out as timely for me.

On complexity:

I have struggled with complexity my entire career. Why do systems and apps get complex? Why doesn’t development within an application domain get easier over time as the infrastructure gets more powerful rather than getting harder and more constrained? In fact, one of our key approaches for managing complexity is to “walk away” and start fresh. Often new tools or languages force us to start from scratch which means that developers end up conflating the benefits of the tool with the benefits of the clean start. The clean start is what is fundamental. This is not to say that some new tool, platform or language might not be a great thing, but I can guarantee it will not solve the problem of complexity growth. The simplest way of controlling complexity growth is to build a smaller system with fewer developers.

On designing a functioning organization:

One dirty little secret you learn as you move up the management ladder is that you and your new peers aren’t suddenly smarter because you now have more responsibility. This reinforces that the organization as a whole better be smarter than the leader at the top. Empowering every level to own their decisions within a consistent framing is the key approach to making this true. Listening and making yourself accountable to the organization for articulating and explaining the reasoning behind your decisions is another key strategy. Surprisingly, fear of making a dumb decision can be a useful motivator for ensuring you articulate your reasoning clearly and make sure you listen to all inputs.

Article: “Look Around You ”

An interesting look at what the author believes is “a trend towards self-indulgence” that “can be summed up in two words: developer experience”.

This is the idea that investing in the whims and wants of developers allows them to build faster and cheaper, thus helping them deliver a better product – eventually. The excitement developers exhibit towards new technology can be infectious, but a magpie-like behaviour sees them flit and flirt from one framework to another, abandoning what’s been tried and tested, and throwing scorn on anything perceived as outdated. And there’s always another developer-focused feature to implement before the user experience can be addressed. As the complexity of digital software grows and the size of websites increases (weighed down by client-side libraries and privacy-invading scripts), it’s safe to say this argument amounts to little more than trickle-down ergonomics.

I really liked that phrase, “trickle-down ergonomics”. The author continues:

And now designers are getting in on the act. Concerned with order and beauty, and with a low tolerance for inconsistency and a penchant for unachievable perfection, efforts are now expended on the creation of all-encompassing design systems. An honest appraisal would acknowledge that the intended audience for these is not the customer but their colleagues. After all, a user focused on achieving a particular task is unlikely to notice a few stray pixels or inconsistent padding.

Article: “R.I.P.C.” by Paul Ford

On the non-user-friendliness of Linux:

Every operating system is a batch-card processing retro-mess underneath. Linux makes this a virtue to be celebrated rather than a sin to be hidden. I appreciate that. It’s nice not to have to pretend that computers actually are good, or work.

On the “personal” in “P.C.”:

My goal as a software person is to figure out ways to put “personal” back into the systems we discuss and build. “Efficient” or “slick” or “easy to deploy to AWS” are great things, but “empowering” and “gave me a feeling of real control” are even better.

Article: “Designing for actual performance”

There’s actually a lot of good stuff in here. It got the gears in my brain spinning on the possibilities for doing things “the old way” (I already wrote about some of that). But I wanted to save this particular quote about “unprogressive non-enhancement”.

You take some structured content, which follows the vertical flow of the document in a way that everyone understands.

Which people traverse easily by either dragging their scroll bar with their mouse, or operating the keyboard using the up and down keys, or using the spacebar.

Or if they're using a touch device, simply flicking backwards and forwards in that easy way that we've all become used to. What you do is you take that, and you fucking well leave it alone.