At no point are these men actually providing leadership. They’re just in the leader class…

Kind of an interesting distinction: there are leaders who provide leadership, and there are leaders who are in the leadership class but do nothing of the sort.

Also, I loved this anecdote from somebody who works in the film industry:

“You get [executive] producers that say, ‘I want to be involved in the artistic process,’ and you’re like—I don’t ask to look at your spreadsheets, man.”

People are like fields: you gotta intentionally let them lie empty producing absolutely nothing for a little while:

You see, one of the most important things, which is true of both plants and people, is that you’ve got to let them lie fallow for a while. A field cannot support the same crop forever. You must intentionally let the field lie empty, producing nothing…

People are the exact same way.

Google has 175,000+ capable and well-compensated employees who get very little done quarter over quarter, year over year. Like mice, they are trapped in a maze of approvals, launch processes, legal reviews, performance reviews, exec reviews, documents, meetings, bug reports, triage, OKRs, H1 plans followed by H2 plans, all-hands summits, and inevitable reorgs.

If there’s one thing that drives me nuts, it’s spending time doing work that’s not the work. It’s cray-cray to me that orgs spends weeks on these review cycles and it’s just accepted, like “It’s performance review season, everything’s on hold.”

very few Googlers come into work thinking they serve a customer or user. They usually serve some process (“I’m responsible for reviewing privacy design”) or some technology (“I keep the CI/CD system working”). They serve their manager or their VP. They serve other employees. They will even serve some general Google technical or religious beliefs (“I am a code readability expert”, “I maintain the SWE ladder description document”). This is a closed world where almost everyone is working only for other Googlers, and the feedback loop is based on what your colleagues and managers think of your work.

Why does it seem like a radical idea now-a-days to say: when I search for something the first result should be the thing that most closely matches what I searched for.

Here’s something I think we should all agree upon: when a willing speaker wants to say something to a willing listener, our technology should be designed to make a best effort to deliver the speaker’s message to the person who asked to get it.

I hope this is self-evidently true. When you dial a phone number, the phone company’s job is to connect you to that number, not to someone else. When you call Tony’s Pizza, you expect to be connected to Tony’s Pizza — not to Domino’s, not even if Domino’s is willing to pay for the privilege…

If you follow someone on social media, then the things that person says should show up in your timeline.

That is not a radical proposition, but it is also not the case today. Facebook, Twitter, TikTok, YouTube and other dominant social media platforms treat the list of people we follow as suggestions, not commands .

This is why I love RSS: if I subscribe to something, it will show up in my feed. End of story.

one of Brian Eno’s Oblique Strategies has it: “Be the first person to not do something that no one else has ever thought of not doing before.”

Like most people, my head is full of thoughts and stuff I have opinions on. I conduct enthusiastic debates in my head, and internally anyway, I’m always super convincing, right?

But when I sit down to write a blog post about something — that’s when I have to figure out what I really think, and what I really know, about a subject.

To feed my blogging, I am constantly reading books, magazine articles, academic papers, and a sprawling network of blogs…Much as writing catalyzes thinking, reading catalyzes writing; the vast majority of ideas I get for blog posts come from reading

Love that line: "Writing catalyzes thinking, reading catalyzes writing.” Next time somebody asks, “How do you blog so much or know what to write about?” One answer will be: “I read a lot.” Who doesn’t have thoughts after reading?! Write them down next time.

Design Thinking education willfully ignores these complexities, preferring to wrap Design into a digestible package, and in so doing establishing it as a simple, reproducible and processional endeavor. This approach dramatically simplifies the highly complex, nuanced, non-linear reality of Design to a grotesque degree.

Spicy! There’s more:

Given the genesis of Design Thinking — emerging as it did from the bowels of international consulting firm IDEO — it’s perhaps no coincidence that these five tidy phases closely mirror the ‘phase billing’ techniques employed by Design consultancies. Each portion of a project proceeds conveniently along pre-agreed paths, with pre-agreed outcomes on pre-agreed schedules. Real Design work is complex, chaotic and messy, Design Thinking is linear, simplistic and procedural.

Maybe too good, too neat, to be true?

The seamless stepping from one phase to the next, wrapping up neatly with a ‘thing to be made’ is disconcerting and reductive, and (as mentioned in my first critique) reflects a phase-billing attitude common in client services industries. Like ‘Agile’, or ‘Scrum’ or any other product development tool, Design Thinking offers some basic organizational logic to a process, but it implies a level of closure which isn’t present in reality. It’s a fallacy of rapidity, of repeatability, of clean outputs and finite solutions.

I always enjoy these kinds of takes—“things I’ve learned over two decades of doing this”.

Pick the right tool for the job or you’ll have to find the right job for the tool you got.

Respect people more than code.

Don’t attach your identity to your code. Don’t attach anyone’s identity to their code. Realize that people are separate from the artifacts they produce.

Don’t do speculative programming. Only make the code extensible if it is a validated assumption that it’ll be extended. Chances are by the time it gets extended, the problem definition looks different from when you wrote the code.

According to Google’s first UX writer, Sue Factor, one of the main reasons why Google decided to go with sentence case was because it was just easier to explain to designers and engineers. In a product interface, it’s not always clear what’s considered a “title.” Is a tab name a title? How about a settings checkbox? Or a confirmation message?

A great breakdown of title vs. sentence case. I have to admit, after reading it, I’m becoming a believer in sentence-casing all the things. My brain is already thinking about how I’d do this on my blog—say, a regex to find/replace title casing on all post titles going back a decade? Must…resist…urge…

The history of the office workspace:

First, bosses got rid of private offices. That dramatically reduced how many surfaces you had control over: Cubicles give you far less space to arrange things as you’d prefer. Then open-offices came along and made things even more miserable, because they destroyed even the vestigial bits of privacy we had with cubicles — as well as the meagre (but still useful) cubicle wall-space you’d use to organize info. And of course, open offices also meant more noise distractions and more interruptions, which were, as [a researcher] argues, possibly the worst blow of all to our thought: “Perhaps the most important form of control over one’s space is authority over who comes in and out.”

The research around gaining control of your office space and environment is telling:

being able to organize your workspace makes you nearly one-third more productive than when you can’t.…as [the author of the experiment said] “three people working in empowered offices accomplished almost as much as four people in lean offices.”

Once upon a time the web was supposed to be system for sharing carefully structured information, full of sensible metadata and collaboration. Instead, we turned it into an semi-opaque app delivery model running in a browser sandbox.

And:

we take it for granted that we can read the code we’re running, examine the markup we’re seeing, and review the CSS that styles it. But all these aspects of web development may be nothing more than a brief and transient anomaly in the history of software design.

Take for granted is right.

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.

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.

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.)

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.

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.

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.

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.

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...