"Again, you should do your job in such a fashion others can build on top of it. Do not in the process try to make yourself indispensable; if you do then you cannot be promoted because you will be the only one who can do what you are now doing! I have seen a number of times where this clinging to the exclusive rights to the idea has in the long run done much harm to the individual and to the organization. If you are to get recognition then others must use your results, adopt, adapt, extend, and elaborate them, and in the process give you credit for it. "
In everything you do, take the extra effort to provide just a little more context so that your work can become useful to others outside your immediate audience. The more effort you put in, the more valuable your work can become.
"The Nike guided missile systems, the computer systems I ran, and many other aspects of the work at Bell Telephone Laboratories all taught me the facts of systems engineering—not abstractly, but in hard lessons daily illustrated by idiots who did not understand the whole as a whole, but only the components. "
Harsh take. But the same thing can be said of our addiction to components in software and design. Components exist to serve a larger system, not to satisfy our aesthetic itch to build novel component libraries.
"It has great beauty of layout. But in its details of construction it still falls far behind. Indeed, in its construction it is completely spoiled. For reasons outside our control, it was necessary that this particular building, once laid out, was then "detailed" by ordinary processes. It was taken to the drawing board, by people who had not laid it out, far from the site, and given mechanical "drawn" details, quite inappropriate to its design... until it became, in the end, no different from a thousand ordinary buildings of our time. In short, it was almost destroyed, because it was not built in the right way. At first I hesitated, I was not sure whether to write this, or whether to include the picture, because it is so sad and so depressing. But then I realized how essential it is to include it: because many people may be willing to lay out a building in the way I have described, and will then try to get it built from drawings. "
I love how Alexander spends a whole chapter talking about this beautiful design they created, only to have it be utterly butchered when it came to the actual implementation. “Looks great in Figma”. You see this a lot in software where the end result looks like nothing the designer envisioned and this usually happens when the engineers are the people who “had not laid it out” and are too “far from the site”. Or rather, “throwing designs over the wall”.
"...if the builder builds according to a detailed drawing, and is constrained by his contract to make the building exactly like the drawing, he then makes the detail identical, to follow the drawing-and in the actual building this becomes dead and artificial. "
This reads exactly like an argument against trying to be “pixel perfect” and taking a Figma design too literally. Instead, Alexander argues that builders (engineers) need to build the design using the same pattern language that created it. A consequence of this is that you will always get a slightly different result each time you apply the language, but that’s exactly the point. If the patterns and the language are good, the result will always be good. They may not match what’s in Figma, but they will match the intent of the design.
This goes against just about every “best practice” today. We simply have no mental model for patterns like this. The best “patterns” are at best just big components.
"Dr. Ryan told us, after his clinic was built, that this one week he spent with us, shaping the building, was the most important week he had spent in five years the week in which he had felt most alive... The simple process by which people generate a living building simply by walking it out, waving their arms, thinking together, placing stakes in the ground, will always touch them deeply. "
There’s something immensely powerful in designing things together with the people who will actually be using the thing and the people who will actually be building the thing. Some of the most memorable highlights of my career have been the times where I was working directly with stakeholders and users of the actual thing I was building and riffing off a hundred “wouldn’t-it-be-cools”.
I once built some software for salespeople to streamline the quoting process for a Gazebo-building company. I wasted a week trying to “gather requirements” before I finally drove over, sat down and asked someone to “sell me a Gazebo”. And we quite literally “walked it out” through the showroom floor and I got to see for myself what the actual difference between wood and composite flooring was.
The farther you get from the user, the more sterile your “requirements” become.
"He believes specialists brought together to make a team are the basis of systems engineering, and between jobs they must go back to their specialties to maintain their expertise. Using the group too often to fight fires is detrimental in the long run since then the individuals do not keep their skills honed up in their areas. "
I always felt like people who work on design systems should be required to rotate back to product work to stay grounded in what the actual problems are.
"...the computers were but a part of a research–development organization, vital to be sure, but it was their value to the system which mattered in the long run, how well the computers helped reach the organization’s goals, as well as society’s goals, and not how comfortable it was for the staff operating the computers. "
At the end of the day, components (computers in this case) serve the organization’s goal, which are not always the same goals as the staff using them. If you focus only on the user experience and ergonomics of your components, you risk losing sight of why you’re doing the work in the first place.
Thinking about this the next time I’m naming design tokens.
Also, remember that Material Design serves Google’s goals, which may or may not be your own organization’s goals.
"Cato would have smiled hearing about the recently observed effect in aeronautics that the automation of airplanes is underchallenging pilots, making flying too comfortable for them, dangerously comfortable. The dulling of the pilot's attention and skills from too little challenge is indeed causing deaths from flying accidents. Part of the problem is a Federal Aviation Administration (FAA) regulation that forced the industry to increase its reliance on automated flying. "
Not to compare software engineering with aeronautics, but if you spend more than an hour using AI to code, you’ll discover there’s a very real dulling of attention and skills that comes from this kind of boredom.