Index of All Reading Notes


Reading Notes, April 2021

Video: Earthrise

A beautiful reflection on the story behind Apollo 8 and their capturing of the “earthrise” photograph—the first photo of Earth from space.

We didn't have any specific directions about the use of photography. We were all on the earth, so we all knew about the earth. They wanted photographs of something that was unusual [like] close-ups of the far side of the moon. The earth? It was strictly secondary.

More than the documentary details of the earth-rise photo, this is a musing on our existence in the cosmos.

Article: “Realign 2020: Realigned”

I made the classic mistake. I started out with small updates; type, color, logo. And published those posts after each chunk of work. But then? I made a mess. I made a git branch with the ominous name "rebuild." So, of course, that turned into an amorphous catch-all.

Been there. Done that.

That leads to feelings of lack of accomplishment and a constant feeling of something in the distance that you know you want to get to, but can't will yourself to move towards. I guess? I dunno? Who knows? What was I even talking about? Oh yeah. Web design.

Tyler updated his site and I absolutely love it.

Article: “Don’t think like a database”

If the data or the back-end requires you to do something, it doesn't mean that's how users should think about a problem. It's a common mistake in UI design...complexity on the back-end doesn't mean you should show that complexity on the front-end....

It's hard doing that though because first you have to understand the back-end. Then you have to unlearn it.

Like Robin, I struggle with this as well. There’s forever a tension between how the system works, how the end user thinks about the task they want to accomplish, and what timeline you have to bridge the gap between the two.

Article: “2021 Redesign or: How I Learned to Stop Art Directing and Love the Blog”

Art-directed blog posts are a trap. For instance, I have a silly little post about hair band albums that I've been nudging for months. I couldn't get it to look how I wanted, and I ended up scrapping the idea. Mind you, the post took about an hour to write. I could have pushed send at that point and gone on to the next post. I asked myself: how many more posts could I have written instead of trying ten different shades of 80s-inspired pink?

I realized that if I cared about publishing in any consistent manner, I'd have to give up the obsessive art-directed posts (which is hard to do when it's a creative outlet). So I decided to keep some flexibility to art direct; I'd just put up some constraints. Dave Rupert has a great (and practical) article about art-directed posts that made a lot of sense to me. Instead of giving myself total freedom, I've limited the number of decisions I can make. I can change the font, and I can change the color scheme.

Like Regan, I feel the tension of art directed posts being an impediment to publishing.

My goal (right now) is to write and publish, so I do it over and over. This helps me become better at writing and by extension thinking.

My goal (right now) is not to get better at making things look awesome. If that were my goal, I’d likely take on art directed posts again.

But there’s always that question: are people coming to your blog to read it or to look at it?

Article: CSS Working Group FAQs

I’ve never found myself with the need to use physical lengths in CSS such as in, or cm, or mm.

Nonetheless, I stumbled on this historical background describing why real-world units in CSS has been and will be a failure. I found it intriguing:

Originally, all the “real world” units were meant to be accurate physical measurements. However, in practice most people authored content for 96dpi screens (the de facto standard at the time of early CSS, at least on PCs) which gave a ratio of 1in = 96px, and when browsers changed that ratio because they were displaying on different types of screens, webpages that implicitly assumed the ratio was static had their layouts broken. This led us to fixing a precise 1in:96px ratio in the specs, and the rest of the physical units maintained their correct ratios with inches.

Later, Mozilla attempted to address this again, by adding a separate “mozmm” unit that represented real physical millimeters. This ran into the second problem with real physical units - it relies on the browser accurately knowing the actual size and resolution of your display. Some devices don't give that information; others lie and give info that's only approximately correct. Some displays literally cannot give this sort of information, such as displaying on a projector where the scale depends on the projection distance. Authors also used mozmm for things that didn't actually want or need to be in accurate physical units, so when mozmm and mm diverged, they were sized badly.

The overall conclusion is that trying to present accurate real-world units is a failure; browsers can't do it reliably, and authors often misuse them anyway, giving users a bad experience

Article: “Remote to who? A working letter”

Lots of folks online are linking to this article by Mandy Brown—and for good reason. Here’s what resonated with me:

I am not actually a fan of the “remote” terminology: I prefer to talk of teams as being either co-located or distributed, as those terms describe the team not the individual. After all, no one is remote all by themselves. But if we’re going to be stuck with that term, and it seems like we are, then we have to ask—remote to who? Perhaps you are remote to your colleagues, but you can be deeply embedded in your local community at the same time. Whereas in a co-located environment, you are embedded in your workplace and remote to your neighbors.

And then this:

Because if remote work gives us anything at all, it gives us the chance to root ourselves in a place that isn’t the workplace. It gives us the chance to really live in whatever place we have chosen to live—to live as neighbors and caretakers and organizers, to stop hoarding all of our creative and intellectual capacity for our employers and instead turn some of it towards building real political power in our communities.

And this:

As offices start to reopen there are going to be more and more pieces about the minority of CEOs who buck the trend of hybrid remote work and tell their entire staff to get back to their desks full-time. They will say it’s because collaboration and creativity are better when people are all in the same room, that the companies who continue to pay for expensive offices will end up with a competitive advantage. I promise you those CEOs are the ones looking at the balance sheet and doing a calculation in their head that says that even though remote work might save them millions on real estate, the transfer of power to their employees would be too great to make that a good deal.

Article: “How to make an ineffective 404 page”

If you make websites, a thing you should know is that complete redesigns are oftentimes political, and not stemming from user demand. It’s a move to claim ownership over those who came before you.

From now on, whenever I see a redesign announced to the world, I am going to ask myself: “hmmm...I wonder who is claiming control over what over in that business?”

Article: “Non-Fungible Taylor Swift”

It’s not that “art is important and rare”, and thus valuable, but rather that the artists themselves are important and rare, and impute value on whatever they wish.

I’m late to the Taylor Swift re-recoding her own album news, but found Ben’s take intriguing.

Quote: Edward Tufte and the data-to-ink ratio

Found here:

In the book The Visual Display of Quantitative Information, data visualization designer Edward Tufte introduced the data-ink ratio concept, which is the proportion of ink devoted to the non-redundant display of data-information.

From this, Tufte derives one of his most famous principles: “Erase non-data-ink, within a reason. Ink that fails to depict statistical information does not have much interest to the viewer of a graphic; in fact, sometimes such non-data-ink clutters up the data, as in the case of thick mesh of grid lines.”

Article: “Why Obama Fears for Our Democracy”

If we do not have the capacity to distinguish what’s true from what’s false, then by definition the marketplace of ideas doesn’t work. And by definition our democracy doesn’t work. We are entering into an epistemological crisis.

This excerpt is what drew me in to this interview. It’s long, but there were a number of insights in it that stuck out to me. I’ve noted some for myself elsewhere, but I wanted to note a few here in a professional vein.

First up, this observation about life being like high school is interesting. It might be maddening at first, but as Obama points out, it should be empowering:

You’re in high school and you see all the cliques and bullying and unfairness and superficiality, and you think, Once I’m grown up I won’t have to deal with that anymore. And then you get to the state legislature and you see all the nonsense and stupidity and pettiness. And then you get to Congress and then you get to the G20, and at each level you have this expectation that things are going to be more refined, more sophisticated, more thoughtful, rigorous, selfless, and it turns out it’s all still like high school. Human dynamics are surprisingly constant. They take different forms. It turns out that the same strengths people have—flaws and foibles that people have—run across cultures and are part of politics. This should be empowering for people.

Lastly, I wanted to note Obama’s own admitted disposition towards optimism intertwined with this idea of forgoing changing the world and instead iteratively improving the world;

I think it is possible to be optimistic as a choice without being naive...[However] being optimistic doesn’t mean that five times a day I don’t say, “We’re doomed.”...

The point I sometimes make [is] “Can we make things better?”

I used to explain to my staff after we had a long policy debate about anything, and we had to make a decision about X or Y, “Well, if we do this I understand we’re not getting everything we’re hoping for, but is this better?” And they say yes, and I say, “Well, better is good. Nothing wrong with better.”

Nothing wrong with better, indeed.


Reading Notes, March 2021

Podcast: Bill Gates on Armchair Expert

Dax, admitting his disposition to being a control freak, asks Bill how hard it was for him to learn to delegate and if it was one of Bill’s biggest challenges at Microsoft. Bill answers with an interesting and retrospective look at how he had to change his mental model, going from writing code to organization and orchestrating people (at about ~40:40):

Yeah, scaling [was] a huge challenge. At first I wrote all the code. Then I hired all the people that wrote the code and I looked at the code. Then, eventually, there was code that I didn’t look at and people that I didn’t hire. And the average quality per person is [went down], but the ability to have big impact is [went up]. And so that idea that a large company is imperfect in many ways [is true] and yet it’s the way to get out to the entire world and bring in all these mix of skills. Most people don't make that transition and there are times when you go “oh my god, I just want to write the code myself.” The famous thing I used to say is, “I could've come in and written that myself over the weekend.” Well, eventually I couldn’t.

Article: “What I think, not what I thought”

when you make it up as you go, you get to do what you think, not what you thought. All plans are rooted in the past — they're never what you think right now, they're what you thought back then. And at best, they're merely guesses about the future. I know a whole lot more about today, today, than I did three months ago. Why not take advantage of that reality?

I really like this—but that might be a biased take because it’s how I live my personal life. No life roadmap. Just some “big picture directional ideas”. To be honest, I’ll probably use Jason’s rationale here for how justifying how I live my life.

Video: “The Humane Representation of Thought” by Bret Victor

What he's worrying about is the engineering problem of: how do we build working, reliable systems out of this distributed, computational material. What I’m worrying about...is the humanist problem of: what should we build, why are we building it, what will we do with it, and what is it going to do to us?

It’s so easy to get caught up in the engineering minutiae—How will we do this? Is it even possible? Those humanist questions Bret outlines are great questions to ask yourself before you build anything.

Article: “Diagnose with Data. Treat with Design.”

Design and data are not at odds with one another. One helps you understand phenomena and gives you a foundation on which to build your assumptions. The other is the joyful process of creation to solve problems based on those assumptions.

Can’t believe I’m linking to something on LinkedIn, but here we are. Julie’s observations resonate with me. She continues:

If design intuition tells you that some experience is bad (because it's hard to use, it's confusing, etc.), TRUST the intuition...

If design intuition tells you that A works better than B at a large scale, be wary...

data helps you become a better designer. But data by itself does not lead to wonderful things. You still have to design them.

Article: “Preemptive Pluralization is (Probably) Not Evil”

Before you write any code — ask if you could ever possibly want multiple kinds of the thing you are coding...

It is a LOT easier to scale code from a cardinality of 2 to 3 than it is to refactor from a cardinality of 1 to 2...

I’ve seen this so many times, especially in places where I thought there would never be more than one. I like that swyx has a name for it.

Even at my current job, we’re working on a multi-year problem that shifts from a fundamental assumption of the platform that there’s only ever one of a thing, when now we’re realizing to keep pace with the market we need multiple.

It’s worth noting: you never see the cases where you don’t have to convert to more than one, so you feel the pain when you have to convert but the joy when you don’t have to.

Article: “Progressive enhancement and accessibility redux”

Josh Fremer being quoted on QuirksBlog on the topic of: "what's the difference between accessibility and progressive enhancement?"

I think of [progressive enhancement and accessibility] as the same process, but with different foci. Accessibility aims to optimize an experience across a spectrum of user capabilities. Progressive enhancement aims to optimize an experience across a spectrum of user agent capabilities...

What is the application of color to a website if not a progressive enhancement targeting user agents that can discern colors? Whether the "agent" in this case is the electronic device in the user's hands or the cells in their eyes is kind of moot. The principles of both PE and accessibility require us to consider the user who is unable to receive color information.

What an interesting idea: user agents being human beings or electronic devices, doesn't matter, it's all about starting with the most basic functionality and enhancing from there.

That’s an interesting concept to think about, especially in light of his Josh's final point:

a fun little thought experiment is to imagine a sci fi future in which users can plug computers directly into their brains, or swap their personalities into different bodies with different capabilities. This further blurs the line between what we traditionally call a "user agent" and a user's innate disabilities. "This web site is best viewed in a body with 20/20 vision and quick reflexes."

Video: Nadia Eghbal’s Talk for the Long Now Foundation

We have this myth that software is zero marginal cost, ignoring the complex human interdependencies that are required to maintain it.

I found this talk incredibly insightful. I need to get her book. She’s put a lot of thinking and research into the aspects of software that people often ignore: namely, every aspect of software that’s not building it. We always talk about creating software but never maintaining it:

“Write code and forget about it” simply isn't a realistic vision of what's required to make and move these systems. Software is brittle, unreliable, subject to breakage at all times, and an endless exercise in failing over and over again.

Article: “Phil Libin: Find a new way to ski”

An interview with the founder of Evernote:

What’s wrong with Silicon Valley

The business model being indirect revenue. It rewards keeping your users in a heightened, emotional state so that they hang around your platform for as many hours as possible, so they can click on ads.

The easiest emotional state to generate algorithmically is tribal outrage. It’s a simple and primal emotion. We, as the tech industry, have built a model that we make money when we piss people off. And everyone’s pissed off now, we’ve made a lot of money and people are like, what went wrong? Well, everything went exactly as planned.

Reductive, perhaps, but it resonates.

Article: “Material Design text fields are badly designed”

I’ve watched hundreds of people interact with forms and seen many of them struggle. But not once was that down to the use of a conventional text field.

It’s almost like we should choose boring technology UI.

Article: “Give me a definition for the word dashboard”

Eric Bailey, speaking on some research work he was doing designing a dashboard:

That dashboard would have been a month or so of work for me, but it would have been the participant's everyday experience for the foreseeable future. That's a huge responsibility.

As a designer, this is a good reminder of your impact on humans, irregardless of scale.

Article: “An alternative to competition”

I’m just really enjoying Jason’s blogging now that he’s got Hey World:

I don't think about competing. Competition is for sports, it's not for business.

HEY is simply an alternative...

And all we have to do is get enough customers to make our business work. That's it. That's how we stay alive. Not by taking marketshare away from anyone, not by siphoning off users, not by spending gobs of cash to convince people to switch. We simply have our own economics to worry about, and if we get that right, we're golden.

When you think of yourself as an alternative, rather than a competitor, you sidestep the grief, the comparison, the need to constantly measure up. Your costs are yours. Your business operates within its own set of requirements. Your reality is yours alone.


Reading Notes, February 2021

Video: Maciej Cegłowski, Pinboard - XOXO Festival (2013)

I do like this idea of complexity sneaking into our lives and having to actively fight it, almost like it's roaches or something.

Great talk. Funny and candid. A thoughtful rebuke of many commonplace ideas in tech today:

I mentioned perseverance because there's this pernicious idea that comes from startup world that you should "fail quickly". I've always been a proponent of failing really really slowly because if you aren't in it for the money you don't know when you've succeeded or if you might succeed. Success doesn't come labeled in any way to distinguish it from failure—unless you're in it for money in which case it's really easy to count your success.

Later he talks about how Thoreau wasn’t much of a success in his lifetime. Only later were the insights of his writings recognized as ahead of their time. Maciej then weaves that narrative into his own points about perseverance and being open with money when he sarcastically points out the absurdity of financials as a measure for his definition of “success”:

I earned $181,000 from pinboard last year, which is 23,000 times as successful as Henry David Thoreau. Not bad at all.

And then this:

[You should write things down because] experience is hard-won knowledge and you don't want to just let it get away.

And lastly this:

We can't depend on big companies to take a stand for us.

Podcast: ShopTalk Show #448

Great discussion herein on modern web tooling and the absolute chasm between trying to run a project with tooling vs. no tooling:

You’re no longer developing a web application. You’re developing a code base for producing that web application.

Article: “Hey, World!”

Email is the internet's oldest self-publishing platform. Billions of emails are "published" every day. Everyone knows how to do it, and everyone already can. The only limitation is that you have to define a private audience with everything you send. You've gotta write an email to: someone.

Email client as publishing platform: audience ranging from one to the entire internet. Fascinating take from Basecamp folks on publishing a blog. I think this will be great for lots of people who aren’t tech savvy and simply want to write stuff and publish it online. Not sure how they’ll handle basic blogging features in the future, like tagging and/or categorizing posts. Nonetheless, exciting to see them enter the blog space in an interesting way.

Article: “Tech Hostage”

The solution I've cobbled for us is that Julie (my partner) owns the music account that runs our bedroom and kitchen devices, I own a music account that's used on my desktop computer...my son is using an Alexa that's connected to his music account...and my daughter has a Google nest...signed in to a spare phone that's entirely signed in for her connected to her music account.

This Jenga tower of tech just about works, except my daughter can't control her lights from her device. "Make my room red!" she cheers to much disappointment from Daddy who explains: "I just can't work it out yet".

I am a goddamn hostage to tech.

This is why I have not yet put any smart tech in my house. Perhaps it’s an inevitability as my kids grow, but our music is a Bose CD/radio player, a record player, or an iPhone plugged in to my Bose and controlled manually. Maybe it’s simply because I grew up on them, but I really enjoy the experience of CDs. Plus they are incredibly cheap at thrift stores these days. Every album I ever wanted as a teen is now $1.00 at the thrift store.

Article: “The web is something different”

I’ve come to accept that if there are bugs on the web or if there’s a massive quality dip on a site you’re visiting…that is a sign the web is working. It means some unqualified person was able to skip past the gatekeepers and put something online. That’s a win for “The web is for everyone.”

Unbelievably great point and I agree wholeheartedly. Also loved this:

I wish we’d see the web more for itself, not defined by its nearest neighbor or navel-gazing over some hypothetical pathway we could have gone down decades ago.

Article: “HTML and CSS still isn’t about painting with code”

Browsers can’t break the web. They need to support the bleeding edge but also the sins of the past.

Great point by Christian Heilmann. Browsers, of all software, have it tough. Give ’em a break sometimes.

Article: “A few notes about A/B testing from Jared Spool”

[A/B testing is] seen as a cheap solution to doing hard work. I believe it’s not the panacea that everyone thinks it is.

A great summary of a twitter thread from Jared Spool on A/B testing. Resonates loudly with my experience.

Article: “Blogroll”

Cutting insight from Eric Bailey:

Blogrolls mostly fell on the wayside as the web matured and industrialized. In an era that is obsessed with conversion funnels, the idea that you’d want to provide a mechanism to voluntarily leave your website seems absurd.

Article: “Coaching Tools – The Narrative”

Love this post from Marty Cagan.

I’d like to discuss my single favorite coaching tool for helping product managers become exceptional: the written narrative.

Oh, you mean a spec?

I am not talking about a spec of any sort. A spec is not intended to be a persuasive piece – it’s just a document describing the details of what you want built.

Ah, ok, so not a spec. So what?

I’m talking about a document that describes the vision of what you’re trying to achieve, why this will be valuable for your customers and for your business, and your strategy for achieving this vision. If this narrative is done well, the reader will be both inspired and convinced.

I love the idea of a written narrative—mere prose, thoughtfully written paragraphs of text—for describing vision, value, and strategy. How and why can this be so effective? Because, as Stephenie Landry explains:

[With written narratives] you can’t hide behind complexity, you actually have to work through it.

You think you know something until you have to explain it—not in the way of specifying minute details for people, but in the way of inspiring, persuading, and including people.

Love this point, as well, by Brad Porter:

When I begin to write, I realize that my ‘thoughts’ are usually a jumble of half-baked, incoherent impulses strung together with gaping logical holes between them.

Article: “Apple Mail and Hidden Tracking Images”

Good reminder from Gruber that email clients are, unfortunately, web browsers without all the protections of an actual browser:

Don’t get me started on how predictable this entire privacy disaster [regarding spy pixels] was, once we lost the war over whether email messages should be plain text only or could contain embedded HTML. Effectively all email clients are web browsers now, yet don’t have any of the privacy protection features actual browsers do.


Reading Notes, January 2021

Article: “How I changed in 2020.”

I’m doing good work. Or am I? “Good” is whatever wins votes. Am I focusing on the wrong things? Does design even matter? What would other designers think if they saw my work? They’d probably laugh at it. None of this looks like the design industry’s idea of “good” design. Would they even think of this as “design” at all? Mostly I help make decisions about product behavior, but it’s all so invisible. How could anyone evaluate it? How am I supposed to measure my own self-worth with it?

Carolyn’s writing is incredibly refreshing:

But if the work of this year has taught me anything, it’s that getting something, anything out the door in time can make all the difference. Progress over perfection. One foot in front of the other. So here I am, telling an incomplete, imperfect, unsatisfying story, and sharing it with the world before it’s capital-R Ready.

Article: “Should The Web Expose Hardware Capabilities?”

An illuminating look at the security concerns of allowing third-party browsers in iOS. I always thought Apple's rule—“Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript.”—wasn’t so great. But there is an interesting security angle on this I’d never considered:

If an app could receive device access permissions, and then included its own framework that could execute code from any web site out there, [the requirement for “what’s changed” notes] in the app store review guidelines would become meaningless. Unlike apps, web sites don’t have to describe their features and product changes with every revision.

This becomes an even bigger problem when browsers ship experimental features...which are not yet considered a standard...By allowing apps to ship any web framework, the app store would essentially allow the “app” to run any unaudited code, or change the product completely, circumventing the store’s review process.

...when considering the current state of web standards, and how the dimension of trust and sandboxing around things like Bluetooth and USB is far from being solved, I don’t see how allowing apps to freely execute content from the web would be beneficial for users.

So interesting. There’s more:

Without drawing a line of “what’s a browser”, which is what the Apple app store essentially does, every app could ship its own web engine, lure the user to browse to any website using its in-app browser, and add whatever tracking code it wants...I agree that perhaps the line in the sand of “Only WebKit” is too harsh. What would be an alternative definition of a browser that wouldn’t create a backdoor for tracking user browsing?

The details in this piece helped me better understand the technical merits that Apple and Mozilla have on to their more defensive approach to building web browsers.

Article: “How I Build JavaScript Apps In 2021”

Lots in here that resonates with my own feelings on similar topics:

I still remember the debates with colleagues about using babel a few years ago. Within the front end development world, transpiling had just become a thing, so we ended up babelifying our builds to use ES6. Our argument back then was that one day, we would be able to push our application's directory structure on a web server and since all browsers would then support the augmented ES6 features, our app would just work! Without a build process. WOW! That must have been around 2015. When I look at the source code of these old applications now, our technical visions didn't end up becoming reality.

Looking back, I do find it interesting how babel was thought of (at least in some regards) as a polyfill: use it to write the latest and greatest and then, one day, simply remove it. [Narrator voice] but transpiling is a dangerous drug.

I also try to avoid transpiling. It's not because I don't like ESNext features, but more because I want to minimize the risk of getting stuck with the transpiler.

Article: “Against essential and accidental complexity”

Long before computers were invented, elders have been telling the next generation that they've done everything that there is to be done and that the next generation won't be able to achieve more. Even without knowing any specifics about programming, we can look at how well these kinds of arguments have held up historically and have decent confidence that the elders are not, in fact, correct this time.

...Brooks' 1986 claim that we've basically captured all the productivity gains high-level languages can provide isn't too different from an assembly language programmer saying the same thing in 1955, thinking that assembly is as good as any language can be and that his claims about other categories are similar. The main thing these claims demonstrate are a lack of imagination.

A good reminder, I would venture, that even core web technologies will be pushed in the future. You don’t have to accept everything that comes down the road of innovation, but being able and willing to keep an open imagination is what’s important.

Article: “Understanding the True Cost of Client-Side A/B Testing”

The full cost has to factor in both the price we’re paying for the service, as well as the impact it has on the business.

While specifically talking about A/B testing, this is a good reminder that nothing is free. Saying yes to one thing means saying no to many others. Cost is never solely composed of what does it cost for the thing I say yes to, but also what is the cost of saying no to all the other things?

Article: “Art Direction for Static Sites”

A neat behind the scenes look at how Dave does his own art directed blog posts. Personally, I think he strikes a great balance between customizability and maintainability, with an elegant yet simple approach to how much he can tune each individual page.

Dave’s piece really makes me want to do art direction. However, I’ve done it in the past and I always felt like the custom styling got in the way of writing and publishing. And right now, I want to write—a lot.

That said, if I ever do venture the path of art direction anew, I might try one-off posts. Like this:

If you want to go all out and create the weirdest page on the Internet, you don’t have to hijack the system. You can eject from your layout entirely by choosing not to specify a layout. That alone gets you most of the way there! A page can be a hand coded page that atrophies at its own pace away from the parent styles is a great way to limit your technical debt.

That speaks to me. Once I publish, I never have to touch it again unless I want to, not because my site changes (which, let’s be honest, it inevitably will, about a million more times).

Article: “The Prestige Trap”

The insights here resonated with me and the way I viewed my own decision making coming out of college—and I didn’t go to an Ivy League school, but a state college.

For the majority of Ivy Leaguers, the most impressive thing they've accomplished is achieving admission to their university. When you're deemed successful because you went to Harvard rather than celebrated for what got you there in the first place, you learn to game the system and just focus on the credentials the next time around.

And later:

Sometimes, achieving excellence even runs orthogonal to the certainty of prestige. For example, I saw within my own studies that getting an 'A' in a class was very different than actually learning the material. With an intense course load and impending deadlines, many students find it easier to take shortcuts to get the 'A' rather than to really grapple with the material which could take time away from learning how to game the test. The same problem happens within the workforce, except instead of getting an 'A' in a class, it's optimizing to get promoted during your annual review.

And yet later:

But what worries me most about the prestige trap are its effects on an individual level. While recruits may confuse a Stanford CS degree for evidence of world-class programming skills, the candidate won't. We know when we're optimizing for credentials vs. pursuing excellence for its own sake. There is something deeply fulfilling about the latter and rather unsatisfying about the former.

Lots of introspective insights here worth pondering.


Reading Notes, December 2020

Article: “Why it’s good for users that HTML, CSS and JS are separate languages”

The interesting thing about the web is that you never know who you’re building stuff for exactly. Even if you keep statistics. There are so many different users consuming web content. They all have different devices, OSes, screen sizes, default languages, assistive technologies, user preferences… Because of this huge variety, having the structure of web pages (or apps) expressed in a language that is just for structure is essential.

It is truly incredible just how many kinds of users are out there consuming HTML. Especially when you start to consider things like search engine spiders and content scrapers, they enable some pretty incredible things (like, for example, democracy). These are all capabilities that, in essence, rely on semantic markup. And it’s not just HTML. It’s CSS too:

responsive design worked, because CSS allowed HTML to be device-agnostic.

Article: “Validation is a mirage”

When I hear MVP, I don’t think Minimum Viable Product. I think Minimum Viable Pie. The food kind.

A slice of pie is all you need to evaluate the whole pie. It’s homogenous. But that’s not how products work. Products are a collection of interwoven parts, one dependent on another, one leading to another, one integrating with another. You can’t take a slice a product, ask people how they like it, and deduce they’ll like the rest of the product once you’ve completed it. All you learn is that they like or don’t like the slice you gave them.

If you want to see if something works, make it. The whole thing. The simplest version of the whole thing – that’s what version 1.0 is supposed to be. But make that, put it out there, and learn. If you want answers, you have to ask the question, and the question is: Market, what do you think of this completed version 1.0 of our product?

This whole post is so good:

Don’t mistake an impression of a piece of your product as a proxy for the whole truth. When you give someone a slice of something that isn’t homogenous, you’re asking them to guess. You can’t base certainty on that.

That said, there’s one common way to uncertainty: That’s to ask one more person their opinion. It’s easy to think the more opinions you have, the more certain you’ll be, but in practice it’s quite the opposite. If you ever want to be less sure of yourself, less confident in the outcome, just ask someone else what they think. It works every time.

Article: “Dave goes back to Mac”

If you’re someone who hasn’t touched a Windows machine in years—like myself—Dave’s commentary on switching back to Mac has some really good experiential perspective, including this insight on how access to the web might be universal, but the tools we use to build for it are not.

While the Web is Universal, the tools are not...Tools failed me this time around and I had to change my life to maintain progress. I know ubiquitous support is hard, but it’s so so so important for the Web that we keep the doors open and meet people where they are, meet them on their devices.

Article: “Growl in Retirement”

Gruber notes this crucial distinction about the design of Growl’s notification system:

Growl...served the notifyee, not the notifier, and that made all the difference.

I loved Growl. It was the notification polyfill for OSX: designed to become obsolete.

Video: Programming Should Eat Itself

The evaluator, which determines the meaning of expressions in a programming language, is just another program.

I honestly did not understand much of this talk. But what stood out to me the most—and what I wanted to note down—was the insight stated above. Or, to restate it from another point in the talk:

A program can have another program as data.

Article: “‘Real’ Programming Is an Elitist Myth”

I've always loved that moment when someone shows you the thing they built for tracking books they've read or for their jewelry business. Amateur software is magical because you can see the seams and how people wrestled the computer. Like outsider art.

I love making “amateur software” and “outsider art” as described here. The longer I work on the web, the more interested I find myself in my amateur, outsider software than anything else more “professional” that I’ve been employed to do in my career.

Article: “2020’S ‘The Dog Ate My Homework’ Universal Scapegoat: ‘The Algorithm’”

Gruber gives a fitting commentary on algorithms:

Blaming [this mess] on “the algorithm” is such ridiculous bullshit. What is an algorithm? It’s a set of rules and heuristics, created and decided by people. Blaming this on “the algorithm” is a shameless attempt to insinuate that they just put everyone into a system and the mean old computer decided to put front-line residents at the end of the list, when in fact, what they mean is, the people at Stanford who created the rules decided to put them at the end of the list. That’s their algorithm.

Website: “Epigrams in Programming”

Simplicity does not precede complexity, but follows it.

Motto for a research laboratory: What we work on today, others will first think of tomorrow.

The proof of a system's value is its existence.


Reading Notes, November 2020

Article: “Don’t Be A Hero”

Having that utopian vision of the world is important though. And being optimistic about making enormous change is important, too. But I’m learning that the truly wise folks hold that vision in their minds whilst making tiny incremental progress in that direction every single day

This reminded me of my experience learning to play the piano. You want to start out playing the incredible pieces written for piano—Beethoven’s “Moonlight Sonata”, Debussy’s “Clair de Lune”, Liszt’s “Hungarian Rhapsody No. 2”—but you quickly realize you can’t. So instead you practice over and over and over. Every day. And every day you practice, you can barely notice any improvement from when you started that day. But as time goes by, you notice drastic improvements week over week, month over month, year over year. Tiny, incremental, accumulative progress towards a goal is a powerful thing.

Website: carolynzhang.com

these days, i'm trying to not define myself by what i make, or what people pay me for.

Lovely new portfolio site.

Website: Ephemeralist by Paul Ford

First of all, what is it?

Ephemeralist [is] a web page that...pulls archives from places like the MoMA and the Smithsonian, and allows you to scroll through history—from books and fossils, to pictures of donkeys from the 1700s.

Paul talks about why he created the site on the Postlight Podcast:

I kinda did it just so when I’m going to bed I would have something to look at that would be distracting...And what’s better than old art and ridiculous ephemera? I like a lot of historical nonsense...

Article: “Reflections on software performance”

This feels relevant to reinventions that attempt to make the web faster (like AMP) vs. building in a leaner, more purposeful way with the tools we already have which have been optimized for performance gains.

There’s a general observation here: attempts to add performance to a slow system often add complexity, in the form of complex caching, distributed systems, or additional bookkeeping for fine-grainedincremental recomputation. These features add complexity and new classes of bugs, and also add overhead and make straight-line performance even worse, further increasing the problem.

When a tool is fast in the first place, these additional layers may be unnecessary to achieve acceptable overall performance, resulting in a system that is in net much simpler for a given level of performance.

That kind of perfectly describes Google’s AMP, does it not? It was an attempt to make the web faster, not by encouraging the proper use of web technologies already available but by reinventing the wheel, even to the point of changing URLs.

Video: “Oh The Scripts We'll Load” by Tim Kadelc

This in-depth analysis of loading scripts in the browser is filled with nerdy technical details.

For example, Tim tells this story about a team that was loading a giant bundle of JavaScript using the <script async> tag. To try and improve performance, they ruthlessly cut down the amount of JavaScript being shipped to the browser. They got the file size way down and...performance got worse! Do you know why? Watch this video to find out—or I’ll just tell you why: even though it was async, the giant mass of JavaScript was blocking the parser when it arrived, and because it was so much smaller than before, it was arriving earlier and thus blocking the parsing of the HTML document earlier and giving the appearance of slower performance. Hence Tim’s statement at one point in his talk:

Don't take anything as gospel. There will always be tradeoffs.

Article: “Learning from mistakes”

it's easy to write code you can understand now, but hard to write code you'll understand in six months. The best engineers I've worked with aren't the best because they know every API method under the sun, or because they can turn five lines of code into two with a clever reduce call, but because they write code that they (and their colleagues) can understand now and code that can be understood in the future...

How do these engineers get this ability? Experience. They don't foresee problems because they are able to look into a crystal ball...but because they've been there, done that, countless times.

A good reminder that we’re all here to fail. An “experienced” developer, designer, manager, etc., is just someone who has failed a lot—and learned from it.

Article: “The M1 Macs”

Gruber’s review of the M1 MacBook Air has this nugget which feels so relevant to product and software:

What you need to understand is that the best aspects of these Macs aren’t benchmark-able. It’s about how nice they are. The cooling system never making any noise doesn’t show up in a benchmark. I suppose you could assign it a decibel value in an anechoic chamber, but silent operation, and a palm rest that remains cool to the touch even under heavy load, aren’t quantities. They’re qualities. They’re just nice.

We’re always trying to quantify things that we can measure in order to show, with objective data, that they improved. But insanely great human-to-computer interaction isn’t solely a science. It’s also an art, which means the qualities you can’t or don’t measure have a huge impact.

Article: “The design systems between us.”

This line resonates:

design applications have made it much easier for designers to work together; development applications have made it easier for developers to work together.

But...the gap between each discipline’s workspace hasn’t changed significantly.


Reading Notes, October 2020

Article: “The Power of a Link” by Bryan Braun

I loved this little thought on the power of an <a> link. People are literally employed to write emails asking domain owners for an <a> link to their site in exchange for $$$.

A link, on the open internet, is a vote. It’s your way of saying, “this is great, and more people should know about it.” We talk about how much power the search engines have, but if you think about it, the search engines listen to us. They see what we link to, what we click, and how long we stay. At the end of the day, we are the curators of what gets surfaced on the internet.

This is, at least unconsciously, part of the reason why I indexed my blog’s links: it’s a reminder of the votes I’ve cast on the internet.

I continue to occasionally get emails from marketers asking me to link to their stuff. And while it’s annoying to receive spam, it’s also a reminder of the power I wield, just by having an independent website where I can link to whatever I want.

The power of links! Independent websites: seize the means of search rankings!

Article: “Why does this design crit hurt?” by Robin Rendle

When someone says “hey, this design doesn’t make sense” it’s so very difficult for that not spiral into “wow, I’m a terrible person huh!”

I feel this. Less so now than when I was younger, but still. And not even just in design critique, just life critique. But even knowing that it’s a constructive critique doesn’t always help with processing it. As Robin says, “I know design critiques aren’t about me, so why do they still hurt?”

Article: “Six Lessons from Six Months at Shopify” by Alex Danco

First, there’s this note on Conway’s Law (“You ship your org chart”):

The original wording from Melvin Conway goes: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication system.”...

Think about any complex product you like – it could be your phone, your car, a public transit system; whatever. That product is composed of many different parts, and sub parts, all the way down to tiny little atomic units that feel like indivisible “chunks” of product. Conway’s law is an observation about the contours of those chunks of product....boundaries between chunks of product mirror communication boundaries inside the org.

Then there’s this point about software saturation:

there is so much software...I forget who said this – someone smart on Twitter – but your mental idea of the software business changes when you realize that the primary customer of software is becoming other software.

This stuck out to me because just a couple days before I had seen GitLab’s “Tech Stack Details” where they openly enumerate (all?) of the software they use. The list is huge, over 160 pieces of software.

Article: “Now” by Frank Chimero

An interesting observation on how our digitally-saturated lives continue to favor and connect to physical world representations. Of dust we truly art I suppose:

It’s so interesting that we designers are all using these mockup templates to sell work through. Big agencies do it. Individual practices (like me) use the same files. Yet nothing ever gets physically produced. The work stays digital, but we need the mystique of physical production to get the kind of alignment necessary for clients to say yes. Nobody ever fell in love with a logo by seeing it mocked up in an email signature. We still emotionally favor the material world even if our branding strategies and marketing budgets shit-canned it ages ago.

Article: “Missing” by Tim Kadlec

Data can blind you:

As Andy Davies puts it, “Site analytics only show the behaviour of those visitors who’ll tolerate the experience being delivered.” Sessions like this are extremely unlikely to ever show up in your data. Far more often than not, folks are going to jump away before analytics ever has a chance to note that they existed.

And later:

We build an experience that is completely unsuable for them, and is completely invisible to our data...we look at the data and think, “Well, we don’t get any of those low-end Android devices so I guess we don’t have to worry about that.” A self-fulfilling prophecy.

Video: “The web we left behind” by Kyle Jacobson (ESNEXT 2020)

Observations from someone who has been building for the web for 20 years.

We keep engineering more complexity and then using complex solutions to abstract it away for a while until we build new complexity on top of the new abstractions. If we zoom out enough, the overall pictures looks less like overall simplification.

Screenshot of a slide from Kyle Jacobson’s talk at ESNEXT 2020 depicting a line graph climbing up and to the right, illustrating an ever accreting “complexity mountain” of technology.

It’s interesting to view “progress” through this lens: a pile of abstractions, each hiding the previous layer’s complexity. Either way, Kyle’s sentiment resonates with me quite often:

I'm not tired of building products for the web. I'm tired of being a modern JavaScript developer...Most days, I don't seem to be very good at my job.


Reading Notes, September 2020

Article: “Demand Side Sales 101, a new book on sales by Bob Moesta.”

This piece of writing was enough to interest me in buying the book. It sounded great, even though I’ve never heard of Bob Moesta. These kinds of insight cut through so much of the cruft of making software:

Everyone’s struggling with something, and that’s where the opportunity lies to help people make progress. Sure, people have projects, and software can help people manage those projects, but people don’t have a “project management problem.”...Project management is a label, it’s not a struggle.

What kind of struggles do people have?

People struggle to know where a project stands. People struggle to maintain accountability across teams. People struggle to know who’s working on what, and when those things will be done. People struggle with presenting a professional appearance with clients. People struggle to keep everything organized in one place so people know where things are. People struggle to communicate clearly so they don’t have to repeat themselves. People struggle to cover their ass and document decisions, so they aren’t held liable if a client says something wasn’t delivered as promised. That’s the deep down stuff, the real struggles.

Article: “Follow the Fun”

Protoype, demo, repeat. Yes, yes, yes!!

We like to think about this process as the game discovering itself over time. Because as iterators, rather than designers, it’s our job to simply play the game, listen to it, feel it, and kind of feel out what it seems to want to become - and just follow the trails of what’s fun. — Seth Coster, “Crashlands: Design by Chaos” (GDC 2018)

Then:

Interestingly the designer’s role shifts a bit from creative overlord to active listener. They must be attentive to what the game (via play testers) is “saying”. They must be willing to explore those more interesting aspects, abandoning bad ideas and letting go of their initial ideas along the way. I love this methodology and it’s not dissimilar to how we build websites at Paravel, iterating and oversharing our works-in-progress in Slack.

And last this bit of wisdom was maybe my favorite, though perhaps not directly related to the subject at hand:

Don’t throw your pearls to swine by tweeting things to randos on Twitter.

Tweet: Narrow Your Focus

I’ve been feeling the need for these kinds of words lately:

Raise the speed
Raise the quality
Narrow the focus

“Everybody wants results, but not everybody wants to do what that takes.”

Which links to this article (which, to be honest, I only skimmed because it’s quite long and full of CEO-speak):

As a leader, your opportunity is to reset in each of these dimensions. You do it in every single conversation, meeting, and encounter. You look for and exploit every single opportunity to step up the pace, expect a higher quality outcome, and narrow the plane of attack. Then, you relentlessly follow up...

Podcast: The Clearleft Podcast: Design Systems

An interesting observation from James which pits the idea of a “design system” as a completed, packaged object, against the idea of “systematic design” which is more of a mindset that transcends individual objects.

I prefer to talk about systematic design.

So what I mean by systematic design is designing only the things you need, but in a systematic way so that anything you need in future can build on the system you are building. So it's not a finished thing. I think a design system to me sounds like a product which is finished, and that you hand over to somebody for them to kind of take on.

I think a design system sounds like quite an intimidating product, whereas systematic design is something that anybody can get involved with at any point.


Reading Notes, August 2020

Article: “Web Bloat”

For another level of ironic, consider that while I think of a 50kB table as bloat, this page is 12kB when gzipped, even with all of the bloat. Google's AMP currently has > 100kB of blocking javascript that has to load before the page loads! There's no reason for me to use AMP pages because AMP is slower than my current setup of pure HTML with a few lines of embedded CSS and the occasional image, but, as a result, I'm penalized by Google (relative to AMP pages) for not "accelerating" (deccelerating) my page with AMP.

I actually really enjoy the “design” (how it looks + works) of danluu.com. Also enjoyed this fact check:

The flaw in the “page weight doesn’t matter because average speed is fast” is that if you average the connection of someone in my apartment building (which is wired for 1Gbps internet) and someone on 56k dialup, you get an average speed of 500 Mbps.

Article: “A clean start for the web”

While I didn’t agree with necessarily everything in this piece, I really loved the way it started:

The web’s evolution over the last decade has mirrored the American economy. All of the essential indicators are going “up and to the right,” a steady stream of fundamental advances reassure use that there “is progress,” but the actual experience and effects for individuals stagnates or regresses.

Nothing helps you think you’re on the right path like seeing a graph that goes up and to the right representing any aspect of the thing you’re doing.

A line graph going up and to the right but representing no particular pieces of data.

Article: “Back when software was a craft”

Software feels more like assembly than craft...I’ll do glue work when it creates many times the value than the same time spent on craft. It’s fine, I can craft on the weekends, for play.

Site note: Jess’ hero image for this post made me read the title as “Back when software was a cat”

Article: “Why I Won’t Sign Your NDA”

There’s nothing new under the sun. Ideas abound, but execution is everything.

So that’s why I won’t sign your NDA. It’s not because I don’t like you, it’s not because I want to steal your ideas, it’s not because what you’re up to isn’t important.

It’s because the ideas you are likely to share with me over coffee or in a phone conversation are otherwise plentiful, worthless in isolation, and, to some degree, completely unoriginal and already known to the world.

Article: “Ward Explains Debt Metaphor”

A great explanation of behind the metaphor of “tech debt”.

I coined the debt metaphor to explain the refactoring that we were doing...It was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if we had known what we were doing all along...The explanation I gave to my boss, and this was financial software, was a financial analogy I called “the debt metaphor”

With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt. I'm never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.


Reading Notes, July 2020

Article: “The Comeback of Fun in Visual Design”

The cynics will say that the pendulum will swing back to flat in a few years and that it’s all part of the cyclical nature of design trends. I don’t think the pendulum swings all the way back. Sure, there’s an aspect of fashion to design—what’s in vogue today won’t be tomorrow—but I think this is more about the scale balancing out than it is the pendulum swinging back. Fun and “judicious expressiveness” is back to stay—not because fashions have changed but because it has value. It took us losing it to realise that.

Shameless plug: I helped Michael write those particular lines, so is it cheating to cite this here on my blog? Either way, I agree with Michael and am excited about the reintroduction of fun into visual design.

Article: “Ask an expert: Why is CSS...the way it is?”

An interesting perspective from a technical director at the W3C on how and why CSS came to be what it is today. What struck me were the similarities between building platform features for the web and building just about any other piece of software. Read these excerpts and try to tell me they don’t sound exactly like any other piece of software you’ve ever worked on:

Once a feature is in place, it’s easier to slightly improve it than to add a new, better, but completely different feature that does the same thing.

This also explains why the first two improvements to specifying color in CSS—a named-color system and a hue-wheel, polar notation—were adopted over much better, but more complicated, systems proposed at the same time. They were slight improvements, seen as easy to implement.

The idea lost momentum, and we chose the path of least resistance instead.

After a week of mailing list discussion and no suggestions for improvement, the consensus was that my syntax was good enough for now.

Article: “Craft is Culture”

A nice articulate piece on craft and culture.

Linux proved that there is no upper limit to how much value you could extract out of a message board or email list, if you got the social dynamics right. The internet made it easy for craft practitioners to find one another, fraternize and argue over methods and best practices, almost like artists. The fact that none of these people had ever met in person, or had any shared culture or life experience, made zero difference. Their craft was their shared culture.

I suspect that within a few years, we (and others) will go through a complete rethink of how hiring works, that’s re-oriented around craft: how do we celebrate it, how do we communicate the ways that we celebrate it, how do we find people who crave celebration of that very specific thing, and then how do we hire them, wherever they are?

Craft is culture. If you care about craft, you’ve done the hard part.

Article: “Over-engineering is under-engineering”

Honestly, I just really liked this line because it felt very relevant.

from an outsider’s perspective the enterprise/startup web developer job looks...mostly dedicated to re-building things the browser already does, just with a ‘this is our brand’ corporate spin.

Video: “The Wet Codebase” by Dan Abramov

So what happens is that developers learn best practices from the previous generation and they try to follow them. Because there were concrete problems and concrete solutions that were born out of experience. And so the next generation tries to pass them on. But it's hard to explain all this context and all this trade off, so they just get flattened into these ideas of best practices and anti-patterns.

And so they get taught to the new generation. But if the new generation doesn't understand the trade offs and the reasons they came to these conclusions, they don't have the context to decide when it's actually a bad idea and how far can you stretch this. So they run into their own problems from trying to take these best practices and anti-patterns to the extreme. And so they teach the next generation.

So what to do about it?

I think one way to try to break this loop is just when we teach something to the next generation, we shouldn't just be two-dimensional and say here's best practices and anti-patterns. But we should try to explain what is it that you're actually trading away. What are the benefits and what are the costs of this idea?

Article: “Accessibility”

Jeremy’s comments on Open Prioritization, which is an experiment in crowd-funding prioritization of new features in browsers.

when numbers are used as the justification, you’re playing the numbers game from then on.

He is speaking about monetary justification in arguments, but I saw a corollary in data-driven decisions. Once you make a product decision based purely on data, it becomes hard to ever deviate from or change that decision. “But the data said we should...” is the argument. Or “what does the data say?” becomes the leading question on decision making. Data is a cruel master.

He continues:

You’ll probably have to field questions like “Well, how many screen reader users are visiting our site anyway?” (To which the correct answer is “I don’t know and I don’t care”

Sometimes I wish more product decisions were made on principles and values like this more than the crutch of data.

If you tie the justification ... to data, then what happens should the data change? ... If your justification isn’t tied to numbers, then it hardly matters what the numbers say (though it does admitedly feel good to have your stance backed up)...The fundamental purpose of [your product] needs to be shared, not swapped out based on who’s doing the talking.


Reading Notes, June 2020

Article: “Deno is a Browser for Code”

I haven’t really played with Deno yet, but conceptually I love a number of its founding premises:

In order to publish a website, we don’t login to a central Google server, and upload our website to the registry. Then if someone wants to view our website, they use a command line tool, which adds an entry to our browser.json file on our local machine and goes and fetches the whole website, plus any other websites that the one website links to to our local websites directory before we then fire up our browser to actually look at the website. That would be insane, right? So why accept that model for running code?

The Deno CLI works like a browser, but for code. You import a URL in the code and Deno will go and fetch that code and cache it locally, just like a browser. Also, like a browser, your code runs in a sandbox, which has zero trust of the code you are running, irrespective of the source. You, the person invoking the code, get to tell that code what it can and can’t do, externally. Also, like a browser, code can ask you permission to do things, which you can choose to grant or deny.

With Deno, there is no package manager. You only need HTTP.

The HTTP protocol provides everything that is needed to provide information about the code, and Deno tries to fully leverage that protocol, without having to create a new protocol.

Also this bit:

This leads us to the Deno model, which I like to call Deps-in-JS, since all the cool kids are doing *-in-JS things.

This is a really interesting conceptual look at what Deno is doing and how it’s different. I like it. It feels very “webby”.

Article: “RFC 1925 - The Twelve Networking Truths”

Found this via Dave’s blog and the source article is a wonderful read that starts like this:

This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths.

What follows is a number of half truths, half jokes, informed by years of experience. Like this one:

(3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea.

A number of these truths, rules, whatever they are, I encountered just this week. In fact, I see many of them every week:

(5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.

And

(8) It is more complicated than you think.

A great read.

Article: “Tradeoffs and Shifting Complexity”

Oh hey, another article from Dave. But it just resonated with me so much!

We don’t really make software architecture decisions based on some rigorous cost/benefit analysis. Decisions are often more informed on existing biases, past experiences, and the tradeoffs people find most comfortable. Decisions also get slipped in under the cover of self-imposed sprint deadlines...sometimes, it seems, the act of making a decision or the need to “unblock” something gets elevated over the impact of the decision.

I think this is where the second implication of Tesler’s Law comes into play: “Who will inherit the complexity?” Is it a value or a cost that gets passed on to the user? It’s a simple question, but the answer dictates so much.

This really resonates—so much decision making gets made around how the teams building the software organize themselves, communicate, and basically work. And the outworking of those environments, those processes, is what often frames our decision making.


Reading Notes, May 2020

Article: “How HTTP Requests Work”

If the browser notices the server supports HTTP/2 it sets up a HTTP/2 session (with a handshake that involves a few roundtrips like what I described for DNS) and creates a new stream for this request. The browser then formats the request as HTTP/2 wire format bytes (binary format) and writes it to the HTTP/2 stream, which writes it to the HTTP/2 framing layer, which writes it to the encryption layer, which writes it to the network socket and sends it over the internet.

Fascinating look at all that’s happening to merely visit something like website.com. To be quite honest, it’s incredible any of it even works at all.

Article: “Realign 2020: Color”

Tyler reflecting on the rationale and process in his color choices. In a world where we’re constantly creating static digital mockups as the artifacts for gathering consensus to build something, this is a good reminder to constantly question: is this design meant to be looked at, or actually used?

Letting contrast ratios influence aesthetic decisions can be a little uncomfortable. As an experienced designer, I have a trained eye that I trust to choose colors that work well and look good. But, that’s not the whole story. My instincts towards subtlety often lead to colors that look fantastic, but are low in contrast. Low contrast text can be difficult for people to see. Color needs more than my instincts alone. So I let go of a bit of control.

Letting go can produce great results. Results that make a design accessible and enjoyable to more people.

Article: “Attitude of Ingratitude”

Evergreen excerpt to reference:

Before I stopped using twitter, and since starting it up again, I decided always to be positive while using it. Or rather, not to be negative. It was very easy to, for example, watch a slightly substandard film, pop online and go “Oh lol, just watched a terrible film, something, something.” While forgetting that people worked hard on it, and everything that goes along with how much effort goes into producing anything from start to end.

Video: “Rosie Pattern Language: Improving on 50-Year Old Regular Expression Technology”

Based on some recommendations on Twitter, I started watching some Strangeloop talks. To be honest, I don’t fully grasp a lot of what’s being discussed in these talks, but there are little bits and pieces I find and note down.

In this particular talk, Jamie points out an interesting historical fact around regexes. My familiarity with regexes is: those big cryptic pattern matching strings I hopefully never have to deal with much. I found it interesting that what makes them scary (a regex that’s more than like seven characters long) is basically due to the over-extension of a constraint that shaped their original design.

This is an interesting point of origin: [regex's] usefulness on the command line and while editing led directly to how concise regular expressions are—which is great if you need to be concise. If you don't need to be concise it means that the syntax is rather cryptic.


Reading Notes, March 2020

Article: “Why is CSS frustrating?”

First up, the difficulty of CSS reminds me of the difficulty of book design... When designing a book we have to treat the InDesign file as a sort of best guess, it’s not until we print the dang thing that we begin to see all the problems...

So the best thing to remember when designing a book is the same as when designing a website: the screen is a lie.

What we’re seeing on screen and what the final product will become are two very different things. We need to constantly remind ourselves that there are invisible edge cases, problems that in this context, on this screen, are made utterly invisible to us.

“the screen is a lie”—I loved this phrase when I read it. Perhaps everything in this article will be apparent to anyone who’s been working on the web for years, but it’s definitely not apparent for people who haven’t (i.e. “stakeholders”). I’ve already found myself trying to distill the essence of this article into my introductory statements to stakeholders before presenting design mocks, like “ok, remember everyone, that what you’re going to see is actually a lie. It does not represent the final product, nor does it represent the finality of the product. There are problems and edge cases that are entirely invisible to us in these mocks. This is just a glimpse of a very particular, targeted solution.”

Oh, and I liked this snippet about the web being messy. Once you embrace the messiness, it’s no longer a pain point. In fact, it’s actually a strength you enjoy capitalizing on.

I think everyone hates CSS for forcing them to be empathetic but also because the web is so messy—despite that being the single best thing about it.

Video: “When We Build” by Wilson Miner

Had this talk sitting in my “To Watch” list for a long time. It’s full of little insights. I really like the speaker’s presentation of this quote from Marshal McLuhan:

All media are extensions of some human faculty, mental or physical. The wheel is an extension of the foot. The book is an extension of the eye. Clothing is an extension of the skin. Electric circuitry is an extension of the central nervous system. The extension of any one sense displaces the other senses and alters the way we think, the way we see the world, and ourselves. When these changes are made, men change.

Article: “Redesign: Perfect Trifecta” by Frank Chimero

Frank talks about his process of selecting a typeface for his blog.

No matter how much one plans, a designer will crawl through their mental rolodex of fonts and see what feels right to their eye. Post-rationalization is an open secret in the design industry, but with personal work, there is no one to impress with rigor. One can go on intuition. The eye knows.

“Post rationalization is an open secret in the design industry.” Love this line. It’s funny because Frank says it’s an open secret but I can’t actually remember ever seeing it written down anywhere.

Article: “Agile: The Once and Future Methodology”

Really I just liked these quotes. They seem so obvious when written down that they’re hardly worth noticing, but I’m not sure how many of us that work in software have truly internalized this truth such that we could articulate it clearly. I want to, which is why I’m writing this down.

there is an intrinsic tension among opposing forces that every engineering project must solve.

There is the desire to reduce costs; opposing that desire is the need to develop a reliable product with all the features and functionality needed to make it a success.

And this:

Build a little, test early and often so that mistakes are caught early and so stakeholders have a chance to see and respond, and so that the inevitable requirement changes are identified and absorbed during the process, not in a terrified rush at an acceptance test.

Article: “How Big Technical Changes Happen at Slack”

This article was making the rounds on the internet. Personally I think there’s lots of good technical advice in there, but also lots of more broad advice about developing anything as a product—including design systems (whatever you define that to be).

When we are trying to drive change, we do so with a customer-centric attitude towards the teams trying to understand and use a new system. Their happiness is the only real barometer of your success. This involves outreach, requirements gathering, feedback, iteration, and purposeful education and skill-sharing.

When in doubt, remember: you’re accountable for your team’s technical success, and your team’s technical success is–in the long run–judged by the people using your stuff.


Reading Notes, February 2020

Article: “The Shallows: tenth anniversary edition” by Nicholas Carr

Reflecting on the 10th anniversary of his book The Shallows

Welcome to The Shallows. When I wrote this book ten years ago, the prevailing view of the Internet was sunny, often ecstatically so...In a 2010 Pew Research survey of some 400 prominent thinkers, more than 80 percent agreed that, “by 2020, people’s use of the Internet [will have] enhanced human intelligence; as people are allowed unprecedented access to more information, they become smarter and make better choices.”

The year 2020 has arrived. We’re not smarter. We’re not making better choices.

Then later:

When it comes to the quality of our thoughts and judgments, the amount of information a communication medium supplies is less important than the way the medium presents the information and the way, in turn, our minds take it in. The brain’s capacity is not unlimited. The passageway from perception to understanding is narrow. It takes patience and concentration to evaluate new information — to gauge its accuracy, to weigh its relevance and worth, to put it into context — and the Internet, by design, subverts patience and concentration.

Article: “Guide to Internal Communication, the Basecamp Way” via basecamp.com

A collection of general principles the folks at Basecamp try to keep in mind when communicating. There’s a lot of really great stuff in there. I’ve only surfaced a few here that feel particularly relevant to me in February 2020.

Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts. If it's important, critical, or fundamental, write it up, don't chat it down.

Speaking only helps who’s in the room, writing helps everyone. This includes people who couldn't make it, or future employees who join years from now.

"Now" is often the wrong time to say what just popped into your head. It's better to let it filter it through the sieve of time. What's left is the part worth saying.

Article: “Looking at Letters” by Frank Chimero

A great analysis of choosing type and making creative decisions.

you can also pick by gut or chance once you’re certain you have a solid pool to choose from. Reasons can be arbitrary, and you need to leave room for whim. I once chose a typeface because I liked the 7. Sometimes one can overthink things.

I raise all this to show the natural limits of intent...Best to take those first big steps in the right direction, whittle down the options, and commit to what feels right to you. No choice is bulletproof, and no amount of evidence is ever going to completely clarify or validate a choice. This is what makes these choices creative.

Article: “Agile as Trauma”

Questioning the thinking that more collaboration is better:

Collaboration! So much effort goes into writing and talking about collaboration, and creating tools to facilitate collaboration and telecollaboration, with the tacit assumption that more collaboration is always better...Since communication overhead increases proportionally the square of the number of people on the team—a fact illuminated by Brooks in the 1970s—what you actually want is as little collaboration as you can get away with.

On the spurious nature of feature comparison:

Features don’t work, in the sense that they can be easily gamed. A brittle and perfunctory implementation, done quickly, is going to score more intramural brownie points over a robust and complete one. If the question is does product A have feature X? then the answer is yes either way. This also makes features a spurious basis for comparison in competing products because you need to seriously examine them to determine the extent to which they are any good.

How to speed up software development;

Like any other creative endeavour, software development can’t be sped up as much as we can eliminate the phenomena that slow it down.

Viewing software development through an entirely new lens:

A development paradigm that can be construed from the outside as setting great store by speed—or, I suppose, velocity—is invariably going to be under continuous political and economic pressure to accelerate...If instead you asserted that the work amounts to continual discovery, it happens at one speed, and could potentially continue indefinitely, you might be able to pace yourself.

Article: “Letting tools make choices”

This little story resonated with my own experience so much, I just wanted to make note of it—a kind of “hey, somebody else feels the same as me.”

I remember sitting down one evening after work to focus on a side project and losing the best part of the evening trying to get two different tools that I'd chosen to use playing nicely alongside each other. I finished for the night and realised that I'd made no progress...Once I had everything playing nicely, one of the tools would have an update which broke something and I'd repeat the process all over again.

Article: “The Simplest Way to Load CSS Asynchronously” via filament group

This post is about seven months old, but I hadn’t seen this trick before. I didn’t even need an explanation (though theirs is great). Just reading the markup dawned on me the elegance of this trick to loading a CSS stylesheet async.

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

I love little tricks in HTML like this that would otherwise require who knows how many lines of JavaScript.


Reading Notes, January 2020

Article: “Level of Effort” by Brad Frost

REQUIREMENTS. What an absolutely terrible word. “As per the requirements…” It sounds so authoritative. So final. But at the end of the day it’s just some designers or BAs making some calls (maybe informed by plenty of research, maybe not) and rolling with them.

A really great piece from Brad arguing for the inclusion of front-end developers as equal partners in the design process.

A more collaborative process saves an absurd amount of time, money, and anguish. Frontend developers can not only help better determine level of effort of any design solution, but offer suggestions, alternatives, and solutions that better follow the grain of the web. “If we move this from here to here, we can build it out in 2 hours. But if it stays the way it is, it will take about 2 weeks to implement.” Repeat that a couple dozen times and you just saved yourselves months worth of unnecessary work.

I think this observation is spot-on.

Video: Malcom Gladwell on Larry King Live

I ended up down a Malcom Gladwell rabbit hole the other day, which resulted in some interviews with him playing in the background while I worked and I liked this:

A special kind of insight comes from distance...I think we’re really reluctant to re-examine our conclusions about the past. There’s so much to be learned by simply going back and saying “we made up our mind about this [thing] that happened”, boom, the day after it happened. And then we just let it sit there and never went back to say, “well, was I right?” There are all kinds of things you can learn, years later, that can fundamentally change your understanding of history and how you reach your own conclusions.

Then later:

It brings to mind that famous epigram “history is written by the victors.” And that’s true. The account that you get in the first go-round is written by the guy who won. So one of the reasons it’s so important to go back and look at history again is you have to give other people a chance to speak. People are willing to be honest with the passage of time.

Article: “Building Trust as a Designer”

Is it my job to be realistic and empathetic to constraints, or to be the persistent voice of the user who makes stuff better at the cost of momentum...? As with most things, it depends.

An honest look, I felt, at the reality of being a designer.

We have to learn to push for the impossible while navigating and respecting the constraints of the people and organisations we work with.

Article: “The Concept Electronics Show”

Concept designs (and worse, concept videos) are a sign of dysfunction and incompetence at a company. It’s playing make-believe while fooling yourself and your audience into thinking you’re doing something real. Concepts allow designers to ignore real-world constraints: engineering, pricing, manufacturing, legal regulations, sometimes even physics. But dealing with real-world constraints is the hard work of true design. Concepts don’t stem from a lack of confidence. They stem from a dereliction of the actual duties of design.

Later:

Designing at the limits of possibility is one thing; designing unbounded by reality is another.

Article: “A guide to Minimalist Web Design”

I just liked this one excerpt. I think there’s a key differentiation between “adding white space” and “removing stuff”:

Removing or excluding elements from a web page necessarily leaves empty space. So that space is not an action that you do, but a result that you get through throwing unnecessary elements out, because you don’t need more space. but you need less stuff.


Reading Notes, December 2019

Article: “Larry and Sergey: a valediction” by Nicholas Carr

Loved this paragraph from Carr:

When, in 1965, an interviewer from Cahiers du Cinema pointed out to Jean-Luc Godard that “there is a good deal of blood” in his movie Pierrot le Fou, Godard replied, “Not blood, red.” What the cinema did to blood, the internet has done to happiness. It turned it into an image that is repeated endlessly on screens but no longer refers to anything real.

Article: “Martin Scorsese: I Said Marvel Movies Aren’t Cinema. Let Me Explain.” via nytimes.com

Apparently Martin Scorsese threw some shade—at least that’s how some people saw it—at the Marvel films:

I’ve tried to watch a few of them and they’re not for me, they seem to me to be closer to theme parks than they are to movies as I’ve known and loved them throughout my life, and in the end, I don’t think they’re cinema.

He then wrote an opinion piece to clarify what he was trying to say:

There’s worldwide audiovisual entertainment, and there’s cinema. They still overlap from time to time, but that’s becoming increasingly rare. And I fear that the financial dominance of one is being used to marginalize and even belittle the existence of the other.

Read his words how you want, but one of my interpretations is: data-driven movie making has ruined cinema:

everything in [The Marvel movies] is officially sanctioned because it can’t really be any other way. That’s the nature of modern film franchises: market-researched, audience-tested, vetted, modified, revetted and remodified until they’re ready for consumption.

“But the data proves that’s what the people want!” He addresses that:

And if you’re going to tell me that it’s simply a matter of supply and demand and giving the people what they want, I’m going to disagree. It’s a chicken-and-egg issue. If people are given only one kind of thing and endlessly sold only one kind of thing, of course they’re going to want more of that one kind of thing.

He concludes:

In the past 20 years, as we all know, the movie business has changed on all fronts. But the most ominous change has happened stealthily and under cover of night: the gradual but steady elimination of risk.

I wonder if this is happening in pockets software design and development, for better or worse...

Article: “The Principles of Versioning in Go”

This piece is quite an exhuastive look at why the folks behind Go version the way they do. I found the entire thing quite an interesting analysis of semver and versioning software. So if you’re interested in that kind of computer science stuff, read the whole thing!

While the article deals specifically with the topic of versioning in software, I found this commentary about code aesthetics to have many parallels to design. I thought it was a good articulation of how I feel about keeping links underlined—and in many cases the default “blue”—on the web.

The most common objection to semantic import versioning is that people don’t like seeing the major versions in the import paths. In short, they’re ugly. Of course, what this really means is only that people are not used to seeing the major version in import paths.
...
Both these changes—upper-case for export and full URLs for import paths—were motivated by good software engineering arguments to which the only real objection was visual aesthetics. Over time we came to appreciate the benefits, and our aesthetic judgements adapted. I expect the same to happen with major versions in import paths. We’ll get used to them, and we’ll come to value the precision and simplicity they bring.

What would the www be like if everyone kept their links underlined?

Tweet: @ryanflorence

There are two types of software companies: those that ship code that embarrasses their engineers and those that go bankrupt.

Based on my experience thus far in my career, I would agree with this statement. Granted it’s a black and white statement, but if you read between the lines, the essence here resonates with me.

I think a corrollary to design would quite frequently hold to be true as well: “there are two types of software companies: those that ship products that embarass their designers and those that go bankrupt.”

Article: “Tape loop” by Simon Collison

A beautiful piece that ruminates on the experience of music as it was before the iPod. Back then, music was an experience that shaped your identity, your life! And now that experience is completely gone, except for those of us who remember it. We are vessels of the cassette.

Physicality [the cassette tape] feels like an investment in something: a relationship with a piece of work that I'll endeavour to like. If I decide I don't like it, I will be sure of that, having tested more thoroughly than if it was one of hundreds of Spotify album samplings.

Maybe it’s just nostalgic ramblings, but I agree with his conclusion: “[I enjoy] music in more ways than one, and I feel much richer for it.”

Article: ‘“Ethics” and Ethics’

the tech industry prefers the word “ethics” over morals

Why? Because:

“Ethics” is nice. Morals are uncomfortable.
“Ethics” is less binding. They feel more abstract, neutral, less scary, less obligatory. Morals command.
“Ethics” is abstract. Morals are concrete.

Overall, a bit rambling in spots but had some interesting insights I think.

Article: “Bluesky: Twitter Announces Effort to Build ‘Decentralized Standard for Social Media’” via Daring Fireball

Gruber’s commentary on Twitter’s apparent forway into creating an open source standard for social media. What I liked was John’s analysis of prescriptive vs. descriptive specs.

XHTML was a boil-the-ocean plan to create a new version of HTML, its creators’ ideal for how HTML should be used — a prescriptive spec. HTML5 took the approach of standardizing how HTML already was being used — a descriptive spec. We all use HTML5 today.


Reading Notes, November 2019

Article: “From public intellectual to public influencer” by Nicholas Carr

Nicholas Carr with another great analysis. This time he points his lens at the “influencer”:

Marketing has displaced thinking as our primary culture-shaping activity, the source of what we perceive ourselves to be. The public square having moved from the metaphorical marketplace of ideas to the literal marketplace of goods, it’s only natural that we should look to a new kind of guru to guide us.

Then later:

The idea that the self emerges from the construction of a set of values and beliefs has faded. What the public influencer understands more sharply than most is that the path of self-definition now winds through the aisles of a cultural supermarket. We shop for our identity as we shop for our toothpaste, choosing from a wide selection of readymade products. The influencer displays the wares and links us to the purchase, always with the understanding that returns and exchanges will be easy and free.

A great post. Read the entire thing.

Article: “Five Packages” by Dave Rupert

I find something poetic in the fact that the dependencies I rely on the most will eventually not be needed.

I’ve actually been thinking about this the past couple years. Dave put this feeling into words here.

So much of my web dev work for the last couple years, both via my employer and on personal projects, has been around trying to make conscientious decisions about what and why I include as a dependencies in a project. For personal projects, I’ve been trying to get to “dependency zero” (where reasonably possible) or close to it. When I do bring in deps, I try to architect my project and use the dependencies in such a way that whatever code I write and tool I compile with, one day I’ll be able to remove that dependency entirely from my project and not have to touch a single line of code other than in my package.json. I’ve been able to do that a few times and let me tell you: that is a nice feeling.

Article: “The Popeye Moment” by Frank Chimero

Most design content has become poor quality, surface-level content marketing that does more damage than good, because it offers over-simplified, misinformed perspectives dressed up as guidance. One hardly gets the sensation of lived experience and professional acumen in the words.

Love that articulation. Love all of Frank’s words. Looking forward to following this little project he’s started.

Online eBook: “Modest JS: Upgrading (the idea of) dependencies”

This is a little excerpt from an online book about “modest JavaScript”. I liked this particular paragraph which brings into focus the more general meaning of the word “dependency” then circles back to its usage in the context software:

The idea of dependencies in software writing goes back a while...But being dependent, that’s a concept with an even longer history. Including dependencies into your project feels like a win (all of this work you don’t have to do), but depending on other people’s work doesn’t feel so much like a win anymore. Being dependent: that doesn’t feel good at all.

Article: “Third party” by Jeremy Keith

An interesting post as always from Jeremy, but this line:

I know that it would make my life as a developer harder. But that’s of lesser importance. It would be better for the web.

Podcast: “You Can Learn A Lot For The Low Price Of Your Ego - With Shawn Wang”

I like Shawn and the unique perspectives he brings about learning to the world of webdev. I haven’t listented to this entire podcast yet, but I liked this excerpt from the transcript:

“You can learn so much on the internet for the low, low price of your ego.” If you keep your identity small, you can remain open to new ideas. If you make what you know a part of your identity, being receptive to new ideas and accepting that you were wrong becomes challenging.

Article: “The Department of Useless Images”

The Web is smothering in useless images. These clichéd, stock images communicate absolutely nothing of value, interest or use. They are one of the worst forms of digital pollution because they take up space on the page, forcing more useful content out of sight. They also slow down the site’s ability to download quickly. In the last ten years, webpages have quadrupled or more in file size, and one of the primary reasons for this is useless image proliferation. If organizations are filling their websites with these useless, information-free images, are they also filling their websites with useless, information-free text? Are we still in a world of communicators and marketers whose primary function and objective is to say nothing of value and to say it as often as possible? And whatever you do, look pretty.

The struggle is real.

Loved this imagined conversation:

“We have this contact form and we need a useless image for it.” “How about a family cavorting in a field of spring flowers with butterflies dancing in the background?” “Perfect.”

Article: “How Life Became an Endless, Terrible Competition”

My wife shared this with me, commenting that I should think about this in the context of our young kids. With our 4 year old just about to reach the age where the social convention is you send them off to public school, we’ve been discussing topics like this.

Elites first confront meritocratic pressures in early childhood. Parents—sometimes reluctantly, but feeling that they have no alternative—sign their children up for an education dominated not by experiments and play but by the accumulation of the training and skills, or human capital, needed to be admitted to an elite college and, eventually, to secure an elite job.


Reading Notes, October 2019

Article: “Using the Platform” by Tim Kadlec

One of the most fascinating things about the web is its “don’t break current implementations” ethos, which stands in direct contrast to just about every other piece of software ever made:

This permanence to the web has always been one of the web’s characteristics that astounds me the most. It’s why you can load up sites today on a Newton, and they’ll just work. That’s in such sharp contrast to, well, everything I can think of. Devices aren’t built like that. Products in general, digital or otherwise, are rarely built like that. Native platforms aren’t built like that. That commitment to not breaking what has been created is simply incredible.

Later:

as some frameworks are, just now, considering how they scale and grow to different geographies with different constraints and languages, the web platform has been building with that in mind for years.

Conclusion:

Use the platform until you can’t, then augment what’s missing. And when you augment, do so with care because the responsibility of ensuring the security, accessibility, and performance that the platform tries to give you by default now falls entirely on you.

Article: “A Like Can’t Go Anywhere, But a Compliment Can Go a Long Way” by Frank Chimero

An interesting look at the effects of UI design. What do you think culture would look like if we reversed these UIs? Praise required words while negativity was easily accessible via a single interaction? Who knows. Could be different. But also humans are humans and it could be the same.

First, a look at Facebook’s UI:

one negative reply literally takes up more visual space than tens of thousands of undifferentiated likes.

Then Twitter’s:

The arrangement is even worse on Twitter. Liking stays attached to the original tweet and makes most positive interactions static. Negative reactions must be written as tweets, creating more material for the machine. These negative tweets can spread through retweets and further replies. This means negativity grows in number and presence, because most positivity on the service is silent and immobilized.

Positivity is “silent and immobilized’. What an fascinating assessment—and the result of this?

like can’t go anywhere, but a compliment can go a long way. Passive positivity isn’t enough; active positivity is needed to counterbalance whatever sort of collective conversations and attention we point at social media. Otherwise, we are left with the skewed, inaccurate, and dangerous nature of what’s been built: an environment where most positivity is small, vague, and immobile, and negativity is large, precise, and spreadable.

Article: “Overly defensive programming”

I’ve kind of been following the development of optional chaining in JavaScript. It’s now stage 3, which had me re-evaluating my own thoughts on the syntax. @housecor has been a visible opponent of the syntax and I found this piece via a thread on his twitter. It has some good points specifically relevant to optional chaining, but even more broadly relevant to writing JS applications.

Trust in your data, and your code will be more predictable and your failure cases more obvious. Data errors are simpler to debug if an error is thrown close to the source of the bad data.

Unnecessary safety means that functions will continue to silently pass bad data until it gets to a function that isn’t overly safe. This causes errors to manifest in a strange behavior somewhere in the middle of your application, which can be hard to track...Debugging it means tracking the error back to find where the bad data was introduced.

And later:

Being overly cautious with external data means that the next person to consume it doesn’t know if it’s trustworthy, either. Without digging into the source to see how trustworthy the data is, the safest choice is to treat it as unsafe. Thus the behavior of this code forces other developers to treat it as an unknown, infecting all new code that’s written.

Article: “Words as Material”

An absolutely wonderful piece on writing.

Matt Jones: “[Writers] are the fastest designers in the world. They’re amazing at boiling down incredibly abstract concepts into tiny packets of cognition, or language.” ... writing is part of every design. If you can clearly define what you’re making and articulate its value, the steps to bring it out into the world will go much faster.

This resonates about 1,000% with my experience.

Writing can be a tool for talking to ourselves when we’re still figuring things out. A sort of mirror or feedback system. A way to understand and articulate design.

When I sit down to write, I don’t usually know what I’m going to say. It’s only through the act of writing that it becomes clear that I need to say anything at all.

Quoting David foster Wallace who is talking about ordinary people of their craft being able to explain their craft

maybe being able to communicate with people outside one’s area of expertise should be taught, and talked about, and considered as a requirement for genuine expertise.

Video: “The State of Agile Software in 2018”

I originally discovered this via a link on Dave Rupert’s blog—along with his relatable commentary:

Whenever I read the original Agile Manifesto and it’s accompanying Twelve Principles, my soul leaps! But in practice inside enterprise Agile frameworks, my soul is often left crushed...In my experience, there seems to be a strongly held belief that if you obey certain rituals: have certain meetings, say certain words, pray certain prayers, commit to improbable deadlines; your product will enter the Promise Land. It’s hard for me to rectify what I know about software development with this religion. I have resigned myself to being an apostate.

However, I didn’t get around to listening to the source video until recently. It’s fantastic. The speaker is Martin Fowler, one of the original signers of the Agile Manifesto. The fact that he basically calls apostasy on what most of us likely participate in as the de-facto, day-to-day, shared implementation of agile, is striking.

with so many differences, how can we say there is one way that will work for everybody? We can’t. And yet what I’m hearing so much...is imposing methods upon people. That to me is a travesty.

Even the agile advocates wouldn’t say that agile is necessarily the best thing to use everywhere. The point is: the team doing the work gets to decide how to do it. That is a fundamental agile principle, which means that if a team doesn’t want to work in an agile-way, then agile probably isn’t appropriate in that context. And that is the most agile-way of doing things.

I can’t help be nod my head in agreement with Dave’s summary: “Fowler’s perspective and patience with the Agile Industrial Complex gives me a foothold to keep from falling into hopelessness.”

Article: “Don’t Solve the Problem” via signalvnoise

Your job as a leader isn’t to just help clarify thought process – but to give confidence in their thinking.

As Wade says, “You’re trying to just help them get to that realization that, ‘You know what to do.’”

They have some good suggestions on 16 questions you can ask to propel those doing the problem-solving, instead of jumping in to solve the problem yourself:

  1. What do you see as the underlying root cause of the problem?
  2. What are the options, potential solutions, and courses of action you’re considering?
  3. What are the advantages and disadvantages to each course of action?
  4. How would you define success in this scenario?
  5. How do you know you will have been successful?
  6. What would the worst possible case outcome be?
  7. What’s the most likely outcome?
  8. Which part of the issue or scenario seems most uncertain, befuddling, and difficult to predict?
  9. What have you already tried?
  10. What is your initial inclination for the path you should take?
  11. Is there another solution that isn’t immediately apparent?
  12. What’s at stake here, in this decision?
  13. Is there an easier way to do what you suggested?
  14. What would happen if you didn’t do anything at all?
  15. Is this an either/or choice, or is there something you’re missing?
  16. Is there anything you might be explaining away too quickly?

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.


Reading Notes, June 2019

Article: “What I Learned Co-Founding Dribbble” by Dan Cederholm

A lot of good reflection in here on Dan’s personal experiences. But what I really liked was this take on keeping a healthy perspective of your digital work in conjunction with the other things in life that are important:

One thing all of this [digital design work] has in common is that it’s all gone. It doesn’t exist anymore. Kaput. Deleted.

Now you can either get really depressed about how digital work is so disposable, or you can view that as a positive. That you can continue to reinvent yourself and your work.

Remember how important some of this stuff seemed at the time? Emergency meetings? Calls while on vacation? There are no lives at stake here. It’s here and then it’s replaced. Something I try to keep in mind when things start getting a little urgent and stressy.

...while pixels can disappear and your work is temporary, people and relationships stick around. Soon, you’ll realize they are the most important part of all of this. Long after the work is gone, if you do things right, you’ll have good people, friends, co-workers, future co-workers around you that will be much more valuable than the things you created.

Video: “The Faker You Are, the More Successful You Can Be” by Pablo Stanley

While specifically targeted at designers and the design industry, I thought this was a rather (comedic) talk on the culture of the technology at large. It’s kind of written in the spirit of the old tale “The Emperor’s New Cloths”, a way of saying “look at these moments in your professional life and realize that nobody is wearing any clothes”.

A couple quotes I liked:

that’s the spirit of the creative: always carrying that soul-crushing insecurity

the more buzzwords you use, the less you have to explain your actual design thinking.

“empathy map”, “user journey maps”, we’re kinda crazy about maps, I don’t know what it is, probably because we’re lost [as an industry].

Article: “Why I don't use web components” by Rich Harris

I think that websites should work without JavaScript wherever possible. Web components don't.

This is a pretty good summary of my feelings in dealing with web components. I particularly like his points about progressive enhancement. I’ve only found web components particularly useful for pieces of your UI that are intrinsically interactive or really small, discrete pieces of UI that can be progressively enhanced quite easily (like Github’s time-elements).

Article: “Freedom”

I thought this was an interesting set of musings about the liberating feeling that comes with a true “personal” computer—a computer that you can do what you want, when you want, how you want—and how that freedom has eroded over time. I think it’s another side of the thoughts I wrote a couple months back about software product interface design. It’s the rationale behind why I can’t move to an iPad as my primary computing device.

Maybe because I lived through this — maybe because I’m a certain age — I believe that that freedom to use my computer exactly how I want to, to make it do any crazy thing I can think of — is the thing about computers.

That’s not the thing about iOS devices. They’re great for a whole bunch of other reasons: convenience, mobility, ease-of-use.

You can do some surface-level automation, but you can’t dig deep and cobble together stuff — crossing all kinds of boundaries — with some scripts the way you can on a Mac. They’re just not made for that. And that’s fine — it’s a whole different thing.

Later:

With every tightened screw we have less power than we had. And doing the things — unsanctioned, unplanned-for, often unwieldy and even unwise — that computers are so wonderful for becomes ever-harder...But if we don’t have this power that is ours, then I don’t actually care about computers at all. It meant everything.

Article: “Perceived Velocity through Version Numbers” by Dave Rupert

A single number bump replaces a mountain of marketing

Dave muses on the versioning numbers behind HTML, CSS, and JavaScript:

In JavaScript, there’s a never-ending stream of libraries, frameworks, polyfills, importers, bundlers, alterna-script languages, and performance problems to write about. It’s sure to dominate the daily programming news cycle. HTML and CSS don’t really have that position and luxury any more. In many ways, the switch to a “Living Standard” have made them dead languages, or at least mostly-dead. New language features don’t show up like they used to, or at least I don’t see the release notes anymore.

I’m on a bit of a quest to understand why these three technologies built to work together are so unequally yoked in popularity and their communities polarized. One end of the spectrum experiences a boom while the other experiences a bust. The rising tide does not lift all boats.

Article: “Codeacademy vs. The BBC Micro”

An interesting look at how the UK government tried to educate their citizens about computers in the 70’s, and how their approach back then compares to the way we “teach computers” now-a-days.

I really liked the author’s points. Especially the idea of teaching general computing principles, not what code to write to make a computer do something, but how and why the computer requires you to write code to run programs (emphasis mine):

“Learn to code” is Codecademy’s tagline. I don’t think I’m the first person to point this out—in fact, I probably read this somewhere and I’m now ripping it off—but there’s something revealing about using the word “code” instead of “program.” It suggests that the important thing you are learning is how to decode the code, how to look at a screen’s worth of Python and not have your eyes glaze over. I can understand why to the average person this seems like the main hurdle to becoming a professional programmer. Professional programmers spend all day looking at computer monitors covered in gobbledygook, so, if I want to become a professional programmer, I better make sure I can decipher the gobbledygook. But dealing with syntax is not the most challenging part of being a programmer, and it quickly becomes almost irrelevant in the face of much bigger obstacles. Also, armed only with knowledge of a programming language’s syntax, you may be able to read code but you won’t be able to write code to solve a novel problem.

As I’ve written before, I suspect learning about computing at a time when computers were relatively simple was a huge advantage. But perhaps another advantage these people had is shows like The Computer Programme, which strove to teach not just programming but also how and why computers can run programs at all. After watching The Computer Programme, you may not understand all the gobbledygook on a computer screen, but you don’t really need to because you know that, whatever the “code” looks like, the computer is always doing the same basic thing. After a course or two on Codecademy, you understand some flavors of gobbledygook, but to you a computer is just a magical machine that somehow turns gobbledygook into running software. That isn’t computer literacy.

I’m banging the drum for “general principles” loudly now, so let me just explain what I think they are and why they are important. There’s a book by J. Clark Scott about computers called “But How Do It Know?” The title comes from the anecdote that opens the book. A salesman is explaining to a group of people that a thermos can keep hot food hot and cold food cold. A member of the audience, astounded by this new invention, asks, “But how do it know?” The joke of course is that the thermos is not perceiving the temperature of the food and then making a decision—the thermos is just constructed so that cold food inevitably stays cold and hot food inevitably stays hot. People anthropomorphize computers in the same way, believing that computers are digital brains that somehow “choose” to do one thing or another based on the code they are fed. But learning a few things about how computers work, even at a rudimentary level, takes the homunculus out of the machine.

Article: “if statements and for loops in css”

An novel take on CSS selectors as if statements and for loops:

menu a {
  color:red;
}
menu a:first-child {
    color: blue;
}
menu a:not(#current) {
    color: red;
}

Now do that imperatively in JS:

for (all menus) {
    for (all links in this menu) {
        let first = [figure out if this is the first link in the menu]
        if (first) {
            link.color = 'blue'
        } else if (link.id !== 'current') {
            link.color = 'red';
        }
    }
}

The drawback of the JavaScript version is that it’s more verbose than the CSS version, and hence more prone to error. The advantage is that it offers much finer control than CSS. In CSS, we’ve just about reached the limits of what we can express. We could add a lot more logic to the JavaScript version, if we wish.

In CSS, we tell the browser how links should look. In JavaScript, we describe the algorithm for figuring out how an individual link should look.

Article: “The web we broke.” by Ethan Marcotte

At the end of February, WebAIM published an accessibility analysis of the top one million home pages. The results are, in a word, abysmal...And we failed. I say we quite deliberately. This is on us: on you, and on me. And, look, I realize it may sting to read that.

But this piece isn’t just a criticism. I like Ethan’s resolution towards building a more-accessible web. It’s a practice I think I could incorporate into anything I want to learn.

The only way this work gets done is if we start small, and if we work together. Instead of focusing on “accessibility” writ large...aim to do one thing this week to broaden your understanding of how people use the web, and adapt your design or development practice to incorporate what you’ve learned.

Or at least, that’s what I’m going to do. Maybe you’d like to join me.


Reading Notes, May 2019

Article: ”Preload, prefect and other tags”

I’ve actually never really taken the time to try and understand exactly the difference between preload, prefetch, preconnect, prerender, etc. This articular sums it up nicely. In fact, I’m going to sum it based on my understanding of how they summed it up. Is that enough summing for you?

There’s a lot more useful and nuanced information in the article beyond what I’ve summarized here. Check it out if you don’t already know the differences.

Article: “Slashed URI”

I actually always wondered why the file scheme had three slashes in it. Now I know—and it makes perfect sense.

a file scheme has 3 slashes (compared to the two used after http) because the scheme for URLs is :/// and since file (in most cases) has no host (it's your machine), it becomes file:/// (ref).

Article: A Complete Guide to useEffect

Really, I just loved this line. I wish more articles I read started with this premise:

There won’t be much to learn. In fact, we’ll spend most of our time unlearning.

Tweet: Key Traits of Great Design by @cameronmoll

Great design can’t ship without great relationships. Be pleasant to work with! Design is the minimum bar, relationships are the highest bar.

Visual hierarchy is...the underpinning of all visual communication. Without it design has no value. “I don’t paint things. I only paint the difference between things.” – Henri Matisse

Problem definition becomes clearer as we begin solving the problem, refine the problem further, solve the problem further, repeat. The process is circular, not linear.

Some good points in there.

Article: “The Back-end for Front-end Pattern (BFF)”

An interesting article detailing the evolution of different application architectures over the years. Though this is specific to SoundCloud’s evolving architecture, it does seem to follow the path trodden by the industry at large.

I found the BFF pattern proposed in the article quite interesting, as it was not a pattern I’d seen before. It does make a lot of sense though. As services became more generic over the years in order to please their consumers, we ended up with clients that had to make possibly hundreds of API calls just to draw a single UI. The idea of having each client maintain its own “server” which reaches out to various services for its own specific needs is really interesting. Granted, GraphQL can do this for you in a sense, but trying to create a GraphQL endpoint that can appease the needs of a variety of clients can end you up in the same dilemma. However, if you spun up multiple “BFF” GraphQL servers, each one specific to its clients needs, then things get interesting!

On a more technical problem, our public APIs almost by definition are very generic. To empower third-party developers to build interesting integrations, you need to design an API that makes no assumptions about how the data is going to be used. This results in very fine-grained endpoints, which then require a large number of HTTP requests to multiple different endpoints to render even the simplest experiences...The idea was that having the team working on the client own the API would allow for them to move much quicker as it required no coordination between parts

Article: “Learn in Public”

I’ve known Shawn for a little while online, but just recently met him in person. We got to talking about a variety of things and he told me about this short little piece of writing he’d done sometime past. So I looked it up and read it. It’s good. I like the metaphor that comes to mind of “creating learning exhaust”. I think that makes writing feel more feasible and accessible. What you produce doesn’t have to be Hemingway; rather it’s often just going to be the byproduct of your learning.

You already know that you will never be done learning. But most people "learn in private", and lurk. They consume content without creating any themselves…What you do here is to have a habit of creating learning exhaust. Write blogs and tutorials and cheatsheets. Speak at meetups and conferences. Ask and answer things on Stackoverflow or Reddit. (Avoid the walled gardens like Slack and Discourse, they're not public). Make Youtube videos or Twitch streams. Start a newsletter. Draw cartoons (people loooove cartoons!). Whatever your thing is, make the thing you wish you had found when you were learning…just talk to yourself from 3 months ago.

Article: “In defence of boring UX”

An interesting and fresh perspective on digital design. No matter what aesthetics you put into your app, that’s never what people talk about. They don’t talk about what it looks like, that’s what designers talk about. They talk about what they can do with it.

I’ve been feeling this more and more. Quite often I’d honestly prefer system-native controls instead of custom styled or custom designed up controls. They’re boring, but they’re familiar and usable and dependable. And boring.

But big or small, I beg you, stay boring. Because true delight will always live outside your product. As Chris Kiess notes, “I’ve spent a lot of time in the field on various projects and it is rare I find a user who comments on some aspect of a feature I had discussed ad nauseam with my team.”

Endless debates about indentations, rounded corners, and colour choices are UX’s version of the sunk cost fallacy. Nothing digital design can offer compares to the experiential joy of an Airbnb host in Dublin recommending the perfect nearby bar. Or a Chicago Lyft driver giving you a dozen amazing food and drink suggestions. Or cycling confidently through Portland at 11pm thanks to turn-by-turn instructions on a Pebble watch.

Article: Plain Text vs. HTML Emails: Which Is Better?

I can’t believe I’m linking to HubSpot, but let truth come from whence it may.

I’ve long been a fan of plain text emails (really plain text anything). And now I have some serious data to back up my gut feeling.

Aside from proper list segmentation, nothing boosts opens and clicks as well as an old school, plain-text email.

What’s really interesting about this data is that people say they prefer HTML emails and visuals, but the data shows the opposite of what people say:

In a 2014 survey, we asked over a thousand professionals whether they preferred HTML-based or text-based emails, and whether they preferred emails that consisted of mostly text or mostly images. Nearly 2/3 of the respondents said they preferred HTML and image-based emails...[However] In every single A/B test...The emails with fewer HTML elements won with statistical significance.

The authors of the article I think get to the root of what I’ve always felt about email: it’s a 1-to-1 interaction:

For example, shouldn't an email with an image of the ebook being promoted do better than an email with no visualization of the offer? Wouldn't just a plain email be boring, and not help explain the offer? Aren't humans wired to be attracted to beautiful design?

Unfortunately, this principle doesn't apply to email.

And the reason is simple: Email, unlike other marketing channels, is perceived as a 1-to-1 interaction.

Think about how you email colleagues and friends: Do you usually add images or use well-designed templates? Probably not, and neither does your audience. They're used to using email to communicate in a personal way, so emails from companies that look more personal will resonate more.

Again the data backing these claims up is quite significant:

For the click rate, we dove into data from over half a billion marketing emails sent from HubSpot customers. These customers vary in type of business, and have different segments, list sizes, and list compositions.

What we found was that even a single image reduced the click rate

That plain text performs better than HTML emails is no small claim, especially from a marketing company like HubSpot. The cynical part of me doubts that much will come of it, though. As the author of the article states:

Ultimately, in email, less is more.

This can be a tough pill for marketers to swallow (myself included)...But data repeatedly shows plain-text email wins, so it's up to us to decide whether or not we want to make the switch.

At least now I’ve got some good data to backup my gut.

Article: “The inception bar: a new phishing method”

An interesting look at a new phishing method:

There seems to be a trade-off, between maximizing screen space on one hand, and retaining trusted screen space on the other. One compromise could be to retain a small amount of screen space to signal that “the URL bar is currently hidden”, instead of giving up literally all screen space to the web page.

Safari on mobile has an interesting approach in that the url bar shrinks on scroll but the domain always stays visible in the UI. I like that.

Some browser makers seems to be more and more trying to get rid of the URL, both from and engineering and a UI/UX perspective. Personally I think we should be doing the opposite. We should double down on the URL of a website and make sure it’s treated as a cornerstone of browser UI.


Reading Notes, March 2019

Website: “Always Own Your Platform”

You know, it wasn't that long ago. There was RSS. There were blogs...Now? [Social media sites] control what gets amplified and what gets monetized. A few conference rooms in Silicon Valley dictate our online culture.

What I actually really loved about this site and found rather witty and novel was how it appeared when linked to in my twitter feed:

Screenshot of tweet on twitter

I found the anarchist, "freedom fighter" approach to this site’s open graph metadata rather novel and amusing.

Talk: “Webhooks and Events and Microservices, oh my!” from Phil Hawksworth

Phil once heard someone say, “I wouldn’t use a minimum viable parachute” to which he responds “I would if I was in a situation where I needed a parachute”. His point being:

MVP is not choosing a weak product over a good product. MVP is choosing to have something now and something better later.

Article: “Going Offline—the talk of the book” by Jeremy Keith

Jeremy discusses some of his strategy around presenting code when your audience is more than just developers (or even code beginners):

logic is more important than code. In other words, figuring out what you’re trying to accomplish (and describing it clearly) is more important than typing curly braces and semi-colons. Programming is an act of translation. Before you can translate something, you need to be able to articulate it clearly in your own language first.

I think this is an excellent strategy for making code less overwhelming to people who would otherwise be unfamiliar with it.

Article: “Maybe the web should die” by Paul Miller

I click Buzzfeed links and Verge links and Awl links and Polygon links for the same reason anybody does: there's a hole in my heart, and I hope 300-400 words of web content will fill it

A couple more assessments:

wouldn't it be nice to live in a world where I never have to read something that was written for the sole purpose of traffic and revenue?

More than half the time when I'm at Buzzfeed and The Verge (I keep using Buzzfeed and The Verge as examples because I visit them a lot apparently), I get the distinct feeling that this publication has “no special interest in publishing beyond value extraction through advertising”. And if that’s the case, then it’s really important that I, as a human being with presumably better things to do, should avoid publications that make me feel this way.

online publications seem to have coalesced around the worst elements: huge ads, disposable content, auto-play videos, Like and Tweet buttons which follow you around the internet, hidden embedded pixels that try and guess your eye color so they can sell you shampoo more effectively.

Towards the end:

The reason there’s no solid revenue alternative to advertising for most of these websites is that most of what they put out is junkfood clickbait designed to increase revenue through ads. They can’t monetize it because it’s worthless. Is that ironic?


Reading Notes, February 2019

Article: “Emoji Avatars for My Website”

Kind of a cool/fun way of authoring content and controlling the style of that content by way of the emoji embedded in the content. Essentially, if he embeds a select emoji in his post, he has an equivalent photographical expression of his own face as an avatar for the post. Cool idea.

Podcast: “Fighting the Hype in Technology”

You don’t have to listen to the whole thing, but I thought this observation by Paul Ford (about 26 minutes in) was really great. It’s something that never really gets talked about. I feel like working in software is always talked about as this dreamy, change-the-world endeavor. But the reality is just getting something out the door that people will actually want to use can be a monumental effort. If you can do that, if you can ship something that’s good enough for people to want to use it, that’s pretty damn good. You should give yourself a pat on the back.

the fundamental problem that most people are facing is not, “how do I apply technology X to get, you know, incredible yields?” That’s a very startup-y, West Coast kind of problem. The problem most people have is: can I get a good enough piece of software shipped that people want to use? That’s it — that is it, and that is...still the fundamentally hardest thing that most people can pull off...And especially at an organizational level. If you’re in a big org, just trying to get good software out the door [is incredibly hard]. (emphasis mine)

Article: “Please, Throw Away Used Whiteboard Markers” via Postlight

day after day, year after year, people go to the whiteboard, use a faint marker, and then just leave that marker for the next person. After all, they think, it still has a little ink left. Maybe someone likes faint marker lines. Maybe someone will come along at night and refill it. Or it might naturally grow new ink. Really, who can say?

I think there’s a little gap of knowledge in all of us around how whiteboard markers work – which is why, when we pick one up and use it only to find its output faint and unreadable, we put the cap back on. “It’s probably got something left in it, I just don’t know how to coax it out. I’m sure someone else smarter than me will know how.”

This piece reminded me of someone I worked with who, whenever they found a used marker, would always put the cap back on and dramatically chuck it across the conference room towards the trash. It was beautiful thing.

Article: More Good Programming Quotes

Some of my favorites:

“Much of the essence of building a program is in fact the debugging of the specification.” — Fred Brooks

“A common fallacy is to assume authors of incomprehensible code will be able to express themselves clearly in comments.” — Kevlin Henney

“Sufficiently advanced abstractions are indistinguishable from obfuscation.” — @raganwald

Then later, a few favorites in the comments:

“If at first you don’t succeed, call it version 1.0.” — Unknown

“It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.” — Steve Jobs

“The most important thing in communication is to hear what isn’t being said.” — Peter Drucker

“Management is doing things right; leadership is doing the right things.“ — Peter Drucker

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” — Bill Gates

“No one’s life has yet been simplified by a computer.” — Ted Nelson

“If you think good architecture is expensive, try bad architecture.” — Brian Foote

“The bearing of a child takes nine months, no matter how many women are assigned.” — Frederick P. Brooks Jr.

“To err is human but to really foul up requires a computer.” — Dan Rather

“The business of software building isn’t really high-tech at all. It’s most of all a business of talking to each other and writing things down. Those who were making major contributions to the field were more likely to be its best communicators than its best technicians.” — Tom DeMarco


Reading Notes, January 2019

Article: “Busy is the new stupid”

You can’t claim time on anyone else’s calendar, either. Other people’s time isn’t for you — it’s for them. You can’t take it, chip away at it, or block it off. Everyone’s in control of their time. They can give it to you, but you can’t take it from them.

The video was especially interesting.

Article: “Four Cool URLs”

A neat look at varying URL designs. The author touches on the idea of designing URLs so that users can construct a URL without having to actually use your site. Additionally, as users become more familiar a site’s URL patterns, you’ll find it’s often quicker to edit the URL rather than use the GUI to navigate the application or website.

I’ve been thinking about URL design more and more lately. In fact, on my icon gallery sites I designed the URLs of each icon “resource” to act as my API for accessing the icon’s artwork:

I could leverage my site’s URLs as an interface for getting icons, i.e. /icons/:id/ for the HTML representation of the icon and /icons/:id/:size.png for the actual icon (i.e. /icons/facebook/512.png would give me facebook’s 512px app icon).

Video: “In The Loop” by Jake Archibald at JSConf.Asia 2018

A great, visually-instructive talk about the event loop and how your JavaScript actually gets executed by the browser. He has some great examples of gotchas that are worth wrapping your head around. Like this one: if the user clicks the button, in what order are things logged?

Two event listeners in JavaScript

His descriptions of tasks, animation callbacks, and micro tasks, from the perspective of the browser, were all eye opening. Great talk for anyone doing JavaScript.

Article: “CSS for JavaScripters 1” via quirksmode.org

An interesting take on explaining CSS to “JavaScripts” through the lens of JSON:

Like JSON files, CSS files are not programs. but a series of declarations that programs use in order to create output. Also, they fail silently when they contain instructions that the receiving program does not understand.

If you approach CSS as you approach JSON you’ve taken a step toward understanding it.

Article: “Thieves of experience: On the rise of surveillance capitalism” by Nicholas Carr

Nicholas Carr, in reviewing a new book, is at it again: writing counterpoints to the Silicon Valley gospel.

Zuboff’s fierce indictment of the big internet firms goes beyond the usual condemnations of privacy violations and monopolistic practices. To her, such criticisms are sideshows, distractions that blind us to a graver danger: By reengineering the economy and society to their own benefit, Google and Facebook are perverting capitalism in a way that undermines personal freedom and corrodes democracy.

Later:

Whenever we use free apps and online services, it’s often said, we become the products, our attention harvested and sold to advertisers. But, as Zuboff makes clear, this truism gets it wrong. Surveillance capitalism’s real products, vaporous but immensely valuable, are predictions about our future behavior — what we’ll look at, where we’ll go, what we’ll buy, what opinions we’ll hold — that internet companies derive from our personal data and sell to businesses, political operatives, and other bidders.


Reading Notes, December 2018

Article: “React v16.7: No, This Is Not The One With Hooks” via reactjs.org

I like how transparent and intentional the react team is with what they do. When there are significant or strategic changes, they don’t just say “here’s a new release” and plop something onto npm. Their corresponding release blog posts explain what they did and why they did it.

This particular post is a great example of their thoroughness. They explain their theoretical position on semver and why they intentionally release the way they do. I love it.

Patches are the most important type of release because they sometimes contain critical bug fixes. That means patch releases have a higher bar for reliability. It’s unacceptable for a patch to introduce additional bugs, because if people come to distrust patches, it compromises our ability to fix critical bugs when they arise — for example, to fix a security vulnerability

They also touched on their regret for how they versioned their recent releases: they conflated their software release version (“semver”) with their marketing release version (“hooks”) (and it came back to bite them in the butt). This is something we’d all do well to remember:

At React Conf, we said that 16.7 would be the first release to include Hooks. This was a mistake. We shouldn’t have attached a specific version number to an unreleased feature. We’ll avoid this in the future.

Good principles to remember.

Article: “Optimized for Change” by Dan Abramov

What’s a crucial aspect of designing APIs?

The best API designers I know don’t stop at the “first order” aspects like readability. They dedicate just as much, if not more, effort to what I call the “second order” API design: how code using this API would evolve over time.

A slight change in requirements can make the most elegant code fall apart...[great APIs] are optimized for change.

Article: “JIRA is an Antipattern” via techcrunch

One thing that writing elegant software has in common with art: its crafters should remain cognizant of the overall macro vision of the project, at the same time they are working on its smallest micro details. JIRA, alas, implicitly teaches everyone to ignore the larger vision while focusing on details. There is no whole...JIRA encourages the disintegration of the macro vision.

A scathing assessment of how Jira is commonly used. Personally, I like the author’s conclusion: Jira can be great for issue tracking, but for anything larger it works against you. I also like the suggestion of prose as a description of the project. If we all had to write out – in natural language – what we were doing in software, I think we’d discover a lot more holes in our thinking which we’d then be forced to patch up. Jira makes it easy for you to bypass all of that and just write simple, vague depictions of what you’re trying to do.

Article: “Why Doctors Hate Their Computers” by Atul Gawande via The New Yorker

A fascinating look at technology’s influence on doctors (based on years of experience by a well-renowned doctor).

First, there’s the realization that some of the constraints prior to digitalization were actually beneficial:

piecing together what’s important about the patient’s history is at times actually harder than when [we] had to leaf through a sheaf of paper records. Doctors’ handwritten notes were brief and to the point. With computers, however, the shortcut is to paste in whole blocks of information—an entire two-page imaging report, say—rather than selecting the relevant details. The next doctor must hunt through several pages to find what really matters.

That’s when you start to realize that technology has its benefits, but you likely traded one set of problems for another. For doctors, apparently technology is becoming so overbearing that we’re hiring for jobs which didn’t exist to handle the computerization of everything:

We replaced paper with computers because paper was inefficient. Now computers have become inefficient, so we’re hiring more humans [to complete computer-related tasks].

Which results in us humans acting like robots in order to fulfill the requirements of the systems we built:

Many fear that the advance of technology will replace us all with robots. Yet in fields like health care the more imminent prospect is that it will make us all behave like robots”

The author’s solution?

We can retune and streamline our systems, but we won’t find a magical sweet spot between competing imperatives. We can only insure that people always have the ability to turn away from their screens and see each other, colleague to colleague, clinician to patient, face to face.

Tool: htm

JSX-like syntax in plain JavaScript - no transpiler necessary.

A tool that essentially lets you do JSX but in the browser (no transpiling). This is really awesome when you want to leverage native es modules for react in the browser and not transpile.

Article: “Prototypes and Production” by Jeremy Keith

Was just doing something similar and feel the same way. When building a prototype, you throw so many best practices to the wind:

Whereas I would think long and hard about the performance impacts of third-party libraries and frameworks on a public project, I won’t give it a second thought when it comes to a prototype. Throw all the JavaScript frameworks and CSS libraries you want at it (although I would argue that in-browser technologies like CSS Grid have made CSS libraries like Bootstrap less necessary, even for prototyping).

Remember, however, that prototypes quite often gain their utility through their ability to be like a piece of paper: you sketch out your ideas quickly with low friction, you learn what you don’t want, then you throw it away.

Build prototypes to test ideas, designs, interactions, and interfaces…and then throw the code away. The value of a prototype is in answering questions and testing hypotheses. Don’t fall for the sunk cost fallacy when it’s time to switch over into production mode.

Video: “The Transformative Power of Classical Music”, a TED Talk by Benjamin Zander

Not a talk about software, but has some good insights into what makes a great leader:

The conductor of an orchestra doesn’t make a sound. He depends for his power on the ability to make other people powerful...I realized my job is to awaken possibility in other people...

He says the way you can tell if you’re awakening possibility in other people is by looking into their eyes. And if someone’s eyes aren’t reflecting that awakened possibility, then you have to ask:

Who am I being that my player’s eyes are not shining?

And that can extend to anyone in your sphere of influence: “who am I being that my [children’s / employees’ / friends’] eyes are not shining?”


Reading Notes, November 2018

Quote: On Software Development

With every passing day that I work in technology, I find this quote more and more relevant:

replace “can you build this?” With “can you maintain this without losing your mind?” – Nicholas Gallagher

Article: “Against Software Development”

An interesting, and short, look at problem areas of software development. This line has been lingering in my head for a few days:

Perhaps we should expect true advances in software “engineering” only when we learn how better to govern ourselves.

Article: “Programmer Archeologists”

This sounds like a future we could very possibly live in:

In Verner Vinge’s space opera A Deepness in the Sky, he proposes that one of this future’s most valuable professions is that of Programmer-Archaeologist. Essentially, the layers of accreted software in all large systems are so deep, inter-penetrating, idiosyncratic and inter-dependent that it has become impossible to just re-write them for simplicity’s sake – they genuinely can’t be replaced without wrecking the foundations of civilization. The Programmer-Archaeologist churns through this maddening nest of ancient languages and hidden/forgotten tools to repair existing programs or to find odd things that can be turned to unanticipated uses.

Article: ”’It’s Not a Bug, It’s a Feature.’ Trite—or Just Right?” by Nicholas Carr via Wired

It’s not a bug, it’s a feature is an acknowledgment, half comic, half tragic, of the ambiguity that has always haunted computer programming.

In the popular imagination, apps and other programs are “algorithms,” sequences of clear-cut instructions that march forward with the precision of a drill sergeant. But while software may be logical, it’s rarely pristine. A program is a social artifact. It emerges through negotiation and compromise, a product of subjective judgments and shifting assumptions. As soon as it gets into the hands of users, a whole new set of expectations comes into play. What seems an irritating defect to a particular user—a hair-trigger ­toggle between landscape and portrait mode, say—may, in the eyes of the programmer, be a specification expertly executed.

Shortly after reading this article, I found this lovely t-shirt:

T-shirt where a bug is dressed up as a feature

Article: “Choose Boring Technology”

An interesting opinion piece on how “boring” technology can be a pretty safe bet:

The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.

New technology has a much larger magnitude of failure modes that are unknown. We all know this. Searching for a way to fix something (which is huge part of you’re job as a developer) that’s been around 10 years is much easier than searching for a to fix something that’s been around 10 days.

It can be amazing how far a small set of technology choices can go...If you think you can't accomplish your goals with what you've got now, you are probably just not thinking creatively enough.

That seems to be the embodiment of JavaScript.

Video: “Make the Right Thing the Easy Thing: Designing Processes Teams Will Actually Follow” by Jason Lengstorf

I thought this was a really great presentation around how to be effective building software.

If you have a rockstar and everyone on the team is deferring to the rockstar, you have fewer people on your team taking initiative. If you have a team of 10 people and 9 of them, when you ask a question, just turn to look at the senior dev to see what their solution is, you’ve just lost 9 brains worth of thinking power.

You have to ask yourself:

What are the underlying problems that created the need for a rockstar to come in and fix everything?

He makes a point about how code reviews get a bad rap because a lot of teams only conduct code reviews when something is wrong:

Code reviews are a chance for the lead developer to flog someone in the public square because they did something that, I don’t know, was a memory hog. That is not what a code review should be. I think that code reviews should mostly be when someone does something that you like. Pull it up in front of the entire team and walk through what they did right. Then talk about all the other ways it could’ve been written that wouldn’t have been optimal. Show what the anti-pattern could’ve been, and praise what was done.

[As a senior developer] You should be constantly failing in front of your team then showing them how you learn from your mistakes, because that’s how you got where you are — that’s how you became a senior developer.

A really good point on thinking about longevity in the things you build:

Use stable open source tools if that option exists because if you build something in house you are now saying “this tool, in addition to our product, is something that we need to maintain and staff.”

Write code that’s small and easy to delete...when you optimize for deletion, you don’t have to write code that’s valid five years in the future...[google scale] you should be building features for 500 rather than optimizing for 5 million...weight the tradeoffs and choose the thing that will make your team more productive, not the thing that will make your app best in ten years.


Reading Notes, October 2018

Article: Design Principles – React

I’d never read this before. It‘s a document from the React team stating, essentially, the philosophical underpinnings of why the build software they way they do.

One of the things I found interesting was their perspective on setState() and why it’s asynchronous. After all the things that’ve been said about setState() their articulation about how they think about it is probably the most helpful I’ve heard and what we should teach to beginners: that it’s not so much about “setting state” as it is “scheduling an update”. of what setState() a

There is an internal joke in the team that React should have been called “Schedule” because React does not want to be fully “reactive”.

One of the real powers I think behind React is the ability you have as a developer to trace as state of the UI to the data that produced it. This explicit design goal really does “turn debugging from guesswork into a boring but finite procedure”:

If you see something wrong on the screen, you can open React DevTools, find the component responsible for rendering, and then see if the props and state are correct. If they are, you know that the problem is in the component’s render() function, or some function that is called by render(). The problem is isolated.

If the state is wrong, you know that the problem is caused by one of the setState() calls in this file. This, too, is relatively simple to locate and fix because usually there are only a few setState() calls in a single file.

If the props are wrong, you can traverse the tree up in the inspector, looking for the component that first “poisoned the well” by passing bad props down.

This ability to trace any UI to the data that produced it in the form of current props and state is very important to React. It is an explicit design goal that state is not “trapped” in closures and combinators, and is available to React directly.

While the UI is dynamic, we believe that synchronous render() functions of props and state turn debugging from guesswork into a boring but finite procedure.

I also liked the section where they talked about their own internal style of developing the React codebase and how practicality generally trumps elegance:

Verbose code that is easy to move around, change and remove is preferred to elegant code that is prematurely abstracted and hard to change.

Article: “Preparing a conference talk” via adactio

An thoughtful writeup behind how Jeremy prepares for his conference talks. I like this part about how even a plain text file, which seems open-ended, still enforces a certain kind of linear constraint, whereas a blank sheet of paper and a pencil is truly more open-ended:

I used to do this mind-mapping step by opening a text file and dumping my thoughts into it. I told myself that they were in no particular order, but because a text file reads left to right and top to bottom, they are in an order, whether I intended it or not. By using a big sheet of paper, I can genuinely get things down in a disconnected way (and later, I can literally start drawing connections).

Video: “"Shaping our children's education in computing” by Simon Peyton Jones at Strange Loop 2018

About the first twenty minutes of this talk (before he gets into the Brittian-specific stuff) is absolutely fantastic.

Education should prepare young people for jobs that do no yet exist, using technologies that have not yet been invented, to solve problem of which we are not yet aware.

His main point is that we (in computers) often put too much focus on technology and not enough on ideas. He showed this really cool video about how you could illustrate sorting algorithms to kids without using any technology. His point is that we need more that encourages inquisitiveness and imagination.

He also makes good arguments about why we should teach “computer science” (again, ideas not technology) to kids. Technologies come and go, but the underlying ideas persist:

Why do we teach biology to kids? Do we expect every kid to become a biologist? No. It’s about coming to understand the world you live in and how you can navigate it, how to take control of events in your life and not just be at their mercy.

Education shouldn’t be about teaching a skill and splitting someone out at the end who is armed with that skill. Rather we teach skills or reason and dedication and problem solving so that when they get spit out, they can navigate the successive waves of technology that will come at them over their careers. Knowing one won’t be enough.

Article: “Taking Pattern Libraries to the Next Level” via Smashing Magazine

We love to talk about “Atomic Design” and “Pattern Libraries” but I found this to be an even more thoughtful look at why those things aren’t silver bullets and how you need an even more thoughtful, overarching design system.

A strong design is informed by a view of the big picture, an understanding of the context, and strong art direction — even at the cost of consistency or time.

Design doesn’t emerge by skinning or theming components; it needs a perspective and a point of view — it desperately needs creative guidance. However, I can’t help but notice that when we are building these lovely pattern libraries and design systems and style guides using fantastic tools such as Pattern Lab and living style guides, we tend to settle on a single shared view of how a pattern library should be built and how it should appear. Yet that view doesn’t necessarily result in a usable and long-lasting pattern library

Article: In Praise of Mediocrity via the NYTimes

The article as a whole felt lacking, but there were a few particular lines that caught my eye as relevant:

We’re afraid of being bad at [hobbies]. Or rather, we are intimidated by the expectation...that we must actually be skilled at what we do in our free time. Our “hobbies,” if that’s even the word for them anymore, have become too serious, too demanding, too much an occasion to become anxious...If you’re a jogger, it is no longer enough to cruise around the block; you’re training for the next marathon. If you’re a painter, you are no longer passing a pleasant afternoon, just you, your watercolors and your water lilies; you are trying to land a gallery show or at least garner a respectable social media following. When your identity is linked to your hobby...you’d better be good at it, or else who are you?

Then later:

The demands of excellence are at war with what we call freedom. For to permit yourself to do only that which you are good at is to be trapped in a cage

This probably stuck out to me because of my post “The Art of the Side Project” I wrote back at the beginning of 2017. Still seems relevant.

Article: “Netlify DX Q&A: Gatsby v2 with Jason Lengstorf” via Netlify

Interview with Jason Lengstorf who is a developer advocate for Gatsby. I liked this bit which referrs to graphql but it’s how I feel about most technology I use. It’s my adoption cycle:

Learn about GraphQL
Dismiss it as a fad
Keep hearing about it
Try it out
Hate it
Keep trying
Things click
Never willingly use anything but GraphQL ever again

Article: “The Rise and Demise of RSS”

An interesting look at what happened to RSS. What I found interesting was the author’s “moral of the story” about how hard building consensus is (whether it’s in open source software, or even just in a business):

But the more mundane reason [why RSS failed] is that centralized silos are just easier to design than common standards. Consensus is difficult to achieve and it takes time, but without consensus spurned developers will go off and create competing standards. The lesson here may be that if we want to see a better, more open web, we have to get better at not screwing each other over.

Tweet: “@asymco on data”

This just seems so true, probably because I subscribe to “people can come up with statistics to prove anything”:

If you have enough data you can prove anything. Which is to say that with enough data everything is true, so nothing is. All great insights I’ve ever seen have come from n=1.

Article: “Aesthetics” via Information Architects

Following on the heels the previous tweet, there’s this piece from the ever insightful folks over at ia.net. Here are a few of the pieces that stood out to me.

Not the master designer but the user is the arbitrator of good design.

The world was sucked into a medium that allowed measuring the performance of forty-one shades of blue. And thus the notion of good and bad design radically changed. Design used to be about sensitivity, beauty, and taste. Today, design is about what engages users and grows profits.

The key performance indicator for design has changed from beauty to profit. Measuring design has transformed a handicraft into an engineering job. The user is king. The user decides what is good and what is bad design

We are also beginning to realize eliminating what is not measurable may come at an unmeasurable cost.

How much of what us human is truly measurable and verifiable?

How do we measure friendship? By the number of replies per month? By the length of replies? With computer linguistics? How do we measure usefulness? Lots of page views? Few page views? Stickiness? Number of Subscriptions? How do we measure trust? By the number of likes? Retweets? Comments? How do we measure truth?

However, out of experience, we know those good things are rare, that quality always comes at a price and that the price tag of quality grows exponentially.

We also know that what is truly good is somehow beautiful, and what is truly beautiful is somehow good. It’s not a direct relationship, it’s a deeper connection.

My comment: Silicon Valley’s law: all software problems will be resolved with more software


Reading Notes, September 2018

Article: The Rise and Rise of JSON

An interesting little story about how JSON rose to its prominence today. It’s probably an illustration of the rule of least power (“choose the least powerful language suitable for a given purpose”). In fact, the article’s author states as much:

my own hunch is that people disliked XML because it was confusing, and it was confusing because it seemed to come in so many different flavors.

The author goes on to say:

XML was designed to be a system that could be used by everyone for almost anything imaginable. To that end, XML is actually a meta-language that allows you to define domain-specific languages for individual applications...And yet here was JSON, a format offering no benefits over XML except those enabled by throwing out the cruft that made XML so flexible.

The simplicity of JSON, which I’m sure is often ridiculed, is quite fascinating in comparison to XML:

The first lines of a typical XML document establish the XML version and then the particular sub-language the XML document should conform to. That is a lot of variation to account for already, especially when compared to JSON, which is so straightforward that no new version of the JSON specification is ever expected to be written.

There were a few little historical tidbits I found interesting in this story. For example, when Douglas Crockford first implemented what would become “JavaScript object notation” by embedding a <script> tag in HTML, he ran into a problem where dynamically written keys could conflict with reserved words in JavaScript, so he just required all key names to be quoted. JSON requires quoted key names to this day.

There’s also the story about the name and the spec:

Crockford and Morningstar...wanted to name their format “JSML”, for JavaScript Markup Language, but found that the acronym was already being used for something called Java Speech Markup Language. So they decided to go with “JavaScript Object Notation”, or JSON. They began pitching it to clients but soon found that clients were unwilling to take a chance on an unknown technology that lacked an official specification. So Crockford decided he would write one.

On, and there was so linked reading in the article, some of which I followed. I liked this comment on XML, which put into words my feelings based on experience with XML:

I spend a disproportionate amount of my time wading through an endless sea of angle brackets and verbose tags desperately searching for the vaguest hint of actual information

Video: “Why Greatness Cannot Be Planned: The Myth of the Objective”

The path to success is through not trying to succeed. To achieve our highest goals, we must be willing to abandon them.

In a lot of ways, that’s the premise of this talk. And I, for one, thought his points resonated a lot with my own experiences of creativity. There’s quite a few paradoxical findings here.

Article: “The top four web performance challenges” by Jeremy Keith

One outcome was to realise that there’s a tendency (in performance, accessibility, or SEO) to focus on what’s easily measureable, not because it’s necessarily what matters, but precisely because it is easy to measure.

Too true.

I think incremental and iterative improvements can be served well by measurements. But vast, innovative improvements and directional changes in product need more than analytics. They need vision and taste from humans.

Here’s a thought? Things that are measurable are like the micro of products, whereas vision and taste are the macro.

Article: Why Trump Tweets (And Why We Listen) by Nicholas Carr

Once again, an interesting opinion from Nicholas Carr into our current political state and its relationship to modern technology.

Twitter’s formal qualities as an informational medium—its immediacy and ephemerality, its vast reach, its lack of filters—mirror and reinforce the impulsiveness, solipsism, and grandiosity that define Trump’s personality and presidency and, by extension, the times. Banal yet mesmerizing, the president’s Twitter stream distills our strange cultural moment—the moment the noise became the signal.

Gambling and social media:

A similarly seductive dynamic [to gambling] plays out on the screens of social media apps. Because tweets and other posts also offer unpredictable rewards—some messages go viral, others fall flat—they exert the same kind of pull on the mind. “You never know if your next post will be the one that delivers a jackpot.”

And how that relates to Trump:

Trump’s tweets don’t just amass thousands of likes and retweets. They appear, sometimes within minutes of being posted, in high-definition blowups on "Fox & Friends" and "Morning Joe" and "Good Morning America." They’re read, verbatim, by TV and radio anchors. They’re embedded in stories in newspapers and on news sites, complete with Trump’s brooding profile picture. They’re praised, attacked and parsed by Washington’s myriad talking heads. When Trump tweets—often while literally watching the TV network that will cover the tweet—the jackpot of attention is almost guaranteed. Trump, by all accounts, spends an inordinate amount of time monitoring the media, the outsized coverage becomes all the more magnified in his mind. And as the signals flow back to him from the press, he is able to fine-tune his tweets to sustain or amplify the coverage. For Trump, in other words, tweeting isn’t just a game of chance. It’s a tool of manipulation. Twitter controls Trump, but Trump also controls Twitter—and, in turn, the national conversation.

On the nature of the medium that is Twitter:

With its emphasis on brief messages and reflexive responses, Twitter is a medium that encourages and rewards [a] reductive view of the world...it’s an invitation to shallowness.

And what that leads to:

Twitter relieves the president [and many of its users] of the pressure to be well-informed or discerning, even when he’s addressing enormously complicated issues like the North Korean nuclear threat...Twitter gives Trump [and again its users] license to sidestep rational analysis.

More acutely:

We listen so intently to Trump’s tweets because they tell us what we want to hear about the political brand we’ve chosen. In a perverse way, they serve as the rallying cries of two opposed and warring tribes...[Trump] succeeds in pulling the national conversation down to his own level—and keeping it there.

On a more philosophical level:

Thanks to the rise of networks like Twitter, Facebook and Snapchat, the way we express ourselves, as individuals and as citizens, is in a state of upheaval, an upheaval that extends from the family dinner table to the upper reaches of government. Radically biased toward space and against time, social media is inherently destabilizing. What it teaches us, through its whirlwind of fleeting messages, is that nothing lasts. Everything is disposable. Novelty rules. The sense that “nothing matters,” that wry, despairing complaint of people worried about national politics right now, isn’t just a Trump phenomenon; it’s built into the medium.


Reading Notes, August 2018

Video: Steve Jobs responds to an Insult

Jobs responding to a question/insult about a particular technology. I think his response is a good reminder that before any technology, you need vision and principles for what you’re doing. Those will guide you more than any technology. In fact, focusing too much on just what’s going on with the tech can often blind you to the potential of what you’re trying to do.

As we have tried to come up with a strategy and a vision for Apple, it started with “what incredible benefits can we give the customer, where can we take the customer?” not starting with “let’s sit down with the engineers and figure out what awesome technology we have and how we are going to market that?” And I think that’s the right path to take.

Article: “Weft” by Ethan Marcotte

I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.

Later:

the visual languages we formalize—they’re artifacts that ultimately live in a broader organizational context. (And in a context that’s even broader than that.) A successful design project understands that context before settling on a solution

Article: “UTC is enough for everyone...right?” by Zach Holman

This is just a fantastic deep dive into working with dates and time in programming.

Tweet: Debugging techniques with customized console.log via @brian_d_vaughn

screenshot of customized console.log calls

One of the most powerful web debugging techniques I'm aware of is adding colors to console.log. Makes it possible to spot high level patterns in an otherwise noisy stream of data.

A cool technique I didn’t know existed. There’s also a gist on how to implement.

Tweet: How selective sampling works by

A neat little .gif depicting the idea of downsampling in computer graphics but on a physical, real-world object.

Article: Flexibility by Jeremy Keith

Jeremy quoting from and commenting on the new book Flexible Typesetting from A List Apart.

It appears the book nods to the materiality of creating things for the web. Specifically, typography on the web should honor and respect the nature of its medium, which tends towards design being a suggestion, not a mandate. Here’s a quote from the book:

Of course typography is valuable. Typography may now be optional [on the web], but that doesn’t mean it’s worthless. Typographic choices contribute to a text’s meaning. But on the web, text itself (including its structural markup) matters most, and presentational instructions like typography take a back seat. Text loads first; typography comes later. Readers are free to ignore typographic suggestions, and often prefer to. Services like Instapaper, Pocket, and Safari’s Reader View are popular partly because readers like their text the way they like it

As the author states, “Readers [on the web] are typographers, too.”

Article: “The Bullshit Web”

First, the author gives us a preface from David Graeber detailing what he means by “bullshit”:

Huge swathes of people...spend their entire working lives performing tasks they secretly believe do not really need to be performed. The moral and spiritual damage that comes from this situation is profound. It is a scar across our collective soul. Yet virtually no one talks about it...These are what I propose to call ‘bullshit jobs’.

Then gives a good example of the kind of bullshit going on in the web: CNN claiming to have the highest number of “video starts” in their category. This is a stat that we all know doesn’t represent anything real but I’m sure goes over well in a marketing meeting:

I don’t know exactly how many of those millions of video starts were stopped instantly by either the visitor frantically pressing every button in the player until it goes away or just closing the tab in desperation, but I suspect it’s approximately every single one of them.

Or what about those “please sign up for our newsletter” emails?

[newsletter signup forms are everywhere.] Get a nominal coupon in exchange for being sent an email you won’t read every day until forever.

As a developer, you probably think “these things only exist because of marketers”. Then the author hits on a few things closer to home, which I think in certain cases are valid points:

there are a bunch of elements that have become something of a standard with modern website design that, while not offensively intrusive, are often unnecessary. I appreciate great typography, but web fonts still load pretty slowly and cause the text to reflow midway through reading the first paragraph

The article is a good look at what the web is becoming and how some of the things we think are so great, if we step back for one second, we might realize aren’t so great after all.

Article: “Securing Web Sites Made Them Less Accessible” by Eric Meyer

A reminder about how different internet access is around the world.

Eric was in rural Uganda teaching web development and trying to access the internet where his only option for connectivity was satellite internet:

For geosynchronous-satellite internet access, the speed of light become a factor in ping times: just having the signals propagate through a mixture of vacuum and atmosphere chews up approximately half a second of travel time over roughly 89,000 miles (~152,000km)... That’s just the time for the signals to make two round trips to geosynchronous orbit and back. In reality, there are the times to route the packets on either end, and the re-transmission time at the satellite itself. But that’s not the real connection killer in most cases: packet loss is. After all, these packets are going to orbit and back. Lots of things along those long and lonely signal paths can cause the packets to get dropped. 50% packet loss is not uncommon; 80% is not unexpected. So, you’re losing half your packets (or more), and the packets that aren’t lost have latency times around two-thirds of a second (or more). Each.

The web and its foundational architecture of TCP/IP is actually pretty amazing when you stop and think about it in light of Eric’s story. But anyway, his point was that to combat the problems of satellite-only connectivity, people create caching servers but those become problematic when everything is HTTPS because HTTPS is meant to stop man-in-the-middle attacks and a caching server is essentially a man-in-the-middle. Eric’s point is that “Securing the web literally made it less accessible to many, many people around the world.”

I don’t really have a solution here. I think HTTPS is probably a net positive overall, and I don’t know what we could have done better. All I know is that I saw, first-hand, the negative externality that was pushed onto people far, far away from our data centers and our thoughts.

Article: “Exploring the potential of friction-free deployments”

I actually really love Netlify’s ethos about how deploys should be so mundane, routine, and predictable that you could deploy every minute if you wanted. So this project was a cool outworking of that vision:

I decided to look at what could happen when continuous deployment is so mundane, so solved, so predictable, that I could deploy with confidence every day. Every hour. Every minute.

Article: “Five Key Benefits of ‘Going Serverless’”

What I love about JAM STACK

Imagine wanting to setup a cron job to scrape stack overflow once a day for support questions about your open source project. It’s hard to justify paying 7 bucks a month for a server for something like this but in the serverless pay-per-execution landscape this would likely land under the free tier or a couple of cents a month.

I’ve been trying this on a few projects with Netlify and it works like a charm. Loving it.

Article: Bits by Ethan Marcotte

I totally agree with Ethan’s assessment here. People are always saying “the web is slow, here’s how to make it fast” and they solve the problem from a technology perspective. But the mainstream web isn’t primarily slow because of an ignorance in how to make it fast. It’s slow because at the core of the web’s essence (and this is something that I think just happened organically over time) people expect everything on it to be free. So money has to be made somewhere, and it gets made by the boatloads of tracking/analytics JavaScript and other bloated bandwidth that ends up on websites.

ultimately, the web’s performance problem is a problem of profitability. If we’re going to talk about bloated pages, we should do so in context: in the context of a web where digital advertising revenue is cratering for publishers, but is positively flourishing for Facebook and Google. We should look at the underlying structural issues that incentivize a company to include heavy advertising scripts and pesky overlays, or examine the market challenges that force a publisher to adopt something like AMP.

Let’s stop kidding ourselves. This is the core issue.


Reading Notes, July 2018

Article: “Removing Babel's Stage Presets” via babeljs.io

Stage presets are being removed in Babel v7 and Henry Zhu makes the case as to why.

Personally, I’m all for it. Stage presets always confused me. Making developers opt-in explicitly to varying levels of language experimentation will be beneficial to everyone because it will force us as a community talk more specifically about the (often quite disparate) evolutionary changes in the language.

Removing the presets would be considered a "feature" since it means someone would have to make an explicit decision to use each proposal, which is reasonable for any proposal since they all have varying levels of instability, usefulness, and complexity.

I like this. You can still get proposals grouped together if you want, but not from the “official” project. It makes developers put too much trust in grouped presets. Leave that up to third parties, which should encourage developers to better vet their sources for grouped proposals. I think this is the right choice because Babel should be low level. Other higher level frameworks or tools can make (and obfuscate) the choices of grouped proposals for people (like create-react-app).

people will have to opt-in and know what kinds of proposals are being used instead of assuming what people should use, especially given the unstable nature of some of these proposals. If you use another preset or a toolchain, (e.g. create-react-app) it's possible this change doesn't affect you directly.

Remember too that it’s not only Babel that has to update with stage presets, but everything down river from that. That’s too much churn to support for something like Babel IMO. Unsustainable. So this again was a good choice

Once new syntax is proposed, many things need updating: parsers (babylon), syntax highlighting (language-babel), linters (babel-eslint), test frameworks (jest/ava), formatters (prettier), code coverage (istanbul), minifiers (babel-minify), and more.

The maintainers seems to recognize that’s too much for Babel to be biting off. They’d be better off if their skin wasn’t in that game.

In many ways, it's surprising we even attempt to handle [stages] in Babel itself given the constant updates and churn.

Podcast: “Async React with Andrew Clark” via The React Podcast

The podcast itself had some interesting tidbits in it, but what I really liked was this little snippet from Andrew:

Code is temporary. Ideas persist.

Side note: this is a good question to ask yourself when coming into or architecting a project — what are the ideas underlying this code? Code can be refactored, but only within the framework of the ideas which support it (otherwise you’re looking at a significant rewrite).

Article: “React - Basic Theoretical Concepts” by Sebastian Markbåge

I never known about this repo until hearing about it on “The React Podcast”. It’s an interesting conceptual approach to the underpinnings of react. In other words, its an expression of the ideas in React irregardless of the code that implements it.

The actual implementation of React.js is full of pragmatic solutions, incremental steps, algorithmic optimizations, legacy code, debug tooling and things you need to make it actually useful. Those things are more fleeting, can change over time if it is valuable enough and have high enough priority. The actual implementation is much more difficult to reason about.

Tweet: Icons aren’t logos by @Mantia

Iconic iconist Louie Mantia on twitter:

Icons: they’re not logos.

Use elements of your brand like color, shape, weight, and style, but resist the urge to just use your logo.

Tweet photo

This first photo was illustrative of his point, but he followed up with another tweet illustrating how different brands could use the same metaphor of a TV in designing their icon without losing brand “equity”.

tweet photo

I, for one, like it. I’d love to see more icon design like this in the wild.

Tweet: Thread between @thekitze and @danabramov

I’ve always enjoyed following Dan, he brings a dose of reality and empathy to a tech world often awash with exaggerated claims.

@thekitze

If we would start webdev from scratch and had to choose between:

No sane person would choose the first options

@dan_abramov

There are three things wrong with this tweet:

@thekitze

Dan, this has nothing to do with React or frameworks.

What I'm trying to say is: just imagine if these weren't technical choices and we had to invent ways of styling, passing data & writing components.

I don't know if people are trying too hard to misunderstand the tweet.

@dan_abramov

It has to do with React because you are prominent in the React community. Whether you want it or not, people from other communities reading this will think “React developers agree with this person that I’m insane for liking e.g. CSS”.

@thekitze

Sane might have been a wrong word. Maybe "experienced".

Still, people are misunderstanding the "invent" part of the tweet. If we had to invent styling most experienced developers would choose tight coupling of styles to elements (otherwise Sass/Less/BEM/Modules wouldn't exist)

And then this — IMO an incredibly insightful, reasoned response in a technological discussion.

@dan_abramov

Again, you’re implying that the other side of the tradeoff only appeals to inexperienced people. This is super patronizing. Have you considered that maybe you lack the experience to appreciate simpler options that match the problem domain more closely?

I love that phrase: “Have you considered that maybe you lack the experience to appreciate simpler options that match the problem domain more closely?”

I love when someone conjoins just the right words in just the right order. Thanks Dan.

Article: “The Cult of the Complex” by Jeffery Zeldman

toolchains have replaced know-how...we must rid ourselves of the cult of the complex. Admitting the problem is the first step in solving it.

That’s how Zeldman has begun his latest tirade. Granted, the delivery is classic Zeldman, but if you wade through some of the ranting and listen for his points, I think he makes some valid ones.

Alas, many new designers and developers (and even many experienced ones) feel like they can’t launch a new project without dragging in packages from NPM...with no sure idea what the code therein is doing...For them, it’s a matter of job security and viability. There’s almost a fear that if you haven’t mastered a dozen new frameworks and tools each year (and by mastered, I mean used), you’re slipping behind into irrelevancy. HR folks who write job descriptions listing the ten thousand tool sets you’re supposed to know backwards and forwards to qualify for a junior front-end position don’t help the situation.

Article: “The Majestic Monolith” via 37Signals Blog

37Signals, makers of Basecamp and ever the buckers-of-trends, wrote this piece about why a monolith architecture (vs. the trendy micro service) is the right technological solution for them. At a more general level, they make this important observation:

The patterns that make sense for organizations orders of magnitude larger than yours, are often the exact opposite ones that’ll make sense for you. It’s the essence of cargo culting. If I dance like these behemoths, surely I too will grow into one. I’m sorry, but that’s just not how the tango goes.

This is true of not just technical patterns, but general organizational approaches too. But that you shouldn’t run HR like a 50,000-person company when you have 50 seems obvious to most though (with some exceptions)

Article: “Designed in China, Assembled in California” via iA

A fourth of July soliloquy:

As China starts outdoing us economically, technically and strategically, we are turning Chinese, slowly losing the spiritual, cultural and political texture that made us different....Silicon Valley spies on us like the Chinese Government—and in many ways they see China as their role model. They admire entrepreneurs that don’t sleep, don’t see their children, don’t care about such touch-me-feel-me nonsense like the truth, justice, beauty or how others feel.

So what makes the West unique? The author suggests the following 16 items:

  1. That all men are by nature equally free and independent
  2. That all power is vested in the people
  3. That government is instituted for the common benefit
  4. That no man is entitled to exclusive privileges
  5. That legislative executive should be separate and distinct from the judicative;
  6. That elections ought to be free
  7. That all power without consent of the representatives of the people is injurious
  8. That in prosecutions a man hath a right to demand the cause and nature of his accusation
  9. That excessive bail ought not to be required, nor excessive fines imposed nor cruel and unusual punishments inflicted
  10. That general warrants are grievous and oppressive
  11. That the ancient trial by jury is preferable to any other
  12. That the freedom of the press is one of the greatest bulwarks of liberty
  13. That a well regulated militia is the proper defense of a free state; that standing armies, in time of peace, should be avoided as dangerous to liberty
  14. That the people have a right to uniform government
  15. That no free government can be preserved to any people but by a firm adherence to justice, moderation, temperance, frugality, and virtue
  16. That religion can be directed by reason and conviction, not by force or violence

And what's so special about these? They are ideas whose impact cannot be directly measured, which is why perhaps in our day they go undervalued:

The West has 16 things to lose [which cannot] be touched, bought or expressed in numbers. It’s not the GDP, it’s not the number of STEM graduates, it’s not the top positions in the charts of the biggest banks. What we can hope is that the bureaucrats and technocrats continue to undervalue how powerful the unmeasurable is. These 16 ideas have survived Napoleon, ended First World War and won against the Nazis. They have survived the Khmer and they have survived Stalinism. Happy fourth of July.


Reading Notes, June 2018

Article: “My Three Steps” by Ethan Marcotte

His wording was specific to CSS grid (which I’m also in the process of learning) but was a good articulation of how I also learn new technology:

  1. “I’m going to learn how to use NEW TECHNOLOGY X to produce something I’m already familiar with.”
  2. “Huh, I can produce this thing I’m familiar with using NEW TECHNOLOGY X way more efficiently than I ever could before.”
  3. “—okay, now I’ll try making something with NEW TECHNOLOGY X I’ve never even considered.”

Article: “What’s in a pattern name?” by Ethan Marcotte

Ethan commenting on the design exercise he often does at conferences and workshops of printing webpages then cutting up the UI into pieces in order to find patterns. An exercise in designing language before any exercise in designing UIs can be critical to success. Words have meaning.

the primary benefit to creating a pattern library isn’t the patterns themselves...But rather...the language used to name, organize, and find patterns is what allows [us] to use those patterns effectively—and that is what creates more consistent designs...the words we use to talk about our design are, well, valuable design tools themselves.

Article: “Chatbots are saints” by Nicholas Carr

Thoughts spurred by Google’s Duplex:

Although chatbots have been presented as a means of humanizing machine language — of adapting computers to the human world — the real goal all along has been to mechanize human language in order to bring the human more fully into the machine world. Only then can Silicon Valley fulfill its mission of capturing the entirety of human experience as machine-readable, monetizable data.

Article: “A Few Bullet Points on Design Criticism” by Frank Chimero

As always, great thoughts from Frank. Everything in this article is great. I could’ve copy/pasted the entire article, but instead I tried to practice some constraint and only copy/paste the stuff that really stuck out to me (honestly though, it’s all good, go read it). Emphases are mine.

On feedback being an art:

clients, co-workers, and bosses aren’t practiced in analyzing design, and designers, while well-versed in giving feedback, are often less experienced in how to productively receive it. Feedback should be a liberal art for everyone.

On gut reactions:

One particularly tricky aspect of criticizing design is that a lot of the work is meant to be quickly read (like logos) or intuitively understood (like interfaces and websites). Does this validate gut reactions or hot takes? I’m uncertain, but it can shift power towards the people who are the least invested in the process.

On design ridicule:

Any defining characteristic of the work will probably be the subject of ridicule.

On the need for specificity:

Praise is meaningless without specificity...A robust feedback process must be specific in its praise, because succeeding is enhancing good choices as well as fixing mistakes.

And a great quote from Michel Foucault on “scintillating” design criticism:

Criticism that hands down sentences sends me to sleep; I’d like a criticism of scintillating leaps of imagination. […] It would bear the lightning of possible storms.

Article: “Apple, Influence, and Ive” via Hodinkee

A few excerpts I found interesting from this extended interview with Jony Ive from Hodinkee (which touts itself as a “preeminent resource for modern and vintage wristwatch enthusiasts”).

First: Ive points outs the interesting parallels between the evolution of personal computing and personal time telling (which I had never noticed before):

I think there is a strong analog to timekeeping technology here for our own products and computational devices. Think about clock towers, and how monumental but singular they are. They are mainframes. From there, clocks moved into homebound objects, but you wouldn’t have one in every room; you might have one for the whole house, just like PCs in the 1980s. Then maybe more than one. Then, time-telling migrated to the pocket. Ultimately, a clock ended up on the wrist, so there is such a curious connection with what we wanted to do, and that was a connection we were really very aware of.

Ive made this observation on Apple’s mindset when approaching a product: it’s not just the destination, it’s all you learn along the journey (emphasis mine):

It was fairly clear early on that we wanted to design a range of products, without getting too convoluted, that would broaden how relevant we were. And working in gold and ceramic was purposeful – not only to expand who Apple is, but also from a materials science perspective. As you know, at the end of any project, you have the physical thing (the watch in this case), and then you have all that you have learned. We are always very mindful that the product not be all that we have in the end, and the Edition yielded much to us. We have now worked with ceramic and with gold, and our material sciences team now understands these fundamental attributes and properties in a way they didn’t before. This will help shape future products and our understanding of what forms make sense.

Ive’s respect for companies (and I think by extension, people) who are willing to buck outside pressures in order to be true to their inner compass, which leads to producing something fully unique to their specific characteristics and traits (which no one else in the world can authentically reproduce):

I have so much respect for many of those other brands – Rolex, Omega – because there is the remarkable longevity combined with such an obvious and clear understanding of their own unique identity. It’s rare but inspiring when you see the humble self-assurance of a company that ignores short-term market pressures to pursue their own path, their own vision. Their products seem to testify to their expertise, confidence, and quiet resolve. Their quality and consistency is rightly legendary.


Reading Notes, May 2018

Article: “A modest guide to productivity” by Frank Chimero

I just really liked this comment in particular and wanted to make note of it:

A person is not a brain driving a meat robot; it all runs together. If work is stymied, ask: are you eating clean? Getting enough sleep? Did your heart pump more than a sloth today? Start with your body, not your work methods. Trust me.

Article: “Bitcoin Is Ridiculous. Blockchain Is Dangerous” by Paul Ford via Bloomberg

An entertaining opinion on the state of Bitcoin and its parallels to the early days of the web.

This particular quote I enjoyed as it points out what I like to think of as the Jurassic Park / Ian Malcom problem: we go so fast questioning “can we do this?” that we often don’t stop to think “should we do this?” until way after we’ve already encountered the ramifications:

the frameworks are coming to build such tools and make them anonymous and decentralized, so that they might endure, and, as with all internet things, they’ll arrive well ahead of the ethics we need to make sense of them.

Article: “I, for one.” by Ethan Marcotte

Going along with another great post from Jeremy Keith, Ethan comments on the on-going controversy around Google’s continuing attempts to promote proprietary technologies (over open ones) with the AMP project. He draws an interesting parallel with the political climate today in America:

[the] trend of corporations-as-activists is the result of an ongoing politicization of the public sphere, which is itself the result of a government that’s unable (or unwilling) to serve its citizens

Then concludes:

the creation of AMP isn’t just Google’s failure, but our failure...of governance of our little industry. Absent a shared, collective vision for what we want the web to be—and with decent regulatory mechanisms to defend that vision—it’s unsurprising that corporate actors would step into that vacuum, and address the issues they find.

And once they do, the solutions they design will inevitably benefit the corporation first, and the rest of us second. If at all.

Article: “Domo Arigato, Mr. Roboto, Tell us Your Secret” via Information Architects

I thought the author’s comment here on Twitter’s response to banning spam bots (whereas Facebook turned to tuning their algorithms so as to not “censor”) was interesting, i.e. “you have the power to shape your own destiny”:

Here is a heavy dose of practical philosophy for you: You know who decides? Those who take responsibility. And those who decide and take responsibility shape their destiny. For those who wait and see other people will decide. This is a moment where Twitter can make precious ground over a seemingly invincible Facebook.

The article is an interesting look at UI design in an automated age. It argues we should clearly differentiate humans and bots in user interfaces, a line which, right now, is mentally taxing at the least and impossible at the most:

Programming an army of bots in a system without checks and balances is economically interesting. It happens because it is cheap.

The UI mockups are interesting. Personally, I would love something like this.

Podcast: “Spotlight: Frank Chimero” via Responsive Web Design

I really like Frank’s insights into the web as a medium. This podcast is no different. Around minute mark 18 though, it gets really interesting.

Ethan asks him the following question:

in some ways you’re sort of trying to frame what a web native aesthetic might be in general for web design...I’d love to hear a little bit more about that, Frank, and just generally how you think about what the web needs as a design medium

I’ve just pulled the entire transcript at that point, because I think everything Frank says is worth pondering (emphasis mine):

One of the reasons that I think so much about what websites should look like, not just in specific terms like, “Oh, I have this client. What should their website look like?” but just in general, what should the experience of going from website to website feel like, it’s mostly grounded in the fact that I sort of see web designers repeating things that we’ve labeled as mistakes before. We did a lot of work...trying to iterate to people the importance of semantics and accessibility on websites, and the benefit to users of having consistent experiences across those website and having those experiences be driven by the interactivity of the browser, right? That’s why Flash websites weren’t so great, because every time you hit a Flash website, you didn’t know how to use it. I see us sort of repeating that at this point. There are sort of these marquee websites that are obviously for marketing but there’s a lot of whizzbangery around it because they’re meant to draw attention. But they have some of those fundamental usability problems that I think those early Flash websites had, and it’s really hard for me to look at them and not see them as cumbersome and bloated—and cool, but I find myself looking at them more than actually using them. Maybe that’s the intent, I’m not really sure.

So, that’s kind of one of the reasons why I was like is there an oughtness?...Is there a way towards making websites that feel like they’re websites? I have a pretty good feeling about what that is and it doesn’t necessarily overlap too much with the whizzbangery that gets a lot of attention. So, wanting to really drill down and say, well, okay, what’s the web’s grain? Well, the web kind of wants you to stack things vertically on top of each other and have quite a bit of text. It wants to be fluid, it wants to scroll vertically, and it wants to probably use flat colors or simple gradients because that’s what’s easy to specify inside of CSS, and also you can take those aesthetic rules and stretch them out to boxes of indeterminate shape or boxes that might change shape based on how somebody’s accessing the website or how much content is sitting inside of that box. So, it’s like what is the aesthetics of fluidity? That’s really what the main question is, and a lot of it is dictated by what the tools make easy for you to do.

So, I think that you can make a perfectly great and serviceable website probably with just, I don’t know, 100 to 150 lines of CSS. It doesn’t take really that much. It doesn’t take a lot of JavaScript or anything like that. The old websites from the 90’s, they still work, their fonts just need to be a little bit bigger and they need to set a max width on their paragraph so it has a nice measure. Other than that, you go back and look at a bunch of the essays by Tim Berners-Lee and you’re like, “Actually, this still holds up. I’m not a big fan that it’s in Times New Roman, but that’s what they had to work with.”

So, that’s what’s interesting to me. It’s taking sort of a principled stance as a starting point, honoring the materials that you’re working with and believing that the web has a grain like how a piece of wood has a grain. You can work against that grain, and that creates interesting work that requires a lot of craftsmanship, but for the most part, if you’re building something, you’re going to want to go with the grain because it’s going to be sturdier, it’s going to be easier for you to work with and typically, hopefully, in the process it will be a little bit more beautiful, too.

We had a conversation about web fonts mostly in that, from a kilobyte perspective, they’re pretty pricey, and there’s all of these logistics to worry about if you want a performant website, about how they load and if you want the flash of unstyled text or using JavaScript to put conditional classes on bodies to change the body font after the fonts load and those sorts of things. My question was just sort of like, well, that’s really easy for other people, but every additional step that they need to take is an extra point of fragility, right? So, I’m just sort of wondering is it worth the effort.

Right now, my website is using two typefaces, one is called Fakt and the other one is called Arnhem, and the fallback immediately after that is San Francisco and Georgia. If I take out the web fonts, I like it nearly as much as if I had the web fonts in there. The vibe of the site changes a little bit, but for the most part most of the typefaces are of the same size, so it isn’t like a world of difference changing the typeface to these fallbacks. So it’s like, well, do I actually need those typefaces in there, or would it just be easier and more stable to have those system fonts being used? I kind of waffle on it, I go back and forth probably every single day, and I decided to leave them in because I was like, well, I bought them, let’s use them. But it is sort of like this interesting question whether these additional assets, what the trade-off for each one of these is. Because every additional element you add to a web page, it costs something, you know? It benefits in some way, but it also costs something, and eventually you’ve got to justify the cost, because we can’t communicate the size of web pages before they’re loaded.

Article: “What Does Code Readability Mean”

My takeaway: can I be a little more humane in how I talk about code? Rather than “this code sucks”, how about “I can’t understand this code – yet.” The inference being: the problem of the code problem lies with me, the reader, not the original writer.

In a similar vein, at the end of the day humans (i.e. developers) are the real resource of your business not the code. This is because all code rots because business requirements change. When I rewrite code, it’s a sign of adding value to the business, not a sign of failure on part of the previous programmer(s).

What follows is mostly just a brain dump of contents from this article that stuck out to me.

By analogy, plenty of people find reading Homer, Shakespeare, or Nabokov difficult and challenging, but we don’t say “Macbeth is unreadable.” We understand that the problem lies with the reader. We may not have sufficient experience with the language and idioms. We may not have enough historical and cultural context (similar to lacking domain expertise when looking at software). We may not have the patience or desire to invest time learning how to read a challenging book. Wikipedia articles and Cliff’s Notes exist to give tl;dr versions of books to people who can’t or don’t want to read the original. When we observe this tendency in other (non-programming) contexts we may interpret it as laziness or short attention span. When we react this way to code we blame the code and the original programmer.

Programmers usually think that they should focus on writing code. Reading code, especially someone else’s code, seems like grunt work, a necessary evil, often relegated to junior programmers in maintenance roles.

I have personally witnessed (more than a few times) professional programmers dismiss working, production code as “unreadable” and “unmaintainable” after looking at it for just a few minutes.

“Good code is simple” doesn’t actually say anything. My many years of programming experience and business domain expertise gives me a very different idea of “simple” than someone with less experience and no domain expertise looking at some code for a few minutes. What we call “simple” depends on our experience, skills, interest, patience, and curiosity. Programmers should say something when they don’t understand code, but rather than saying “this code sucks” they should say “I can’t understand this code – yet.” That puts the focus on the person who struggles to understand rather than on the code. I agree that code reviews improve code quality and team cohesion, but whether that translates to “simple” code depends on the programmers. Programming teams usually converge on common idioms and style, and that make programming together easier, but that convergence doesn’t mean the code will look readable to an outsider looking at it six months later.

When I understand the code I may think that I know a simpler or more clear way to express it, or I may think that the code only presented a challenge to me because I didn’t have the skills or knowledge or right frame of mind. In my experience figuring code out takes significant time and effort, but when I get through that I don’t usually think the code has fatal readability flaws, or that the original programmer didn’t know what she was doing.

Public code reviews create a kind of programmer performance art, when programmers write code to impress other programmers, or to avoid withering criticism from self-appointed experts.

Better programming comes through practice, study (from books and other code), and mentoring. It doesn’t come from trying to blindly adhere to rules and dogma and cargo cults you don’t understand or can’t relate to actual code.

All code baffles and frustrates and offends a significant subset of programmers.

How do you learn to write readable code? Like learning to write readable English, you have to read a lot.

I don’t generally read hackernews (nor its comments), but for some reason while traveling down the black hole of internet browsing, I ended up in the hackernews comments for this article. I thought these were interesting observations.

One comment

I like Rich Hickey's stance on this: "simple" is objective (antonym: "complex"), whereas "easy" is subjective (antonym: "hard"). Easy depends on skills, interest, patience, curiosity - but simple does not. Simple is about lack of intertwining of concerns. About writing code that can be understood without "bringing in" the entire codebase into your mind. Like, you can understand a pure function just by looking at it (it's simple). If it modifies or uses a global variable, now you have to look at all the places that "touch" that global variable, in order to understand what your function does; the code is thus much more complex.

Another (emphasis mine)

Reading code is about 10x as hard as writing it. It takes more concentration, it's less fun, it's harder, and it doesn't impress anyone. You have to know the language better than the person who wrote it, because not only do you have to understand why the code does what they intended it to, but you also have to understand why the code does other things they didn't intend (a.k.a. bugs). But in my experience, you save your team a lot more time and energy in the long run by preferring to read and understand existing code.

Another (emphasis mine)

There is a lot the context you’ve built up in writing that code that could never fit in the comments (even if thoughts could easily be expressed in words, they would dwarf the code and not directly correspond to it; actually comments can actually make code reading harder in this way). It really isn’t about the language either...but how the problem was defined and understood in the first place, how this understanding was encoded in the software.

Another

I sometimes describe programming as a one-way hash operation on requirements. A lot of information and context gets lost when writing software, and I haven't seen a workable solution to that problem yet.


Reading Notes, March 2018

Article: “The Loveliest Living Fossil” via typography.com

A really interesting article that looks at the fluctuating meanings behind punctuations in typography:

At its leading edge, punctuation is volcanically active, giving shape to concepts that move far faster than words. Anyone communicating today has seen #topics and #themes and #categories identified this way, using a symbol that was intuitively understood and replicated even before it was first called a hashtag in 2007. The symbol and its meaning are now universally recognized, transcending even the locality of language, but their use is scarcely a decade old — an astounding accomplishment for a bit of lexical fluff

But the “#” symbol has a myriad of different meanings:

Nº was the number sign before # became a number sign, and it refreshingly serves this one and only purpose. Compare the #, which when preceding a number is read as “number” (“#1 in my class”), but when following a number means “pound” or “pounds” If you’re curious what the # symbol has to do with the abbreviation lbs., here’s one possible missing link. (“70# uncoated paper”), leading to printshop pile-ups like “#10 envelope, 24# bond.” To programmers, a # can mean either “ignore what follows” (as in a Python comment) or “use what follows” (when referencing a page fragment, or a Unicode value in html.) To a proofreader, a # means “insert space,” so in the middle of a numbered list, the notation “line #” does not mean “line number,” but rather “add a line space.” Because of #’s resemblance to the musical symbol for “sharp” (♯), it’s a frequent stand-in for the word “sharp,” and often the correct way of rendering a trademarked term such as The C# Programming Language. The # is rapidly assuming musical duties as well, especially in online databases, leading to catalog collisions like “Prelude & Fugue #13 in F#.” How fortunate a designer would be to have a numero symbol, with which to write “Prelude & Fugue Nº 13 in F#,” or “Nº 10 Envelope, 24# bond.”

Conclusion:

the Nº is a reminder that typography exists to serve readers, and that readers do not live by semantic punctuation alone. There’s a place for variety and richness in typography

A great article, worth reading in its entirety.

Video: “The Functional Tao of Bash” by Garrett Smith

The principles of this talk are illustrated by code examples of BASH, but I think they are general enough to apply to any programming language. The speaker walks you through his own personal thought process and techniques for understanding and refactoring a piece of code which he did not write himself.

I️ found many useful ideas from his own personal techniques that I’d like to try. His overall goal is to make the code easy to understand and comprehend at a glance. He does this by breaking things up into really small function chunks, so you end up with something like:

// Top of file
DoThing();
DoAnotherThing();
DoLastThing();

// Underneath main execution are the declarations
function DoThing() {...}
function DoAnotherThing() {...}
function DoLastThing() {...}

I also enjoyed this quote around the ~11:30 mark:

Programming is not a moral debate. We’re not talking about evil and good. We’re talking about a process of programming. “Writing terrible code” is probably a misnomer. That so called “terrible code” is code that is experimental and trying to prove something. That’s fine. Prove it. Understand it. Get it to work. Learn from it. Then make it clearer. Make it better. As needed.

Article: “Your brain does not process information and it is not a computer” by Robert Epstein

I liked this article and agree personally that the metaphor of the human brain as a computer or information processing machine feels intuitively off-base to what I experience (both as a human and, albeit, amateur computer enthusiast and writer-of-code).

I found rather interesting the author’s examples of how human metaphors for the brain's inner workings have changed drastically over time (none yet seem to have adequately explained the phenomenon):

The invention of hydraulic engineering in the 3rd century BCE led to the popularity of a hydraulic model of human intelligence, the idea that the flow of different fluids in the body – the ‘humours’ – accounted for both our physical and mental functioning. The hydraulic metaphor persisted for more than 1,600 years, handicapping medical practice all the while.

The author concludes that, at some future day, the metaphor of the human brain as a computer will seem as ridiculous as this notion of the brain as a hydraulic machine does now. One example of how a computer is a poor metaphor for the mind is found in the idea of “storing memory”:

Misleading headlines notwithstanding, no one really has the slightest idea how the brain changes after we have learned to sing a song or recite a poem. But neither the song nor the poem has been ‘stored’ in it. The brain has simply changed in an orderly way that now allows us to sing the song or recite the poem under certain conditions. When called on to perform, neither the song nor the poem is in any sense ‘retrieved’ from anywhere in the brain, any more than my finger movements are ‘retrieved’ when I tap my finger on my desk. We simply sing or recite – no retrieval necessary.

He continues:

Because neither ‘memory banks’ nor ‘representations’ of stimuli exist in the brain, and because all that is required for us to function in the world is for the brain to change in an orderly way as a result of our experiences, there is no reason to believe that any two of us are changed the same way by the same experience. If you and I attend the same concert, the changes that occur in my brain when I listen to Beethoven’s 5th will almost certainly be completely different from the changes that occur in your brain. Those changes, whatever they are, are built on the unique neural structure that already exists, each structure having developed over a lifetime of unique experiences.

If you start paying attention, you’ll notice how pervasive the metaphor of “human brain as a computer” is. In fact, I admit (somewhat ashamedly) that when my first son was born I was kind of in shock that during his nine months of development in the womb, there wasn’t some kind of bug that worked its way into his biological system (a weird nose, an immune deficiency, etc). Thousands of babies must be born everyday, most of them likely in “normal working order”. How is that possible? I can’t even ship a single piece of code without some underlying a bug. I suppose I’ve been spending too much time writing software.

Article: “In Search of the Perfect Writing Font” via ia.net

A well-articulated set of arguments for why the folks at IA ship their plain text editor with only a monospaced font:

In contrast to proportional fonts that communicate “this is almost done” monospace fonts suggest “this text is work in progress.” It is the more honest typographic choice for a text that is not ready to publish...The typographic rawness of a monospace font tells the writer: “This is not about how it looks, but what it says. Say what you mean and worry about the style later.” Proportional fonts suggest “This is as good as done and stand in an intimidating contrast to a raw draft.”

I wonder if that’s why there’s so many bugs in software: we’re subconsciously believing it’s always a work in progress? Well, the folks at IA address the programmers and monospaced fonts later:

Programmers use monospaced fonts for their indentation and because it allows them to spot typos. In a perfectly regular horizontal and vertical raster, letters and words become easily discernible

But is there a balance between a proportional font and a monospaced one?

This year, again, we set out exploring our own writing font. We started from scratch, moved from proportional to monospace to three spaces and ended up with duospace...Progressively, we came to realize that the right question is how to make a proportional font look like a monospace, but how many exceptions you allow until you lose the benefits of a sturdy monospace.

And here’s the why behind exploring duospace:

The advantage over proportional fonts is that you keep all benefits of the monospace: the draft like look, the discernability of words and letters, and the right pace for writing. Meanwhile, you eliminate the downside stemming from mechanical restrictions that do not apply to screen fonts.

Article: “Dying a Little in Computer Poetry” via ia.net

Honesty, I’d like to see more blog posts like this. These kinds of observations (and their implications) get brushed over too frequently. In my opinion, the author is trivially breezing over a topic that could results in the ultimate regret at the end of his life:

As a so-called HCI (Human Computer Interaction) designer, I know that using a computer I am, in fact, communicating with a computer. I communicate with computers all day long. I know that, most of the time, I talk to something that has no body, no feelings, and no understanding...I mostly use the computer as a tool to talk to other humans. I structure interfaces and write text that I share with other humans. I communicate more with computers than with my kids. I caress my iPhone more often than my kids. This is a bit sad. Maybe it’s very sad. But, hey, most people spend more time at work than with the family! Spending time with my computers, I support my family. And, hey, eventually, my words and designs will reach other human beings. I know that what I do on my computers will be felt by humans in some way. I fear that on my death bed I might regret these words as much as what they try to deny. But, hey… There is a difference between communicating through computers and communicating with computers.

He also touches on that nagging concern many of us in tech have that what you do becomes worthless in a matter of years months:

Spending time with computers we still risk that all the energy we invested in communicating with them disappears into that little black electric holes that used to eat our Word documents. When we talk to computers, we risk dying a little, as we lose time to the possibility that all our energy turns to zeroes.

Conclusion:

Just pay attention to not pour half your life into the digital void.

Article: “Take the Power Back” via ia.net

Great analogy:

One of the first lessons you learn as a young traveler is when you go to a faraway country: avoid the people that call you on the street. “Massage?” “Hungry?” “Need a guide?” Only noobs follow the hustlers. You find a quiet spot and research where to go. Then you go there and then go further. Same thing when you travel on the Web. Don’t get lured in. Find a quiet spot and research and then go there. And then go further...Things pushed in our stream through an algorithm tailored to our weakness are the digital equivalent of the calls that try to lure you in when you walking down a street in Bangkok.

Also, I thought this was a rather interesting (and funny) observation on how younguns view URLs. Apparently, this was a conversation that happened:

11-year-old: “What is this strange stuff on the Milk package?”
Dad: “This strange stuff is a URL.”
11-year-old “What does it say?”
Dad: “It’s an Internet address.”
11-year-old “Address of what?”
Dad: “Of a Website. It’s used in the browser—you put it in that field on top and then you go to a Website.”
11-year-old “What is the browser?“

The author’s observation on this conversation is that:

The browser now is just another app...Apps bring him there sometimes. To a chatting teen, the address bar is a cousin of the terminal.


Reading Notes, January 2018

Song: "No Phone" by Cake

Just happened to be listening to some Cake the other day and the song “No Phone” came on. To be honest, I kind of sat marveling that this song was written in 2003, way before smartphones came along. Seems incredibly prescient. Here’s some lyrical excerpts:

No phone No phone I just want to be alone today
...
Ringing stinging
Jerking like a nervous bird
Rattling up against his cage
Calls to me throughout the day
...
No phone No phone I just want to be alone today
...
Rhyming chiming got me working all the time
Gives me such a worried mind
...
No phone No phone I just want to be alone today
...
Shaking quaking
Waking me when I'm asleep
Never lets me go too deep
Summons me with just one beep
The price we pay is steep
...
My smooth contemplations will always be broken
My deepest concerns will stay buried and unspoken
...
No phone No phone I just want to be alone today

Article: “Computer latency: 1977-2017” via danluu.com

This article is an exhaustive look at computer latency over the last few decades. The conclusion? Modern computers are significantly slower in keyboard-to-screen response time.

the default configuration of the powerspec g405, which had the fastest single-threaded performance you could get until October 2017, had more latency from keyboard-to-screen than sending a packet around the world.

Though the article deals specifically with detailing the degradations in latency of a keypress on computer hardware over the past few decades, I found this observation to be eerily similar to what’s happening with the degradations in speed of the web over the past few decades:

The solution to poor performance caused by “excess” complexity is often to add more complexity. In particular the gains we’ve seen that get us back to the quickness of the quickest machines from thirty to forty years ago have come not from listening to exhortations to reduce complexity, but from piling on more complexity.

Article: “Hooked and booked” by Jeremy Keith

Data only answers what, not why:

At Booking.com, they do a lot of A/B testing.
At Booking.com, they’ve got a lot of dark patterns.
I think there might be a connection.
A/B testing is a great way of finding out what happens when you introduce a change. But it can’t tell you why.

More:

The problem is that, in a data-driven environment, decisions ultimately come down to whether something works or not. But just because something works, doesn’t mean it’s a good thing.

If I were trying to convince you to buy a product, or use a service, one way I could accomplish that would be to literally put a gun to your head. It would work. Except it’s not exactly a good solution, is it? But if we were to judge by the numbers (100% of people threatened with a gun did what we wanted), it would appear to be the right solution.

Love the picture he paints with the “gun-to-head” example. Though often mistakenly interpreted otherwise, data is only one piece of a multi-faceted story.

Article: “Origin Story” by Jeremy Keith

Jeremy responding to the commonly-held assertion that the web is a primitive technology because it was just designed for sharing documents.

If the web had truly been designed only for documents, [rich interactive applications] wouldn’t be possible.

Article: “Airplanes and Ashtrays” via csswizardry

The author asks: inflight smoking has been banned in commercial airlines for the last twenty decades but airplanes are still fitted with ashtrays, why? Because rules aren’t going to stop 100% of people. The author summarizes this sentiment from the airlines manufacturers: “We absolutely do not want people to smoke on board, but if they do, then we need to handle the fallout from it in the safest way possible.” It’s about pragmatism.

How does this relate to writing code?

ten years of being a developer has taught me that, sometimes, doing the wrong thing is the right thing to do

Also:

When a team cannot bend the rules of your system or framework, they’ll often opt to simply not use it at all. This is a net loss, where allowing them to do the wrong thing would have at least led to greater adoption, more consistency, and less repetition.

The conclusion being:

Whenever you plan or design a system, you need to build in your own ashtrays; a codified way of dealing with the inevitability of somebody doing the wrong thing.

Article: “The Fallacies of Distributed Computing” via csswizardry

I liked this reminder that things don’t always work as expected:

If you build and structure applications such that they survive adverse conditions, then they will thrive in favourable ones. Something I often tell clients and workshop attendees is that if you optimise for the lowest rung, everything else on top of that comes for free.

Video: “PureScript: Tomorrow’s JavaScript Today” by Kris Jenkins

An interesting look at the value proposition of PureScript.

What I found really interesting here were the function signatures because they afford you so much by merely glancing at them, especially when your code has side effects. Here’s the example the presenter uses:

-- Pure
summariseDocument :: String -> String
-- Needs network
fetchDocument :: DocumentId -> Eff (ajax :: AJAX) String
-- Needs a browser
renderDocument :: String -> Eff (dom :: DOM) ()

This lets you keep track of what pieces of your code can run by themselves and which require other systems (servers, databases, etc) in order to run.

[PureScript] takes you to the future of large scale front-end code reliability. [Now I’ve written systems in PureScript] and every one of those systems in recent years has needed a little bit of JavaScript. Maybe five to ten percent of the codebase is JavaScript. All of my bugs, all of my runtime exceptions, all of my problems, come from that five to ten percent. The rest [of the codebase] is rock solid. I worry about logical errors but I don’t worry about the reliability of my code anymore on the front-end.

Quote: David Foster Wallace on Reading

I really enjoyed this quote. It speaks directly to improving your language skills, but I think can more broadly be applied to just about any skill at which you wish to improve. The quote comes from this book (emphasis mine):

Not just reading a lot, but paying attention to the way the sentences are put together, the clauses are joined, the way the sentences go to make up a paragraph. Exercises as boneheaded as you take a book you really like, you read a page of it three, four times, put it down, and then try to imitate it word for word so that you can feel your own muscles trying to achieve some of the effects that the page of text you like did. If you're like me, it will be in your failure to be able to duplicate it that you'll actually learn what's going on. It sounds really, really stupid, but in fact, you can read a page of text, right? And “Oh that was pretty good…” but you don't get any sense of the infinity of choices that were made in that text until you start trying to reproduce them.

Article: “How smartphones hi jack our minds” by Nicholas Carr

Nicholas Carr at it again.

The smartphone has become a repository of the self, recording and dispensing the words, sounds and images that define what we think, what we experience and who we are.

He speaks about an interesting test that was done on cognition and how the results showed that if your phone was even near you, you scored less (emphasis mine):

The results were striking. In both tests, the subjects whose phones were in view posted the worst scores, while those who left their phones in a different room did the best. The students who kept their phones in their pockets or bags came out in the middle. As the phone’s proximity increased, brainpower decreased.

The most interesting part is that they didn’t even know it:

In subsequent interviews, nearly all the participants said that their phones hadn’t been a distraction—that they hadn’t even thought about the devices during the experiment. They remained oblivious even as the phones disrupted their focus and thinking

I think we can all admit it’s tough:

Just suppressing the desire to check our phone, which we do routinely and subconsciously throughout the day, can debilitate our thinking.

Perhaps we’re not as in control as we think:

The evidence that our phones can get inside our heads so forcefully is unsettling. It suggests that our thoughts and feelings, far from being sequestered in our skulls, can be skewed by external forces we’re not even aware of.

But is it really that big of a surprise our phones have such a hold on us?

Imagine combining a mailbox, a newspaper, a TV, a radio, a photo album, a public library and a boisterous party attended by everyone you know, and then compressing them all into a single, small, radiant object. That is what a smartphone represents to us. No wonder we can’t take our minds off it.

Another problem is that we offload remembering information to the computer because we have search engines available to us 24/7. But that is diminishing our own personal knowledge. Plus, as was found in a study “when people call up information through their devices, they often end up suffering from delusions of intelligence. They feel as though ‘their own mental capacities’ had generated the information, not their devices.” So what do we do?

Only by encoding information in our biological memory can we weave the rich intellectual associations that form the essence of personal knowledge and give rise to critical and conceptual thinking. No matter how much information swirls around us, the less well-stocked our memory, the less we have to think with.

The conclusion? (emphasis mine):

That insight sheds light on society’s current gullibility crisis, in which people are all too quick to credit lies and half-truths spread through social media. If your phone has sapped your powers of discernment, you’ll believe anything it tells you.

At the end of the day, all our phones can give us is data, but we often misperceive that as knowledge:

Data, the novelist and critic Cynthia Ozick once wrote, is “memory without history.” Her observation points to the problem with allowing smartphones to commandeer our brains. When we constrict our capacity for reasoning and recall or transfer those skills to a gadget, we sacrifice our ability to turn information into knowledge. We get the data but lose the meaning. Upgrading our gadgets won’t solve the problem. We need to give our minds more room to think. And that means putting some distance between ourselves and our phones.


Reading Notes, October 2017

Video: Effective Programs - 10 Years of Clojure Keynote by Rich Hickey

Generally enjoy these talks by Rich Hickey, even though a lot of the time he’s talking about programming concepts beyond my understanding. What I do enjoy is his ability to describe problems in mainstream programming and ask “Wait, why are we doing this? We’re making things so hard for ourselves!”

Here’s just one quote I enjoyed from his talk:

When you look at programming languages, you really should look at: what are they for? There’s no inherent goodness to programming languages. Only suitability constraints.

Article: I’ve seen the future, it’s full of HTML.

My feelings precisely:

Web development used to be a lot simpler. If I wanted to test a library or hack together a quick demo, I could just <script src=”some-library”>.

I could reload the page instead of re-compiling a bundle. I could load a static page instead of running a development server.

Our default workflow has been complicated by the needs of large web applications. These applications are important but they aren’t representative of everything we do on the web, and as we complicate these workflows we also complicate educating and on-boarding new web developers.

Some of the web components in the examples are pretty cool. I hope this future really is as near as the author says.

Edit: I dove into web components a bit after seeing this article. They’re pretty cool and it feels good to be “using the platform” of the web. However, I still really love the declarative nature of React vs. the imperative nature of web components. Maybe I’ll write more about this in the future. (Who am I kidding? That post probably isn’t going to happen.)

Article: The coming software apocalypse via theatlantic.com

Good article making the rounds in technology circles about how unreliable code can be.

Human intuition is poor at estimating the true probability of supposedly ‘extremely rare’ combinations of events in systems operating at a scale of millions of requests per second. That human fallibility means that some of the more subtle, dangerous bugs turn out to be errors in design; the code faithfully implements the intended design, but the design fails to correctly handle a particular ‘rare’ scenario.

Stupid computers. Always doing precisely what you tell them to instead of catching the gist of your commands. Do what I mean, not what I say!

Article: Q/A with Dan Abramov via hashnode.com

Question for Dan: “What have you learned after working at Facebook for almost two years?”

He gave a response with a number of bullet points, but this one stood out to me:

Think about code in time. Don't stop at thinking about the code as it is now. Think about how it evolves. How a pattern you introduce to the codebase might get copy and pasted all over the place. How the code you're spending time prettying up will be deleted anyway. How the hack you added will slow down the team in the long run. How the hack you added will speed up the team in the short term. These are tradeoffs, not rules. We operate on tradeoffs all the time and we must always use our heads. Both clean and dirty code can help or prevent you from reaching your goals.

Article: Nicholas Carr’s These are not the robots we were promised via nytimes.com

One of my favorite critics of modern technology, Nicholas Carr, is at it again. This time questioning the culture behind AI-powered home robots like the Echo:

Whether real or fictional, robots hold a mirror up to society. If Rosie and her kin embodied a 20th-century yearning for domestic order and familial bliss, smart speakers symbolize our own, more self-absorbed time.

It seems apt that as we come to live more of our lives virtually, through social networks and other simulations, our robots should take the form of disembodied avatars dedicated to keeping us comfortable in our media cocoons. Even as they spy on us, the devices offer sanctuary from the unruliness of reality, with all its frictions and strains. They place us in a virtual world meticulously arranged to suit our bents and biases, a world that understands us and shapes itself to our desires. Amazon’s decision to draw on classical mythology in naming its smart speaker was a masterstroke. Every Narcissus deserves an Echo.

Tweet: @seldo

The older I get, the more every problem in tech seems to be a matter of getting humans to work together effectively, and not tech itself.

Article: Getting the world to do the work for you

The author begins with this quote:

What the pupil must learn, if he learns anything at all, is that the world will do most of the work for you, provided you cooperate with it by identifying how it really works and aligning with those realities. If we do not let the world teach us, it teaches us a lesson. — Joseph Tussman

Then adds this comment:

Leverage amplifies an input to provide a greater output. There are leverage points in all systems. To know the leverage point is to know where to apply your effort. Focusing on the leverage point will yield non-linear results.

I stumbled on this article when I was reading “The Difference Between Amateurs and Professionals” which stated the following:

Amateurs believe that the world should work the way they want it to. Professionals realize that they have to work with the world as they find it.

Article: Why Composition is Harder with Classes

Most modern devices have RAM measured in gigabytes and any type of closure scope or property lookup is measured in hundreds of thousands or millions of ops/second, so performance differences are rarely measurable in the context of an application, let alone impactful.

Then later:

In the context of applications, we should avoid premature optimization, and focus our efforts only where they’ll make a large impact. For most applications, that means our network calls & payloads, animations, asset caching strategies, etc… Don’t micro-optimize for performance unless you’ve noticed a performance problem, profiled your application code, and pinpointed a real bottleneck. Instead, you should optimize code for maintenance and flexibility.

Article: Seamfullness from Jeremy Keith

Always interesting insights from Jeremy:

I’ve written about seams before. I really feel there’s value—and empowerment—in exposing the points of connection in a system. When designers attempt to airbrush those seams away, I worry that they are moving from “Don’t make me think” to “Don’t allow me to think”.

In many ways, aiming for seamlessness in design feels like the easy way out. It’s a surface-level approach that literally glosses over any deeper problems. I think it might be driven my an underlying assumption that seams are, by definition, ugly. Certainly there are plenty of daily experiences where the seams are noticeable and frustrating. But I don’t think it needs to be this way. The real design challenge is to make those seams beautiful.


Reading Notes, June 2017

Video: Andrew Clark Keynote @ ReactEurope 2017

An interesting overview on the state of React and where it’s headed, especially in regards to React Fiber and its “cooperative multitasking” feature.

The speaker does a really good job explaining the current problem React has due to the single-threaded nature of Javascript, which essentially boils down to this: it doesn’t matter how efficient your code is if you end up scheduling a lot of it in an uninterrupted sequence. React Fiber attempts to solve this through a more asynchronous approach to component rendering.

It’s an interesting look at where we are with React and where we might go in the future.

Article: “Some Lessons I Learned in 2013” by Frank Chimero

This is a couple years old now, but I found Frank’s “lessons learned” insightful:

  1. Life isn’t a story.
  2. A lot of things don’t need to be intellectualized: “because I want to” is often a good enough reason.
  3. Empathy is first an act of imagination.
  4. Don’t take business advice from people with bad personal lives.
  5. There are two ways to look at your life: what happened to you or what you did.
  6. Resources don’t replace will.
  7. Lazy trumps smart.
  8. Everybody wants to give advice and no one wants to take it.
  9. We only deserve what we can take care of.
  10. Clearly labeling other people’s petty grievances as bullshit is a fast track to well-being and fewer complaints of your own.
  11. Money is circulated. Time is spent.
  12. You can punch back.
  13. Social media gets less annoying if you’re willing to say to people, “Who the hell do you think you are?”
  14. Pain is unavoidable. Suffering is optional.
  15. Who you are has more to do with how you act and what you love than what you have or say.
  16. It’s more complicated than that.
  17. Everything good I have came from honesty, good intentions, and low expectations.
  18. Stick with the attentive ones.
  19. Find a way to forgive your mistakes.
  20. You’ll never know enough. Oh well.

Article: Conversations with Technology Leaders: Erik Meijer

This is a Q&A article I stumbled on that has some good pieces of advice in it.

First, I liked this point on the absolutist terms we so often use in conversations: “oh, we have to use X because it’s declarative”. Declarative compared to what? These arguments should be more specific.

We cannot talk about everything in absolute terms. Compared to assembly code, C is declarative. But compared to transistors and gates, assembly code is declarative. Developers need to recognize these levels of abstractions.

I also liked the metaphor of computer tools being an extension of your mind:

Good developers understand that they can't do everything, and they know how to leverage tools as prosthetics for their brains.

Some interesting advice on how to find your way between theory and practice (as alway the answer seems to lie somewhere in the middle):

focus at the intersection of theory and practice. There is no progress without friction. It is easy to dive into theory, or all the way into just practice—but the real interesting work happens between theory and practice. Try to understand both sides. The safe spot is to retreat to one of the extremes.

Remember: there is no silver bullet. Your processes alone won’t save you:

With prescriptive processes, people are looking for a silver bullet to solve problems, but it doesn't exist...The world is super-confusing, and you have to embrace it and work with it.

Lastly, I love this bit about finding questions before answers. I often have to remind myself of this before digging into any project:

first focus on finding the right questions, and then the answers.

Article: The art of throwing JavaScript errors

There were two good reminder pieces for me in this article:

Errors are the friends of developers, not enemies.

And

It helps to think of errors as built-in failure cases. It’s always easier to plan for a failure at a particular point in code than it is to anticipate failure everywhere.

Article: Design Better Data Tables

A page full of gifs depicting interaction paradigms for designing data tables. Kind of an interesting little summary.

Gif of table header interaction


Reading Notes, May 2017

Article: “Complexity and Strategy” by Terry Crowley, Former Microsoft Office Lead

Terry Crowley, a Microsoft engineer who lead Office development for over the last decade, reflects on the complexity of building software: from planning releases to technical strategy to dealing with market competition. There were two parts that stuck out to me I wanted to note:

First, he comments on how Google came into the "office productivity" space and applied pressure to what Microsoft was doing by having a suite of tools purely in the browser, available to any platform with an OS. Though he thinks it's too early to see how this will all play out, he does believe the complexity Microsoft has endured in building native Office tools (as opposed to Google's web-based tools) may end benefiting them. Googles apps can't compete in terms of functionality and features because building software as rich as Office in the browser just isn't feasible.

the performance challenges with running large amounts of code or large data models in the browser and managing the high relative latency between the front and back end of your application generally make it harder to build complex applications in a web-based environment. Hyper-ventilation by journalists and analysts about the pace of Google App’s innovation generally ignored the fact that the applications remained relatively simple...I knew the pace of innovation that was possible when functionality was still relatively low ...and nothing I saw as Google Apps evolved challenged that.

In the end, the complexity of the Office software suite ends up acting as a “moat” against the attacks of competitors that simply can’t be crossed without the years of experience Microsoft has gained building this kind of software.

Competitive strategy argues that when a competitor attempts to differentiate you need to focus on neutralizing that differentiation as quickly as possible... It is clear the Office apps would not be positioned functionally the way they are now (with fully compatible native and web clients on all devices and support for offline and co-editing) if there had been any squeamishness about embracing the challenges of complexity. That complexity (as it embodies valued functionality) is the moat.

It’s interesting to think of this complexity, rather than being an liability to the business, when viewed and handled correctly, being an asset and competitive advantage.

Number two:

The dynamic you see with especially long-lived code bases like Office is that the amount of framework code becomes dominated over time by the amount of application code and in fact frameworks over time get absorbed into the overall code base. The framework typically fails to evolve along the path required by the product — which leads to the general advice “you ship it, you own it”. This means that you eventually pay for all that code that lifted your initial productivity. So “free code” tends to be “free as in puppy” rather than “free as in beer”.

I find that a very interesting long-term observation on leveraging frameworks in your codebase. You always see the benefits up front. But in the long run frameworks are “free as in puppy”: once the initial joy has subsided they leave you with responsibility.

Article: “Back to the Cave” by Frank Chimero

I have to admit, when I first started reading this and the author was framing some important questions, I felt like I was going to barf a little when it seemed he was going to give a definitive answer for each (like almost every article on the internet it seems). But then he didn't. It was so refreshing. It reminded me how little things like that make me love Frank’s writing. The question he frames: is going off on your own worth it?

Well, I am here to offer a resounding maybe.

Frank is always marrying paradoxes, which is what makes great writing in my opinion. Like this other part:

How can we be independent together?

Independent together? Resounding maybe? Jumbo shrimp? These are great paradoxes stacked against each other and in proving contraries you find the truth. As Frank points out later in his article “independence is always supported by interdependence."

Now about employment:

Many people presume that employment is the opposite of independence, and that endlessly irritates me. It’s so short-sighted. History shows a long record of artists who did “normal” work to support their creative practice.

He points out many of the famous artists and writers whose work that is now famous today were “side projects” from their daily employment.

There’s one other important benefit to the unrelated day job: when it comes to your art, you don’t have to take any shit from anybody. You can honor any creative impulse because your paycheck is never on the line. Go nuts, make crazy shit. What’s more independent than that.

That’s one reason I’ve personally never liked contract work on the side, or even writing tutorials now. I feel like I have to finish all those things and sometimes I just don't want to. I want to explore as far as I want to go and stop when I want. A day job affords me that because my side projects can be whatever I want whenever I want. I never thought of that, but that is freedom.

Along these lines there is also great quote for this Krista Tippet:

I worry about our focus on meaningful work. I think that’s possible for some of us, but I don’t want us to locate the meaningfulness of our lives in our work. I think that was a 20th-Century trap. I’m very committed and fond of the language of vocation, which I think became narrowly tied to our job titles in the 20th Century. Our vocations or callings as human beings may be located in our job descriptions, but they may also be located in how we are present to whatever it is we do

That last line is fantastic: finding meaning and a calling might be found in being present in whatever we do, be that our job, parenting, or just being a friend. As Frank goes on to comment, “meaning comes from a way of being”:

When Campbell told us to follow our bliss, he wasn’t telling everyone to chase their dreams until they became careers. He said it as a call for people to pursue a vocation as Krista Tippett has defined it. Vocation is as much about who you are and how you are as it is about what you do. Bliss is an attitude, a disposition, so meaning comes from a way of being and is not a consequence of producing work. You make the art, the art does not make you.

One last great point:

I mistake the work’s flaws for my own. Perhaps that’s something many of us have in common. The way to approach this issue is clear: we must acknowledge we are involved in our unsteadiness, but believe we are only part of its reason. If we allow room in our work for serendipity to occur, that same space must also be reserved for misfortune. We are the cause of neither.

Quote: Sovling Problems

A quote often attributed to Einstein, though apparently sourced from a nameless professor at Yale:

If I had only one hour to solve a problem, I would spend up to two-thirds of that hour in attempting to define what the problem is.

The more I work in software, the more I realize this is the way to go.

Article: “How technology created a global village—and put us at each others throats” by Nicholas Carr via The Boston Globe

I don’t know how they get numbers like this, but it’s an interesting figure:

Thanks to the Internet and cellular networks, humanity is more connected than ever. Of the world’s 7 billion people, 6 billion have access to a mobile phone — a billion and a half more, the United Nations reports, than have access to a working toilet.

All of this interconnectivity was supposed to foster tolerance. The more we knew of someone, the more we would like them. Or at least tolerate them. Carr points out that assumption isn’t new. It’s been proclaimed by many western thinkers since the invention of the telegraph—and radio, TV, phone and Internet were only supposed to make it better. And yet, in some ways, they didn’t.

Yet we live in a fractious time, defined not by concord but by conflict. Xenophobia is on the rise. Political and social fissures are widening. From the White House down, public discourse is characterized by vitriol and insult. We probably shouldn’t be surprised

He cites some research done by psychologist in 2007 around people who lived in the same apartment building and they found that:

as people live more closely together, the likelihood that they’ll become friends goes up, but the likelihood that they’ll become enemies goes up even more...The nearer we get to others, the harder it becomes to avoid evidence of their irritating habits. Proximity makes differences stand out.

Social networks seem to only amplify this effect:

Social networks like Facebook and messaging apps like Snapchat encourage constant self-disclosure. Because status is measured quantitatively online, in numbers of followers, friends, and likes, people are rewarded for broadcasting endless details about their lives and thoughts through messages and photographs. To shut up, even briefly, is to disappear. One study found that people share four times as much information about themselves when they converse through computers as when they talk in person.

Work along these lines from British scholars in 2011 concluded:

With the advent of social media it is inevitable that we will end up knowing more about people, and also more likely that we end up disliking them because of it.

That rings true every time you hear someone talk complain about all the racist, hateful, stupid garbage from acquaintances in their Facebook feed. I agree with Carr that, at then end of the day, you’ll never be able to build a global community of harmony with only software.

[there’s an idea], long prevalent in American culture, that technological progress is sufficient to ensure social progress. If we get the engineering right, our better angels will triumph. It’s a pleasant thought, but it’s a fantasy. Progress toward a more amicable world will require not technological magic but concrete, painstaking, and altogether human measures: negotiation and compromise, a renewed emphasis on civics and reasoned debate, a citizenry able to appreciate contrary perspectives. At a personal level, we may need less self-expression and more self-examination.

Love that last line. It’s worth repeating:

we may need less self-expression and more self-examination

Carr concludes:

[technology doesn’t] make us better people. That’s a job we can’t offload on machines.

Video: “The Post JavaScript Apocalypse” by Douglas Crockford

Some thoughts about the direction of JavaScript, specifically how to remove redundant constructs of today’s javascript from the language and leave ourselves with fewer methods of expression. You might think having fewer methods of expression would be a bad thing, but he argues that fewer is actually better because it lowers the cognitive dissonance you encounter when running into two things that are mostly similar but not identical, which you then have to expend mental energy differentiating (he illustrated this with an analogy to purging your life of things, which I thought was interesting). It’s a parallel for Garrett’s law, which goes something like this: if two things are similar, either 1) accentuate the differences and make them more different, or 2) eliminate the differences and make them identical.

Here are some examples of changes the speaker recommended:

He goes into depth on other idiosyncrasies of JavaScript and how he would fix them. Things like what 0 / 0 should equal and why (0.1 + 0.2 === 0.3) returns false. It was an interesting talk and I found the metaphor for removing clutter from your life an interesting parallel to the argument for removing redundancies from the langauage of JavaScript. Obviously you can’t just remove them now, but from a perspective of personal code writing, it’s an interesting argument I may try out in practice.

Video: Jeremy Keith at Render 2017

Two important questions when building software:

  1. How well does it work?
  2. How well does it fail?

Great example with CSS shapes. In browsers that don’t support it, if you use it, you just get a regular fallback.

Service workers are another good example. When somebody loads your webpage for the first time, they download images, html, css, etc, and a service worker. Then on any subsequent request, the service worker does it’s work. Note that every browser, the first time your page is loaded, doesn’t support service workers because they haven’t been downloaded yet. So you start out building under the assumption that your site doesn’t have a service worker, then you enhance from there.

It’s a really good way to build your UI’s, by building them around failure cases.

Article: “Mobile First, Desktop Worst – Prototyping: From UX to Front End” by Oliver Brooks, Creative Director at MetaLab

An interesting read which presents a challenge to the traditional mobile first thinking. The author contrasts “mobile first” design philosophy (at least as one of its definitions) to an analogy of physical product design:

If “Mobile First” design philosophy were applied in the domain of physical product design, the implication would be that you should design the compact, multi-tool screwdriver first. The compact design could then be used to inform the design of a larger version. Why? Because it allegedly is best to ladder-up in complexity (see, progressive enhancement vs. graceful degradation). This idea is, however, is based on the assumption that there is a consistent, linear relationship between complexity and form.

I like the challenge he presents to the assunmption that “there is a consistent, linear relationship between complexity and form”. For some websites I think staring at mobile first and building up linearly works just fine. For others, however, I think it leaves much lacking.

Article: “Plainness and Sweetness” by Frank Chimero

It’s human nature: I over-value where I have influence. Since I am a designer, this frequently means placing too much emphasis on how things look and work rather than the direction they are pointed. But reflecting on the other side of the issue is also interesting: I find that the more input I have in the content and strategy of the project, the less burden I place on the aesthetics. Perhaps this is because I believe the aesthetic of the work should be an extension of its objectives, so if you get the strategy right, the look follows. Since I like to tackle problems sideways, I must risk being plain and rely on direct visuals to keep the work comprehensible.

And this next part is good:

I am for a design that’s like vanilla ice cream: simple and sweet, plain without being austere. It should be a base for more indulgent experiences on the occasions they are needed, like adding chocolate chips and cookie dough. Yet these special occasions are rare. A good vanilla ice cream is usually enough. I don’t wish to be dogmatic—every approach has its place, but sometimes plainness needs defending in a world starved for attention and wildly focused on individuality. Here is a reminder: the surest way forward is usually a plain approach done with close attention to detail. You can refine the normal into the sophisticated by pursuing clarity and consistency. Attentiveness turns the normal artful

More:

the longer we spend in contact with the products of design, the more their willful attempts at individualism irritate us.

The danger of redesigning your brand to current trends:

Many believe that normalcy and consistency breads monotony, but what about the trap of an overly accentuated, hyper-specific identity? When the world changes around you, what do you do?

This is often true of personal portfolios that strive to be different, but in reality, when you're sorting through tons of resumes you're looking for the content before the individuality. The individuality are like fireworks, they may catch your attention for a second, but once that attention is grabbed, if the content is confusing, hard to read, hard to digest, you've failed.

All contain the aching desire to be noticed when instead they should focus on being useful.


Reading Notes, April 2017

The end of the black turtleneck” via zurb.com

Interesting look at how, over time, the curtain has been pulled back on Apple’s magic. Some of this article is meh, but there are a few good pieces in here.

On how we took the wrong things away from Apple and Steve’s methods:

Designer’s took all the wrong ideas away from his presentations. Big reveals were marketing techniques, not methods to surprise our internal product teams. Sexy interfaces were inspirational, not things we blindly copy without consideration for users. Going against the grain was a way to inspire people, not an excuse to shun the ideas of our coworkers . Secrecy was a business technique, not a reason for us to hide and design solo in our computers. Spurring focus groups encouraged risk taking, not give us a reason to avoid learning from our customers.

But now the curtain has been pulled back. We know the truth. We’ve known it the whole time from our own experiences. We just didn’t want to admit it. It’s like when you see celebrity news and realize “oh, they put their pants on one leg at a time like the rest of us”. It’s time to reshape our own thinking and processes:

It’s time for designers to embrace what really drives amazing products and innovation, connection with other people. The impactful design leader is not a lone genius that locks themselves away only to come back with magic that even they themselves don't fully understand. That’s myth, storytelling. No, the impactful design leader is a facilitator. They bring people together from all parts of their organization, rally them around ideas, and extract the best thinking into small gains that lead to big wins. They are found with people, soliciting feedback from designer and non designer alike. They realize failure is both an inevitable and necessary part of the process. They understand it takes constant iteration and a volume of ideas to get to the right answers. And they don’t have to wear a black turtleneck.

How to Use npm Scripts as Your Build Tool”, an egghead.io course

An egghead.io course with lots of useful little tidbits I hadn’t become familiar with yet:

Resilient Web Design” by Jeremy Keith

If you haven’t already heard, Jeremy released this “web book” as he calls it. If you read or listen to Jeremy regularly (like I do) most of the content will feel familiar. Nonetheless, I gave it a read and have noted here a few excerpts that stuck out to me when I read it.


The book’s purpose (and the power of ideas over)

You won’t find any code in here to help you build better websites. But you will find ideas and approaches. Ideas are more resilient than code. I’ve tried to combine the most resilient ideas from the history of web design into an approach for building the websites of the future.

Interesting tidbits on why things are the way they are today:

That same interface might use the image of a 3½ inch floppy disk to represent the concept of saving data. The reason why floppy disks wound up being 3½ inches in size is because the disk was designed to fit into a shirt pocket. The icons in our software interfaces are whispering stories to us from the history of clothing and fashion.

Embracing the uncertainty of the web:

While it’s true that when designing with Dreamweaver, what you see is what you get, on the web there is no guarantee that what you see is what everyone else will get. Once again, web designers were encouraged to embrace the illusion of control rather than face the inherent uncertainty of their medium.

History of JavaScript. Love that last line:

The language went through a few name changes. First it was called Mocha. Then it was officially launched as LiveScript. Then the marketing department swept in and renamed it JavaScript, hoping that the name would ride the wave of hype associated with the then‐new Java language. In truth, the languages have little in common. Java is to JavaScript as ham is to hamster.

Imperative and declarative:

That’s a pattern that repeats again and again: a solution is created in an imperative language and if it’s popular enough, it migrates to a declarative language over time. When a feature is available in a declarative language, not only is it easier to write, it’s also more robust

Savage:

Despite JavaScript’s fragile error‐handling model, web designers became more reliant on JavaScript over time. In 2015, NASA relaunched its website as a web app. If you wanted to read the latest news of the agency’s space exploration efforts, you first had to download and execute three megabytes of JavaScript. This content—text and images—could have been delivered in the HTML, but the developers decided to use Ajax to retrieve this data instead. Until all that JavaScript was loaded, parsed, and executed, visitors to the site were left staring at a black background. Perhaps this was intended as a demonstration of the vast lonely emptiness of space. (emphasis added)

The rise of deploying web apps via traditional software tooling (packaged entirely as a js app):

It’s tempting to apply the knowledge and learnings from another medium to the web. But it is more structurally honest to uncover the web’s own unique strengths and weaknesses.

He continues:

On the face of it, the term “web platform” seems harmless. Describing the web as a platform puts it on par with other software environments. Flash was a platform. Android is a platform. iOS is a platform. But the web is not a platform. The whole point of the web is that it is cross‐platform...The web isn’t a platform. It’s a continuum.

Video: “How to Design a Good API and Why it Matters” by Joshua Block, Principal Software Engineer at Google

In my search for stuff to listen to, I Google’d “the best programming talks” and this was one I stumbled on in a comment thread somewhere out there on the internet.

As I’m not a real computer programmer (but as Pinocchio said, maybe someday) I like to find talks that take a broader perspective and explore principles applicative to any discipline, be it programming, design, or maybe just woodworking. This talk had some of that, thought it was also quite technical at times. Anyhow, I wanted to just make some notes on the tidbits I liked (the slides from the talk can be found here).

Implementation Should Not Impact API

Don’t let implementation details “leak” into API

I think this stood out to me most because it’s something I’ve seen happening a lot at my current job: the technical details of a particular service or API has leaked into a user-facing product and become a mental model for both internal employees and external customers. The problem with this, as the speaker points out, is that it inhibits the freedom to change the implementation in the future because people depend on it.

Names Matter

Around minute 31 he talks about how your API is a little language unto itself. You should be consistent and regular where terminology is largely self-explanatory. If you succeed in naming things consistently and simply your code can end up reading like prose, which is generally an indicator of a well-designed API, i.e.

if (car.speed() > 2 * SPEED_LIGHT) {
  speaker.generateAlert('Watch out for cops!');
}

Using Conventions

Around minute 39 he started talking on how you should borrow conventions from existing languages and platforms. Some of his points included:

His point, which I think can be generalized to any profession, is that if you build with concepts people are already familiar with, it can lend simplicity to your product. If somebody knows how to use a native convention in a programming language or ecosystem, they’ll know how to use yours. But don't transliterate he says. If you’re building for C, don’t learn everything about C’s way of doing X and mirror that to your tool. Plus what was correct in C may not be correct for your particular implementation. It’s good to step back and ask “what is this trying to do?”.


Reading Notes, January 2017

Tweet: @practicingdev

The work of an experienced software developer... perception vs. reality.

Perception vs. reality in software

Article: The JavaScript Wars

One interesting thought: HTML, CSS, and JavaScript are often called “the building blocks of the web”. But perhaps it’s worth considering URLs as the building blocks of the web:

There is another building block for the web, one that is more important than HTML, CSS and JavaScript combined. It all starts with URLs. Those things uniquely identify some piece of information on the web. It should not be that hard or expensive to have a server dump this information into HTML, whatever that information might be; some content, a list of URLs to some more content, you name it. Let’s keep it really simple, just the content, without replicating any of the site’s chrome

It’d be an interesting design exercise to work on building a site purely from URLs with no navigation, i.e. what would typically be your application header would just be one level up: in the browser URL bar.

Article: Your are not paid to write code

New industry title: Front-end Systems Engineer. The responsibilities? You spend all your time updating dependencies of a project.

(See Rich Hickey notes about how gem install hairball is easy: easy to get all that complexity.)

But if you set up a system, you are likely to find your time and effort now being consumed in the care and feeding of the system itself. New problems are created by its very presence. Once set up, it won’t go away, it grows and encroaches. It begins to do strange and wonderful things. Breaks down in ways you never thought possible. It kicks back, gets in the way, and opposes its own proper function. Your own perspective becomes distorted by being in the system. You become anxious and push on it to make it work. Eventually you come to believe that the misbegotten product it so grudgingly delivers is what you really wanted all the time. At that point encroachment has become complete. You have become absorbed. You are now a systems person. (emphasis added)

On another note:

We’re not paid to write code, we’re paid to add value (or reduce cost) to the business. Yet I often see people measuring their worth in code, in systems, in tools—all of the output that’s easy to measure. I see it come at the expense of attending meetings. I see it at the expense of supporting other teams. I see it at the expense of cross-training and personal/professional development. It’s like full-bore coding has become the norm and we’ve given up everything else.

Conclusion:

engineers should understand that they are not defined by their tools but rather the problems they solve and ultimately the value they add. But it’s important to spell out that this goes beyond things like commits, PRs, and other vanity metrics...you are not paid to write code.

Article: Kiss My Classname from Jeremy Zeldman

The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries. And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top. (emphasis added)

I added that emphasis because I thought it was a great point. It’s easy to point the finger and say “well it’s not my fault the codebase is impenetrable” but as a professional software engineer it’s your job to communicate the value and importance of a codebase that is comprehendible. Zeldman continues:

Employers who value quality in CSS and markup will insist that their employees communicate, think through long-term implications, and document their work. Employers who see developers and designers as interchangeable commodities will hurry their workers along, resulting in bloated codebases that lead intelligent people to blame best practices instead of work processes.

Great perspective, in my opinion, on organizational structure and effects on code. It’s always talked about how John or Jane Doe developer impacted the codebase, but people outside of the engineering department have an effect too. And that impact is not often talked about (or even perceived).

Article: Software development: it's got nothing to do with computers

“When it comes to successful software development only the people matter.”

Code matters, but code is ultimately written by people. I think there were some good questions to ask here about your own software teams:

  1. How coherently does your team work?
  2. How well do they communicate with each other?
  3. What processes are in place that empowers them?
  4. Do they derive pride from their work?
  5. How involved do they feel?

Article: On Getting Old(er) in Tech

Don't love everything in this article, but a few pieces I think are solid. Like this:

When I hear someone say they have 20 years of experience, I wonder if that’s really true or if they merely had 1 year of experience 20 times. I’ve known too many developers that used the same techniques they learned in their first year of employment for the entire span of their career...My point is certainly not that younger developers are smarter. It’s that many programmers let themselves grow stale. And the bigger problem is, after doing the same year’s worth of experience ten times, many programmers forget how to learn. Not only can it be extremely hard to catch up with ten years of technology, it can be next to impossible if you’ve forgotten how to learn.

If you plan on being in the IT field for more than 10 years, you need to be a lifelong learner. I’ve always been a lifelong learner. I’ve learned and developed with numerous programming languages, frameworks, and strategies. As a result, I’ve honed my learning skills.

“I’ve honed my learning skills”, a resume piece indeed. I need someone who will take on whatever is thrown at them. That might mean doing it yourself. Or it might mean finding someone else to do it. Or it might mean recruiting the aid of someone else, who does know what they're doing, and letting them guide you through to the completion of the project.

For example, at my most recent job, a customer promise was made with significant business implications. I was asked to help lead the engineering effort through to completion. All I was given was a repository for a codebase nobody understood which was written in Ruby (a language I don’t know except for the occasional fiddling around with Jekyll). But hey, it was a problem that needed to be solved to add value to the business. So I dived in, recruited others to help, and saw it through.

Article: Test Your Ideas (And Assumptions)

Idea of figuring out a basic prototype deliverable first. If people don’t get that right away, the extra work you would’ve invested wouldn’t have been enough to make it successful. Instead refine the conceptual idea more until the prototype is enough to convey and convince.

Cut everything else out and share it with the world. Right now. It isn’t easy – you’ll worry it isn’t polished enough. But that’s the point. If your audience doesn’t “get it” in the rough stages, it’s unlikely a few extra hours of work will change their minds. You can always improve it later if the feedback is positive...Some of the more critical comments sting a little, at first. But I’d rather hear them now than ten episodes down the road.

Article: Web development as a hack of hacks

An interesting commentary on a hacker news thread. Front-end is often looked down on, but that looked down upon-ness stems mostly from real CS people who see the web stack (HTML, CSS, JavaScript) as suboptimal to their real stacks.

When people talk bad about JavaScript, HTML, and CSS:

The main reason back-end developers don’t understand front-end is that they expect a well-defined environment.

That’s an advantage of the web! The multiple browsers, the varied environments is what gives you reach, unlike any other platform!

if there's any reason why tech ageism is amazingly dumb it's this one imo (have the guy on your team who's graduated past the fanboy stage make your tool, platform and framework choices, you will save far more than the premium that you have to pay him).

Front-end-ers love shiny stuff, but sometimes it’s employers too: (hackernews comment)

This is because employers are demanding that candidates know the latest and greatest technologies (eg. looking for 5 years of experience in 1 year old technology)...If I need to be experienced with [all this shiny new stuff] to stay employable because just doing my job isn’t enough, then I’m going to learn it.

The real problem he comes up with:

the main reason why front-end is so behind: Real Programmers With A CS Degree don’t do front-end. Front-end is for script kiddies and pixel pushers, it’s not to be taken seriously...Unfortunately Real Programmers don’t know anything about browsers and have no desire to learn. That makes them useless as front-end teachers. This problem, more than anything else, is what perpetuates web development as a hack of hacks.


Reading Notes, November 2016

Video: Rich Hickey Rails Conf Keynote: Simplicity Matters

specialization generally leads to optimization, not innovation

Though this talk was targeted at rails developers, I couldn’t help but see the parallels to front-end javascript developers.

npm install hairball

Is that simple or easy? It's easy — easy to get that complexity. Perhaps it was simple to get a hairball, but now you have to deal with that hairball and inevitably down the line that's complex.

If you want everything to be familiar you’ll never learn anything new.

Article: One Behavior Separates The Successful From The Average

Generally I dislike articles with headlines like this. But the story in the article illustrates a characteristic of great employees that is sometimes difficult to articulate. The story goes something like this:

A Dad asked his first son, “will you go find out how many cows Cibi has for sale?” The son promptly returned and said “6 cows are for sale.”

The Dad then asked his second son the same question. The second son later returned and said “6 cows [are] for sale. Each cow will cost 2,000 rupees. If we are thinking about buying more than 6 cows, Cibi said he would be willing to reduce the price 100 rupees. Cibi also said they are getting special jersey cows next week if we aren’t in a hurry, it may be good to wait. However, if we need the cows urgently, Cibi said he could deliver the cows tomorrow.”

This short story illustrates a trait an admirable characteristic of great employees. It’s not just about the mandate, it’s about the why behind the mandate. “Why am I being asked to do this?” You can do what your told blindly, but that’s not what your employer needs. Your employer needs you to add value through your own knowledge and experience.

Most people only do what they are asked, doing only the minimum requirement. They need specific instructions on most things they do. Conversely, those who become successful are anxiously engaged in a good cause. They don’t need to be managed in all things...They also influence the direction for how certain ideas and projects go...They reach out to people, ask questions, make recommendations, offer to help, and pitch their ideas.

You’re given a sphere of influence to act within. Act. Don’t simply be acted upon.

Tweet: Advice on Management

Mar Headland has been working as an engineering manager since 1994. Recently on Twitter he talked about how he gets lots of requests for management advice. So, based on the list of questions he’s compiled over the years, he generated the following advice (rolled out in ten tweets):

  1. Just tell them already. One of the best things you can do as a manager is be completely blunt about what you see. Tell them now.
  2. Trust is the currency of good management. You cannot be a great manager if the people with whom you work do not trust you.
  3. Regular one-on-ones are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time.
  4. You have to be your team's best ally and biggest challenger. You can't be a great leader by care-taking alone. Push for their best work.
  5. Repetition feels silly but works wonders. Start each conversation repeating the overall goal and connecting it to the discussion.
  6. "My team wants to work on ___ because it is more fun for them, is that okay?" No. Never. Quoting @jasonk: "Winning is fun." Go win.
  7. Clarify the problems your team needs to tackle. Stay all the way away from specifying the solutions. That's their job, not yours.
  8. You can't know how the company looks from any other seat than your own. Practice with people in other seats to communicate and manage well.
  9. We talk a lot about diversity and inclusion. Here's my unpopular opinion: you, as a manager, have to force it to happen, or it won't ever.
  10. Usually when people ask, "Should I fire this person?" the answer is yes. But usually they do it dramatically more brutally than needed.

Article: How I Practice Resilience for the Unknown Trying Times Ahead

Here’s my paraphrase:

Sometimes, try taking the things that are against your typical behavior and instead of avoiding them, do them. Practice patience, speak up, quiet down, whatever it is, use the things that make you angry as opportunities to learn how to control your own shortcomings. Be ready for future difficulties. And the best way to do that is with practice.

It’s a really interesting and practical approach to day to day life. When things happen that are uncomfortable or unnatural to you, brace them as opportunities for practice. Rather than practicing your already refined skill of avoiding them.

Article: My Increasing Wariness of Dogmatism

Hardly a day goes by I don't see a dogmatic statement about the web.

Here’s a short list:

But nothing is wrong with people spouting off opinions right?

I see ideas that start as dogmatic claims spread. I've heard people regurgitate a dogmatic statement years after I've felt like the industry had moved on. When you happen to agree with them, they feel good. They feel powerful. They feel like something you want to get behind and spread yourself. They don't have that wishy-washy "it depends" feeling that doesn't provide hard and fast answers.

However:

Everyone's situation is different than yours. You can't know everything. There is endless gray area.

Chris argues we should perhaps be a little more verbose in our opinions:

It's certainly wordier to avoid dogma when you're trying to make a point. But it's more honest. It's more clear. It's showing empathy for people out there doing things different. It makes it easier for others to empathize with you.


Reading Notes, October 2016

Typography Is Impossible” by Marcin Wichary via Medium

This was an interesting post on digital typography and, although a lot of it presented quirks and peculiarities I am already familiar with, I wanted to document a few notes I found novel.

Type and Boxes

Digital type lives in boxes. That’s how the software works. But the box is really just a suggestion. Not everything will fit all the time. On the web you don’t have to worry about this unless you start using overflow: hidden:

by default, browsers allow stuff to stick out, unless the container or one of its parents use overflow: hidden instead of overflow: visible. If for whatever reason it’s necessary to apply that restriction, it is important to add horizontal and vertical padding so that text is not clipped.

So how much space do you need to allot a box of type being cut off by overflow: hidden?

A rough suggestion would be to add horizontal padding that’s ⅓ of the font size.

Type and Sizing

Type sizing is different. Sure, you say font-size: 50px, but you’ve probably noticed that a defined font size in one typefaces can take up a significantly different amount of space than the same size font of another typeface.

I’ve seen the results of this problem many times on the web. For example, you’ve got a big H1 on your website where you use a third-party web font service to display that big headline in a traditionally unavailable system font. When it loads, it looks like this:

Innovation Is Our
Middle Name

But if that particular font doesn’t load correctly (or perhaps for a split second while the font is actually downloading to the client) you see it displayed in a fallback system font. It’s quiet possible it now takes up a different amount of space and the word wrapping is different:

Innovation Is Our Middle
Name

This could end up being a problem because often you intentionally design your type to fit a certain way, like when wrapping words around a certain part of an image or deliberately putting words on separate lines to add a punch. Differences in type sizing between font families can so easily break your design.

Font sizes are different. Some quite drastically from one another. That’s because font size is a measure of the type’s containing box, not the type itself:

It turns out that when you choose font size, you actually only choose the size of the box the font lives within. What happens within that box is up to the type designer

This can result in even more problems than the ones just outlined above. For example, not all fonts sit on the same baseline, which can cause alignment issues if you use a fallback. It’s definitely something to be cognizant of when designing for the web where your font choices, though we would like to believe otherwise, are never truly bulletproof.

Type simply doesn’t abide by the rules of static, pixel images:

When you spread two images apart, you can rest assured 20 pixels will mean exactly 20 pixels. When it comes to text, those 20 pixels will be accompanied by extra vertical padding at the bottom and top of each text box — and the text will feel like it’s further apart.

This means that often you have to feel your way through type layout and spacing (while being aware of possible font fallbacks). You won’t find a purely mathematical, bullet-proof approach to beautiful typography. As the author goes on to state:

Type is aligned when it feels aligned, not when it actually is aligned.

And this goes deeper in typography. Superscripts aren’t just the same glyphs shrunk down. Bold characters aren’t just the same letters with a stroke or two on them. Italic words aren’t just the normal versions slanted ten degrees. Type designers optimize these variations with subtle differences. They are all new shapes, redrawn from the “regular” ones so that they feel and appear optically correct.

At the end of the day, lots of these typographic guidelines are here because that’s what we’ve grown used to. And because we’ve grown used to it, it’s best to follow those norms because it sets up expectations between you and the reader.

A lot of [this] might seem arbitrary, but that’s typography for you, too: some of it is not things that are objectively better, just things we’re gotten used to over the last few centuries.

If you’re going to break those norms, do it for a reason. Design intentionally.

Extensible Web Components” by Jeremy Keith via Adactio

As always, insightful progressive enhancement thoughts around service workers vs. web components:

The next question we usually ask when we’re evaluating a technology is “how well does it work?” Personally, I think it’s just as important to ask “how well does it fail?”

Service workers work well and fail well. If a browser supports service workers, the user gets all the benefits. If a browser doesn’t support service workers, the user get the same experience they would have always had. Web components (will) work well, but fail badly. If a browser supports web components, the user gets the experience that the developer has crafted using these new technologies. If a browser doesn’t support web components, the user gets…probably nothing. It depends on how the web components have been designed.

It’s so much easier to get excited about implementing service workers. You’ve literally got nothing to lose and everything to gain.

The Future of the Web” by Matt Griffin via A List Apart

Why it’s ok to be failing while trying to find your way:

To get where we need to go, we have to do it wrong first...If we can continue to work together and consciously balance these dual impulses—pushing the boundaries of the web while keeping it open and accessible to everyone—we’ll know we’re on the right track, even if it’s sometimes a circuitous or befuddling one. Even if sometimes it’s kind of bad. Because that’s the only way I know to get to good.

Love that last bit: the only way to get good is to be bad.

Why we use progressive enhancement to build GOV.UK by Robin Whittleton via GOV.UK

This article is more interesting views on progressive enhancement, though there’s not a lot of novelty here. Progressive enhancement, though arguably not for everyone, seems ideal for a government website.

The more time I spend developing for the web the more I like the concept of progressive enhancement, if nothing else than for its 1) reach and 2) longevity. Pure javascript single-page-apps these days can be so brittle and tenuous in terms of longevity.

“progressive enhancement is about resilience as much as it is about inclusiveness.” ... Building in resilience is also known as defensive design: a system shouldn’t break wholly if a single part of it fails or isn’t supported.

We have a mandate to provide digital services to everyone in the UK and many beyond. Many users access services in different ways to the configuration tested by developers. If a person visits GOV.UK we want them to be able to complete their service or access the information they need, regardless of whether we’ve tested their configuration or not.


Reading Notes, September 2016

Book: Git for Humans from A Book Apart

I’ve been creating web stuff for over 10 years, and i’ve been working with Git for probably the last 4 or 5 of those. So I consider myself relatively rote in basic Git commands like commit, push, pull, etc. However, I’ve never felt like I really understood Git, so I grabbed this book thinking it might help. One of the more lasting impressions this book left me was a concept introduced in the preface of the book by Mandy Brown:

Knowing when and how to commit a change is more than just a means of updating code—it’s also a practice for communicating and sharing work. ... By all means, devour the following chapters in order to t understand how to manage merge conflicts and interpret a log. But don’t forget that Git’s ultimate audience isn’t machines—it’s humans.

This idea of looking at Git as a communication tool is reinforced throughout the entire book. Git can be seen as a way to tell a story about what’s happening to your codebase in a way that’s much “closer to the metal” than other communication tools Slack or email. It’s made me rethink my actions in Git, like how I craft commit messages, how I tag branches, and how I propose and merge pull requests. These can be viewed as more than commands in the terminal but as methods of communicating to humans in the story book of a project, Git becomes a powerful tool of communication over the life arc of your codebase.

For example, when I was first introduced to Git I thought it rather laborious. I liked the idea of saving changes often but having to write a message for every save? That seemed a bit much. Which is why my commit history looked something like:

Now after reading this book, I want to be more thoughtful in my approach to Git and commit messages. I want to have the change of mindset the author himself had and describes in the book:

I came to appreciate the benefits of having every signification version of my projects stored, annotated, and neatly organized ... [it helped me] to think of commits as significant changes, as opposed to the hundreds of little changes I might save in a given hour. The extra steps involved in committing ... have ultimately helped me develop a more thoughtful and judicious way of working.

I think if you work in Git long enough, you’ll begin to appreciate how all those little commits and actions stack up over the course of a project. To have a couple year-old project that is beautifully documented in Git is something you’ll never get through shortcuts. You’ll only get it through disciplined, thoughtful work over a long span of time. Chris Beams talks about this in his article “How to Write a Git Commit Message”. He begins by showing two examples of commit histories, one earlier in his project when he wasn’t caring about commit messages and the other later in the project when he began caring:

Screenshot of two git histories

The former varies wildly in length and form; the latter is concise and consistent. The former is what happens by default; the latter never happens by accident.

If you’ve worked in software, you know the truth of those words: “the former is what happens by default, the latter never happens by accident”. The author of “Git for Humans” touches on this same point in his book:

Every commit you add to your repository contributes to the historical record of your project, so it’s a good idea to make the best, most meaningful commits you can.

That’s what I enjoyed most about this book. I didn’t come away with a lot of technical tips and tricks on using Git (though I’m sure as a newbie to Git you could gain precisely that). Rather, I came away with a broader view of Git as a tool and a process. Git can be about version control, yes. But it can also be about regular people making changes, evolving a code base, crafting a history, and doing it all together. Git can be a story, the story of your time with other people on a project, a biography of yourself, your team, and your product.

Book: Responsive Design: Patterns & Principles from A Book Apart

Here’s the thing about this book: it covers a lot of information that, if you’re current on the latest trends in web design, isn’t new. Don’t get me wrong, the author covers it in a clear, concise manner. If I was a beginner to the field, I would find this book very useful. But as a practitioner, I found the book mostly reviewing things I’m already doing every day (or am at least aware of in some fashion). I would still think the book is well written and would recommend it to anyone who is new to the landscape of responsive web design and wondering how all this responsive stuff is actually accomplished. But for a practitioner there won’t be a lot of new “tips and tricks”. With that said, here are a few things that stood out to me that I enjoyed:

Ajax-Include Pattern

Ethan covers the topic of conditionally loading menus and other content via javascript (as opposed to serving everything on page load and then just showing/hiding parts via CSS). One method he gives for accomplishing this, which I had not seen but found to be quite clever and semantic, is the Filament Group's Ajax-include pattern. You can simply reference the HTML want you loaded in an HTML5 data attribute, like so:

<li data-append="/politics/latest-stories.html">
    <a href="/politics">Politics</a>
</li>

I thought this a great example of progressive enhancement. If javascript is available on the client, it fetches that document fragment and appends it in context.

For what it’s worth, the plugin appears to have a good API which allows additional options such as conditionally loading the content based on a media query, i.e. data-media="(min-width:500px)".

A/B Testing

This is the reason we A/B test in the first place, because the findings of others...are all unproven until they've been tested against our customers, on our platform.

That’s Ethan quoting Michel Ferreria talking about how A/B tests results can be useful but you've got to remember to weigh them against your own user base. So often it feels like A/B test results from another product are improperly used to justify decisions in your own product. Obviously people on your team are not trying sabotage your product. We all just have biases and try to use data to back up our bias. We make the results fit our desired outcome.

I think it’s good to remember (and point out where necessary) that A/B tests from others are performed under conditions unique to them, conditions that often will not mirror those of your own product. You wouldn’t take the results of a research project in Antartica which prove it’s cold outside to mean everyone in desert in Phoenix should buy a coat. They are different circumstances, different conditions. By all means, weigh the data from an A/B test against your own user base and product and make use of the work of others. Just remember data isn’t fact just because its data.

The <img> tag and max-width: 100%

One of the supposed downsides of simply setting max-width: 100% on all <img> elements is that some images don’t scale down nicely. For example, let’s say you have a 1200x1200 pixel infographic. At full resolution the type is set at 16 pixels. That means when the infographic’s <img> element is responsively scaled down on a mobile device to a width of say 300x300 pixels, the text on that graphic is going to be completely illegible.

Now, from a technological standpoint, some people may argue that what you need are tools, tools, tools! Design the infographic in three different sizes, crop it for seven different media queries, and output fifteen different versions of one image in order to account for sizing, pixel density, etc. Then serve all those different images using the <picture> element with a javascript polyfill (or some other cutting edge feature).

Now you could well go and do that. And there are cases when I’m sure that is proper. But I’d like to also suggest another solution: just wrap the <img> element in an <a> tag. That’s it. If the image gets resized to a small viewport, that’s ok. If the user needs to see the full-sized image, they can simply click on it and then use their native hardware’s pan/zoom tools. Sure some might argue that this solution isn’t as optimal as the other scenario, but it’s just as accessible (one could argue possibly more-so). A simple link can be quite effective because hey, that’s how the web was designed to work: link to resources on computers. I’ll be a web page designed today with <a><img></a> will still work in twenty years on a web-accessible device. While a hundreds-of-lines polyfill in javascript designed to fetch and serve one of twenty different images may not.

Mobile Desktop First

One of the reasons I often start my designs at 960px and then design more narrow screens as I go is aptly described by the guys who did the Boston Globe website, as quoted by Ethan in this book:

Ours designs began at 960px, arguably the most complicated breakpoint, with several columns of content. Maybe this just came naturally after years of designing for that width. But I think it’s more than that. It’s easier to design with more screen real-estate — you see more at one time, you have a more nuanced hierarchy ... So starting at 960, we designed downward. Every decision informed the one before it and the one after; we flipped back and forth between break points a lot. As the Mobile First mantra suggest, designing for mobile was most instructive because it forced us to decide what was most important. And since we refused to hide content between break points, the mobile view could send us flying back up to the top level to remove complexity. The process felt a bit like sculpting.

I think that’s an apt justification for how I’ve arrived at my current process for responsive design. Start at 960px and get a good grasp for content relationships, patterns, and hierarchy. As you transitions those responsive modules down to mobile break points, things often break and you discover better solutions for content relationship, UI patterns, and element hierarchy. This sends you back up to 960 pixels where, often, you end up solving problems that were slightly nagging you in the first place. That moving up and down the viewport spectrum and seeing how things flow down to smaller break points helps me arrive at the designs I want without starting “mobile first”.

Final Points

In writing about the need for effective language around responsive design, Ethan writes:

We need a design language that’s as nimble and modular as our layout systems are becoming.

This describes one of the points I felt Ethan was trying to hammer home throughout this book. He wasn’t just writing a tutorial-style book on “how-to responsive design”. To me, at a higher level this book was a suggestion to change the way we think and talk about responsive design rather than the way we implement it. Talking about process and methodology is always harder than technical implementation, often because there is no language for doing it. We haven’t really come up with a really concise vocabulary for responsive web design yet, at least that’s what Ethan suggests in this book. That, more than any particular technical tip or trick, will help propel us to more effective web designs. As the author Jan Swafford once stated, “To discover new means of expression is to discover new territories of the human”.


Reading Notes, July 2016

Article The Law of Leaky Abstractions

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.” Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning.

This is the problem computers present to us in general, not just in coding. They abstract tasks for us. Even something as simple as a spell checker. If you grow up never really learning to spell but always relying on a spell checker (or autocorrect), you'll never be able to write without the assistance of a computer. The computer has become a crutch. As the author stated, abstractions and automation can help you save time doing but they cannot help you save time learning.

Article Holistic Management

An interesting insight into the idea of “holistic management”, where you look at how decision made for and in-behalf of your team will ripple through and affect your larger organization:

Just like we ask designers, engineers and PMs to consider the entire system when designing and building their slice of it, we should also ask the same of ourselves as managers.

Article Mixins Better for Performance

Interesting look at performance difference between mixin and extend in sass. I found this particular point refreshing:

Y’see, when people talk about the performance of mixins, they’re usually thinking about filesize on the filesystem. But because we have gzip enabled (you do have gzip enabled, right?), we should be thinking about filesize over the network.

I often forget this fact. As the Harry Roberts, the author, goes on to show in the article: filesize on the filesystem is one thing and filesize gzipped can often be something else entirely. In his example, File1 was 150% larger than File2 upon compilation, but after gzipping, File1 as 33% smaller than File2.

Article The Year In Design by Zeldman

90 percent of design is typography. And the other 90 percent is whitespace. Style is the servant of brand and content. Style without purpose is noise.

Rediscovering this with the renewed interest in speed, basic page structure semantics, JavaScript fatigue, etc.

One illustration or original photo beats 100 stock images.

With the ubiquity of people being online, they see everything across the Internet (especially the younger generation) so if you’re not unique, they’ll notice. If you’re bland, they’ll notice

Nobody waits. Speed is to today’s design what ornament was to yesterday’s.

This is an interesting observation. I feel like it puts into words this nagging feeling I’ve had the last few months: speed is design. On the web, speed is just as much a part of the design as the grid or typography. In many cases, I think some people would prefer the speed and simplicity of vanilla HTML markup over giant JavaScript apps when all they need to see or read is a few dozen lines of text.


Reading Notes, December 2015

Article: Helpful Talk Tips by Paul Ford

By no means do I consider myself a public speaker. However, in the limited experience I have speaking to groups, these tips seem relevant to public speaking.

First: do you ever wonder why most talks begin with a joke or story? Here’s why:

I’m finding that it’s very important to just get up there and talk a little bit, make some dumb jokes, let people get used to you existing.

Second: it’s generally a good idea to get rid of slides and notes and just have statements that you can respond to, then it feels conversational as opposed to dictated:

I've thrown away most of the slides with bullets, and I’ve thrown away all of my slide notes. Notes are terrible and half the time you can’t see them anyway. Then, what I try to do is make every slide a little statement, and respond to it...By throwing together statistics and pictures and quotes, it looks like I’m giving a talk, but what’s really happening is that I’m having a conversation with myself. The slides are saying things to me and I’m responding.

Article: Valet Apps Are Silicon Valley Entitlement at Its Silliest

Apparently, on-demand valet parking services are springing up in Silicon Valley as a thing — it’s like the Uber of parking. You drive your car, pull out the app, and summon a valet who will park your car in a secure lot and retrieve it whenever you want (for a small fee of course).

The author of the article makes this observation, which I can’t help but agree with wholeheartedly:

In our oversaturated world of on-demand anything, the emergence of insta-valet services is, sadly, not shocking. We want everything to be cheap and easy … but at what point does our obsession with convenience go from maximizing efficiency to optimizing laziness?

That last line so perfectly sums up so many of the venture-backed startups I’ve seen: “at what point does our obsession with convenience go from maximizing efficiency to optimizing laziness?”. Why does it seem like almost every new consumer app/service merely panders to our indolence?

Article: Brighton, England: The San Francisco of Silicon Valley's dreams

An interesting look at the tech culture differences between Brighton, England, and San Fran, California, centered around the person of Jeremy Keith:

[Keith said about Brighton] “It’s not the classic startup obsession with a quick-buck IPO tunnel vision. It’s more about long-term happiness. Nobody’s going to work too hard if working too hard means giving up fun, giving up life. Or else what is all this technology for?”

Book: A Designer's Art by Paul Rand

An interesting look at the root meaning of the word “art” and its relationship to design:

We know that where we perceive no patters of relationship, no design, we discover no meaning … The reason apparently unrelated things become interesting when we start fitting them together … is that the mind’s characteristic employment is the discovery of meaning, the discovery of design … The search for design, indeed, underlies all arts and all sciences … the root meaning of the word art is, significantly enough, ‘to join, to fit together’ — John Kouwenhoven, as quoted in “A Designer’s Art” by Paul Rand (xiii)

The essence of graphic design:

Graphic design is essentially about visual relationships–providing meaning to a mass of unrelated needs, ideas, words, and pictures. It is the designer’s job to select and fit this material together–and make it interesting.

On the process graphic design, and why respect for the individual and his/her process is absolutely necessary (LOVE THIS!!):

The separation of form and function, of concept and execution, is not likely to produce objects of aesthetic value … any system that sees aesthetics as irrelevant, that separates the artist from his product, that fragments the work of the individual, or creates by committee, or makes mincemeat of the creative process will in the long run diminish not only the product but the maker as well.

A statement on the process of design, the first part always being that the designer must break down before he can build up:

Design starts with three classes of material:

  1. The given - product, copy, slogan, logotype, format, media production process.
  2. The formal - space, contrast, proportion, harmony, rhythm, repetition, line, mass, shape, color, weight, volume, value, texture.
  3. The psychological - visual perception, optical illusion problems, the spectator's instincts, intuitions, and emotions (as well as the designer's own needs).
    As the material furnished him is often inadequate, vague, uninteresting or otherwise unsuitable for visual interpretation, the designer's task is to restate the problem. This may involve discarding or revising much of the given material. By analysis (breaking down of the complex material into its simplest components - the how, why, when and where) the designer is able to begin to state the problem

Lastly, the job of artist (and by extension a good graphic designer) is to call attention to the ordinary, to make people stop and reconsider what they believe they already understand:

[designers should practice] the fine art of exhibiting the obvious in [the] unexpected...The problem of the artist is to defamiliarize the ordinary.


Reading Notes, November 2015

Article: Mind Set by Jeremy Keith

A great little piece of writing touching on the art of human relationships. It’s based on an experience Jeremy Keith had trying to persuade others about the importance accessibility:

If I really want to change someone’s mind, then I need to make the effort to first understand their mind. That’s going to be far more productive than declaring that my own mind is made up. After all, if I show no willingness to consider alternative viewpoints, why should they?

Talk: Haunted by Data

A very on-point lecture on the limitations and danger of the our digital mentality “collect everything and maybe we will use it later”.

One example the speaker touches on is the pharmaceuticals industry and how, because of the “big data” philosophy they bought into, they are now at a point of diminishing financial returns in new drug development:

This has been a bitter pill to swallow for the pharmacological industry. They bought in to the idea of big data very early on. The growing fear is that the data-driven approach is inherently a poor fit for life science. In the world of computers, we learn to avoid certain kinds of complexity, because they make our systems impossible to reason about.

Note that the speaker suggests that the diminishing returns result from the fact that computers need unambiguous rules in order to make sense of things. Thus, in order to create data models and make sense of the world, programmers have to throw out “certain kinds of complexity” which are inherently and naturally found in the realm of biological science. As the speaker states later on, “Nature is full of self-modifying, interlocking systems, with interdependent variables you can't isolate.”

Ultimately, what we are dealing with in our computer systems are humans and humans adapt. That means when you create a data model around a person, the model inevitably goes out the window because a person adapts and changes, not just naturally over time, but they also react and change according to the model that is enforced on them.

An example of how humans adapt to numerical requirements, as drawn from this transcript, is found in the anecdotal story of a nail factory. Once their was a nail factory. In the first year of their five year plan, the nail factory’s management evaluated employees by how many mails they could produce. As such, employees produced hundreds of millions of uselessly tiny nails. Seeing their mistakes, management changed their productions goals to measure nail weight rather than nail quantity. As a result, employees produced a single giant nail.

Perhaps this story seems unreal, but the speaker provides a less fictitious example of how humans adapt to the systems imposed on them and how that ultimately renders the collected data useless:

[An] example is electronic logging devices on trucks. These are intended to limit the hours people drive, but what do you do if you're caught ten miles from a motel? The device logs only once a minute, so if you accelerate to 45 mph, and then make sure to slow down under the 10 mph threshold right at the minute mark, you can go as far as you want. So we have these tired truckers staring at their phones, bunny-hopping down the freeway late at night. Of course there's an obvious technical countermeasure. You can start measuring once a second. Notice what you're doing, though. Now you're in an adversarial arms race with another human being that has nothing to do with measurement. It's become an issue of control, agency and power. You thought observing the driver’s behavior would get you closer to reality, but instead you've put another layer between you and what's really going on. These kinds of arms races are a symptom of data disease. We've seen them reach the point of absurdity in the online advertising industry, which unfortunately is also the economic cornerstone of the web. Advertisers have built a huge surveillance apparatus in the dream of perfect knowledge, only to find themselves in a hall of mirrors, where they can't tell who is real and who is fake.

Talk: The Internet With A Human Face

Love this assertion the speaker makes: very often data is just a mirror, it reflects whatever assumptions we bring to it.

The belief in Big Data turns out to be true, although in an unexpected way. If you collect enough data, you really can find anything you want.

big data

This is a graph from Tyler Vingen's lovely website, which been making the rounds lately. This one shows the relationship between suicides by hanging and the number of lawyers in North Carolina. There are lots of other examples to choose from. There's a 0.993 correlation here. You could publish it in an academic journal! Perhaps that process could be automated. You can even imagine stories that could account for that bump in the middle of the graph. Maybe there was a rope shortage for a few weeks? 'Big data' has this intoxicating effect. We start collecting it out of fear, but then it seduces us into thinking that it will give us power. In the end, it's just a mirror, reflecting whatever assumptions we approach it with. But collecting it drives this dynamic of relentless surveillance.

Article: Five Years of Building Instagram

An overview of how Instagram has been engineered over the last five years. A few points stuck out to me.

Choose simple solutions and do not over engineer in order to future proof:

Our mantra, “Do the simple thing first” ... Since there were only two of us, we had to determine the fastest, simplest fix each time we faced a new challenge. If we had tried to future-proof everything we did, we might have been paralyzed by inaction. By determining the most important problems to solve, and choosing the simplest solution, we were able to support our exponential growth.

It takes an incredible amount of focus to do this, but

we often say “do fewer things better” inside Instagram

However, with that said, the author does state that this is not the answer all the time for everyone:

Doing the simple thing first doesn’t mean your solution will work forever. We’ve learned to be open to evolving our product...

Video: Building Without Nails: the Genius of Japanese Carpentry

Just a cool video about craftsmanship. I love how the philosophy behind the craftsmanship is what drives the work forward, not the data behind the product.


Reading Notes, September 2015

Video: The Sound Design Behind Interstellar

As far as what I hope the audience thinks of the sound, I would hope that they think the sound was all shot on the days they shot the movie and that it’s all there. — Richard King, Supervising Sound Editor & Sound Designer Interstellar

I found it interesting how the ultimate goal of the sound team was to have the audience not even notice their work. After all the extremes they went to — the airplane graveyard, the ice shoes, the sand blaster — they wanted their work to go unnoticed by the audience and instead have them simply assume it was all a product of the original film shoot.

I find such an interesting parallel to this in visual design: good, simple design is the obvious choice. So obvious, in fact, that people don’t even notice it. They just naturally assume “how could it be any other way?”

Reminds me of this quote, from the book The Inmates are Running the Asylum (which, if you haven’t read it, is great):

If, as a designer, you do something really, fundamentally, blockbuster correct, everybody looks at it and says, “Of course! What other way would there be?” This is true even if the client has been staring, empty-handed and idea0-free, at the problem for months or even years without a clue about solving it. It’s also true even if our solution generates millions of dollars for the company. most really breakthrough conceptual advances are opaque in foresight and transparent in hindsight. It is incredibly hard to see breakthroughs in design. you can be trained and prepared, spend hours studying the problem, and still not see the answer. Then someone else comes along and points out a key insight, and the vision clicks into place with tentacular obviousness of the wheel. If you shout the solution from the rooftops, others will say, “of course the wheel is round! What other shape could it possibly be?” This makes it frustratingly hard to show off good design work. — pg. 200

This is inline with what Alan Dye, Vice President of User Interface Design at Apple, said about Apple’s design goals:

Inevitable is the word we use a lot. We want the way you use our products to feel inevitable.

The goal is to make it seem as if the designers at Apple can’t even control the form and function of their products because the end goal is so natural and logical, i.e. inevitable.

Article: Miyazaki on Creative Dissatisfaction

Hay Miyazaki, a famous Japanese animation director who created classics such as Spirited Away and Princess Mononoke, described an aspect of his creative process that pinpoints how many of us feel in technology:

Making films is all about—as soon as you’re finished—continually regretting what you’ve done. When we look at films we’ve made, all we can see are the flaws; we can’t even watch them in a normal way. I never feel like watching my own films again. So unless I start working on a new one, I’ll never be free from the curse of the last one. I’m serious. Unless I start working on the next film, the last one will be a drag on me for another two or three years.

Article: The process of design

This was written back when iOS 7 was first introduced to the world. I read it then and made this note. In the years since, I’ve always done a “spring cleaning” of my notes and this one always persisted. I think Frank captures perfectly a description of my job the last three years.

Every time I read this quote, it feels more and more relevant. Likely because “Experience gives a person the eyes to imagine their small choices in aggregate.”

Part of being a good designer is having a hatred for inconsistencies, so I take the interface’s unevenness to mean a hurried timeline, rather than an unawareness of the inconsistencies. Working on multiple screens, apps, and userflows means that certain aspects of the whole system will fall out of sync with each other as the later parts’ lessons override previous choices. The last step of most design processes is to take the lessons learned along the way and apply those best practices to the niggling incongruencies that have inevitably sprung up. This last step usually gets cut under tight deadlines, because the work is technically “done,” but just not “right.” Unfortunately, this kind of consistency is usually seen as a design indulgence that can be postponed. “We’ll iterate,” designers are usually told, but everyone knows you loose a bit of the luster of a tight first impression.

Video: Interview with Jackson Browne

Jackson Browne, an American singer-songwriter who’s been inducted into the Rock-n-Roll hall of fame, did an interview around his newest album Standing in the Breach and revealed a few nuggets about the creative process of making his album which I found relevant to any kind of creative process in general.

One of the first questions the host asked was if he had a personal favorite track on his record. He responded:

No I like them all. Each one of them, at one time or another, has been my favorite song. That’s what it takes to finish them, they have to be something I’m really interested in...[my] songs aren’t always finished when I start recording them. I may just rewrite a verse, or I may actually take something out. It’s a process of exploring. I want to know what the song is capable of doing musically before I finish the subject in terms of lyrics. Nothing’s worse that writing too many verses and having to throw some out. You know, if you find out you don’t really want to hear two verses before the chorus but you’ve already setup the narrative. That’s happened a couple times, where I songs just on the acoustic guitar but when I started to play it with a band I realized “I don’t want to hear another verse, I want to [go right into the chorus]”. I’m always rewriting but I don’t like to throw things away.

That last sentence of his is great: always rewriting, refining, simplifying, making better, making more concise yet impactful and deep. Great stuff.

Later in the interview he talks about his relationship with his album producer how well they work together and compliment one another:

We’re a perfect match because he’s a good engineer but he’s got infinite patience. I’m a neophite, in a recording I’m not technical at all, so I need someone to sit there with me while I think about what I want to think about and who doesn’t engage me with what he wants to do, but just does what he wants to do. Some engineers are ambitious and want to talk about what they want to do, “I’m going to do this, I’m going to do that, can we do this?”. I need somebody that’s much more...patient. Someone who’s almost passive and who will allow me to move things around and turn the balances upside down. And things may remain out of balance for long periods of time and then [i’ll bring them back]...In a funny way, we’re bystanders to each others’ work.

I love this idea he expresses about allowing yourself (and having your producer, co-worker, boss, etc. allow you) to put things out of order to discover possibilities so when you arrive at the final product, you know there’s no other way the thing could be because you’ve explored all possible permutations.

In this same vein of continually exploring possibilities, the host asks if it’s hard for him to release songs because, at that point, the song would officially be considered “finished”:

It’s a bit of an acquired skill to know when a song is done because it’s very easy to keep going and keep adding things because it’s interesting, it’s fun. In a way you’re never done. The song is going to continue to grow after the album too, you just have to know how far you can go with this particular recording.

At the end of the interview, the host opens the discussion to questions from the audience. A guest in the crowd asked him how he remembers and tracks his half-baked ideas. He answers by talking about how he keeps track of snippets on his iPhone which helps him a lot because sometimes he remembers the idea of a song better than it actually was, like “oh yeah I was working on this thing that was really great” and then he’ll look up the snippet on his phone and realize “oh wow, that actually wasn’t very good” but that bad idea can spur other good ideas:

Most of my ideas come from mistakes that interest me...I could disappear into my music room with some of my recordings and make a bunch of songs out of the boxes and boxes of my recordings because each of them represents a moment when I thought I was doing something of value or interesting.

Love that first sentence: “most of my ideas come from mistakes that interest me”. That’s why you shouldn’t be afraid of anything you’ve done in the past. It’s all experiential fodder for good things in the future.

Article: Can Technology Be Humane?

What’s so interesting to me about this article is that it was written in 1969. It’s one of the timeless articles where you think, “man how did the author so accurately foresee the future?”

This passage encapsulates how I increasingly feel seeing the results of tech announcement events, where companies tout their innovative, revolutionary products which will solve all your problems. But underneath, these solutions are merely more technology presented as the solution to the problems caused by our current technology.

The recent history of technology has consisted largely of a desperate effort to remedy situations caused by previous over-application of technology ... Every advanced country is over-technologized; past a certain point, the quality of life diminishes with new “improvements.” Yet no country is rightly technologized, making efficient use of available techniques. There are ingenious devices for unimportant functions, stressful mazes for essential functions, and drastic dislocation when anything goes wrong, which happens with increasing frequency. To add to the complexity, the mass of people tend to become incompetent and dependent on repairmen—indeed, unrepairability except by experts has become a desideratum of industrial design.

“Technology is causing problems, so let’s throw more technology at the problem.” I believe this quite acutely applies to our current trend in technological innovation. It’s this idea we are wrestling of treating the symptoms rather than finding a cure:

It is discouraging to see the concern about beautifying a highway and banning billboards, and about the cosmetic appearance of the cars, when there is no regard for the ugliness of bumper-to-bumper traffic and the suffering of the drivers. Or the concern for preserving an historical landmark while the neighborhood is torn up and the city has no shape. Without moral philosophy, people have nothing but sentiments.

The author also touches on technological automation (emphasis added):

In automating there is an analogous dilemma of how to cope with masses of people and get economies of scale, without losing the individual at great consequent human and economic cost. A question of immense importance for the immediate future is, Which functions should be automated or organized to use business machines, and which should not? This question also is not getting asked, and the present disposition is that the sky is the limit for extraction, refining, manufacturing, processing, packaging, transportation, clerical work, ticketing, transactions, information retrieval, recruitment, middle management, evaluation, diagnosis, instruction, and even research and invention. Whether the machines can do all these kinds of jobs and more is partly an empirical question, but it also partly depends on what is meant by doing a job. Very often, e.g., in college admissions, machines are acquired for putative economies (which do not eventuate); but the true reason is that an overgrown and overcentralized organization cannot be administered without them. The technology conceals the essential trouble, e.g., that there is no community of scholars and students are treated like things. The function is badly performed, and finally the system breaks down anyway. I doubt that enterprises in which interpersonal relations are important are suited to much programming.

But worse, what can happen is that the real function of the enterprise is subtly altered so that it is suitable for the mechanical system. (E.g., “information retrieval” is taken as an adequate replacement for critical scholarship.) Incommensurable factors, individual differences, the local context, the weighting of evidence are quietly overlooked though they may be of the essence. The system, with its subtly transformed purposes, seems to run very smoothly; it is productive, and it is more and more out of line with the nature of things and the real problems. Meantime it is geared in with other enterprises of society e.g., major public policy may depend on welfare or unemployment statistics which, as they are tabulated, are blind to the actual lives of poor families. In such a case, the particular system may not break down, the whole society may explode.

In our haste to see what computers are capable of, we so often misconstrue how well they are actually doing the job we’ve handed off to them:

It is so astonishing that the robot can do the job at all or seem to do it, that it is easy to blink at the fact that he is doing it badly or isn’t really doing quite that job.

When a task is done by a computer rather than a human, its significance and holistic effect are not the same, though we often convince ourselves otherwise.


Reading Notes, August 2015

Book: The Complete Far Side Vol 1

Gary Larsen, creator of The Far Side comic strip, in the preface to his complete comic book anthology:

It's been almost seven years since I hung up my eraser. (For the record, an eraser was the most essential tool I owned.)

Earlier in the introduction, his newspaper editor talked about how fastidious Gary was in writing the captions for his comic strips. He made this observation, which for anyone familiar with The Far Side rings true:

good writing can save bad art, but good art can never save bad writing.

Article: “Stop Pushing the Web Forward”

An interesting read on the state of the web and how, just maybe, we should ponder slowing down for one second to consider the direction we’re headed in and contrast that with where and what we want the web to be. Of course to suggest “slowing down” is technological blasphemy. So the author correctly prefaces his article with “Fair warning. You’re going to hate this one.”

Here are a few passages I enjoyed, in no particular order:

Recently I’ve been having serious doubts about the whole push the web forward thing. Why should we push the web forward? And forward to what, exactly? Do we want the web to be at whatever we push it forward to? You never hear those questions.

Pushing the web forward currently means cramming in more copies of native functionality at breakneck speed — interesting stuff, mind you, but there’s just too much of it.

Native apps will always be much better at native than a browser. Instead, we should focus on the web’s strengths: simplicity, URLs and reach.

But why do web developers want navigation transitions? In order to emulate native apps, of course. To me, that’s not good enough.

We’re pushing the web forward to emulate native more and more, but we can’t out-native native. We are weighed down by the millstone of an ever-expanding set of tools that polyfill everything we don’t understand — and that’s most of a browser’s features nowadays. This is not the future that I want to push the web forward to.

Website: “Computer Jargon”

A coworker showed me this resource around computer jargon — a hacker’s lexicon if you will (apparently it’s the online version of The New Hacker’s Dictionary).There are some funny terms in there. If you work in technology, you’ll probably enjoy these.

Here are a few I enjoyed:

ambimouseterous:

Able to use a mouse with either hand.

disemvowel :

To partially obscure a potentially provocative word by substituting splat characters () for some of its letters (usually, but not always, the vowels). The purpose is not to make the word unrecognizable but to make it a mention rather than a use, so that no flamewar ensues. [Example: “gn cntrl”]

job security:

When some piece of code is written in a particularly obscure fashion, and no good reason (such as time or space optimization) can be discovered, it is often said that the programmer was attempting to increase his job security (i.e., by making himself indispensable for maintenance). This sour joke seldom has to be said in full; if two hackers are looking over some code together and one points at a section and says “job security”, the other one may just nod.

goat file:

A sacrificial file used to test a computer virus, i.e. a dummy executable that carries a sample of the virus, isolated so it can be studied. Not common among hackers, since the Unix systems most use basically don't get viruses.

Ninety-nine rule:

“The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.” ... Other maxims in the same vein include the law attributed to the early British computer scientist Douglas Hartree: “The time from now until the completion of the project tends to become constant.”

Article: “Can Computers Improvise?”

Because, apparently, there’s so little to talk about anymore, it’s been announced that a computer has written lyrics that rival rap legend Eminem. As such, some have even claimed “rappers might soon lose their jobs to robots”. But as Nicholas Carr points out, that’s a little premature:

Our assumptions and expectations about artificial intelligence have gotten ahead of the reality, in a way that is distorting our view not only of the future but of the very real accomplishments being made in the AI and robotics fields.

Personally, I find this especially true for computer illiterate people. My dad constantly sees “news” headlines making outlandish claims for AI and therefore has this sense that the robot rapture will soon be upon us.

As someone who works in tech, I find it laughable, borderline ridiculous that as soon as computers do the tiniest little thing “we jump to the conclusion that computers are mastering wordplay and, by implication, encroaching on the human facility for creativity and improvisation”.

Article: “Programming Sucks”

Fairly recently, Paul Ford wrote a piece called What is Code? where he tried to explain programming. This is another piece that takes a different (shall we say realistic) view of programming. If Ford’s article is seeing programming as a cup half-full, this article is seeing programming as a cup half-empty. Both are true, it's just a matter of view point (or current mood).

Firstly programming is hard. Even if you know lots of programming languages that doesn't mean you will understand an application written in any particular language you know.

The first few weeks of any job are just figuring out how a program works even if you’re familiar with every single language, framework, and standard that's involved...

The average life of a programmer on the web, remembering that a programmer is such a wide-reaching term (emphasis added):

Say you're an average web developer. You're familiar with a dozen programming languages, tons of helpful libraries, standards, protocols, what have you. You still have to learn more at the rate of about one a week, and remember to check the hundreds of things you know to see if they’ve been updated or broken and make sure they all still work together and that nobody fixed the bug in one of them that you exploited to do something you thought was really clever one weekend... You're all up to date, so that’s cool, then everything breaks....You are an expert in all these technologies, and that's a good thing, because that expertise let you spend only six hours figuring out what went wrong, as opposed to losing your job...And that’s just in your own chosen field, which represents such a tiny fraction of all the things there are to know in computer science you might as well never have learned anything at all. Not a single living person knows how everything in your five-year-old MacBook actually works.

The internet is really just being held together by duct tape and glue:

Websites that are glorified shopping carts with maybe three dynamic pages are maintained by teams of people around the clock, because the truth is everything is breaking all the time, everywhere, for everyone. Right now someone who works for Facebook is getting tens of thousands of error messages and frantically trying to find the problem before the whole charade collapses. There’s a team at a Google office that hasn’t slept in three days. Somewhere there’s a database programmer surrounded by empty Mountain Dew bottles whose husband thinks she’s dead. And if these people stop, the world burns. Most people don’t even know what sysadmins do, but trust me, if they all took a lunch break at the same time they wouldn’t make it to the deli before you ran out of bullets protecting your canned goods from roving bands of mutants … You can't restart the internet. Trillions of dollars depend on a rickety cobweb of unofficial agreements and “good enough for now” code with comments like “TODO: FIX THIS IT’S A REALLY DANGEROUS HACK BUT I DON’T KNOW WHAT'S WRONG” that were written ten years ago. I haven't even mentioned the legions of people attacking various parts of the internet for espionage and profit or because they’re bored.


Reading Notes, November 2012

Article: “The Flight From Conversation”

Article of interesting observations written by Sherry Turkel at the New York Times. It details, among other things, how we have "sacrificed conversation for mere connection".

Curating our digital selves

Interesting parallel of the digital world to the real world of advertising in which, as we all know, famous faces on magazines are never quite as they appear:

Texting and e-mail and posting let us present the self we want to be. This means we can edit. And if we wish to, we can delete. Or retouch: the voice, the flesh, the face, the body. Not too much, not too little — just right.

True self reflection requires trust

Why it's so hard to find (or post) anything of deep import amongst in the world of social statuses:

These days, social media continually asks us what’s “on our mind,” but we have little motivation to say something truly self-reflective. Self-reflection in conversation requires trust. It’s hard to do anything with 3,000 Facebook friends except connect.

We expect more from tech and less from each other

We expect more from technology and less from one another and seem increasingly drawn to technologies that provide the illusion of companionship without the demands of relationship. Always-on/always-on-you devices provide three powerful fantasies: that we will always be heard; that we can put our attention wherever we want it to be; and that we never have to be alone.

Sharing proves existence, a la Shakespeare

I share, therefore I am.

Unfortunately, our internet culture has led many to believe that if they don't share online they will be left out. They'll be forgotten. They'll cease to exist socially.

On a related note - Paul Miller, a journalist at The Verge, has made some interesting observations about our innate desire to not miss out. He observes that, when we 'miss out' on one thing (the internet), we get to spend our attention on something else (perhaps of greater import).

Ode to a time long gone

Not too long ago, people walked with their heads up, looking at the water, the sky, the sand and at one another, talking. Now they often walk with their heads down, typing. Even when they are with friends, partners, [and] children

Article: “Dear Business, I'm scared for you”

This article by Brian Hoff at The Design Cubicle is probably the best post describing the web design field I've read in a while.

Businesses will spend $40,000 a year on an employee who works eight to five, five days a week. However, for lack of education they won't spend $1,000 on their hardest-working employee: their website. It works 24 hours a day, 365 days a year and interfaces with more clients than any other employee (perhaps even all their employees combined).

Your website is not a feature that you can half-ass. Spend some money. Protect your future. A good website works hard for your business. Much harder than many employees can offer.

Article: “Creating a Thriving Developer Culture”

I've worked at Arc90 (and technically still do) and I can verify Alex's observations. There truly is a thriving developer culture at Arc that exists because of the company traits he points out.

When your employee gets up in the morning, you want the most exciting thing in her day to be related to your company ... When your employee discovers something cool, you want their second thought to be “how can I use this at work?”.