Monday, May 4th, 2020
Thursday, April 30th, 2020
I was on the podcast A Question Of Code recently. It was fun! The podcast is aimed at people who are making a career change into web development, so it’s right up my alley.
I sometimes get asked about what a new starter should learn. On the podcast, I mentioned a post I wrote a while back with links to some great resources and tutorials. As I said then:
That’s assuming you want to be a good well-rounded web developer. But it might be that you need to get a job as quickly as possible. In that case, my advice would be very different. I would advise you to learn React.
Regardless of your initial route, what’s the next step? How do you go from starting out in web development to being a top-notch web developer?
I don’t consider myself to be a top-notch web developer (far from it), but I am very fortunate in that I’ve had the opportunity to work alongside some tippety-top-notch developers at Clearleft—Trys, Cassie, Danielle, Mark, Graham, Charlotte, Andy, and Natalie.
They—and other top-notch developers I’m fortunate to know—have something in common. They prioritise users. Sure, they’ll all have their favourite technologies and specialised areas, but they don’t lose sight of who they’re building for.
When you think about it, there’s quite a power imbalance between users and developers on the web. Users can—ideally—choose which web browser to use, and maybe make some preference changes if they know where to look, but that’s about it. Developers dictate everything else—the technology that a website will use, the sheer amount of code shipped over the network to the user, whether the site will be built in a fragile or a resilient way. Users are dependent on developers, but developers don’t always act in the best interests of users. It’s a classic example of the principal-agent problem:
The principal–agent problem, in political science and economics (also known as agency dilemma or the agency problem) occurs when one person or entity (the “agent”), is able to make decisions and/or take actions on behalf of, or that impact, another person or entity: the “principal”. This dilemma exists in circumstances where agents are motivated to act in their own best interests, which are contrary to those of their principals, and is an example of moral hazard.
A top-notch developer never forgets that they are an agent, and that the user is the principal.
But is it realistic to expect web developers to be so focused on user needs? After all, there’s a whole separate field of user experience design that specialises in this focus. It hardly seems practical to suggest that a top-notch developer needs to first become a good UX designer. There’s already plenty to focus on when it comes to just the technology side of front-end development.
So maybe this is too simplistic a way of defining the principle-agent relationship between users and developers:
user :: developer
There’s something that sits in between, mediating that relationship. It’s a piece of software that in the world of web standards is even referred to as a “user agent”: the web browser.
user :: web browser :: developer
So if making the leap to understanding users seems too much of a stretch, there’s an intermediate step. Get to know how web browsers work. As a web developer, if you know what web browsers “like” and “dislike”, you’re well on the way to making great user experiences. If you understand the pain points for browser when they’re parsing and rendering your code, you’ve got a pretty good proxy for understanding the pain points that your users are experiencing.
Tuesday, April 28th, 2020
I really enjoyed having a chat with Ed and Tom on their podcast. It’s aimed at people making a career shift into web development, but that didn’t stop me banging on about my usual hobby horses: progressive enhancement, resilient web design, and all that jazz.
There is a huge world out there where design isn’t embraced, where designers are clawing for resources, and where design isn’t prioritized. Most of the organizations that are changing your world don’t know much about design, aren’t looking for designers, and won’t even understand what designers are talking about when they show up at the front door.
Monday, April 20th, 2020
I love how Remy explains front-end development to his kids:
The bones are the HTML. Each bone has a name, we call them tags (or elements).
…the skin and the paint on the skin, this is CSS.
Monday, March 30th, 2020
Over the past few years, I’ve given quite a few workshops and talks on evaluating technology. This methodical approach to evaluation and prioritisation from Trys is right up my alley!
In any development project, there is a point at which one must decide on the tech stack. For some, that may feel like a foregone conclusion, dictated by team appetite and experience.
Even if the decision seems obvious, it’s always worth sense-checking your thought process. Along with experience and gut-feelings, we also have blind-spots and biases.
I feel like there’s a connection here to having good design principles—the kind that explicitly value one facet over another.
Sunday, March 15th, 2020
CSS only truly exists in a browser. As soon as we start writing CSS outside of the browser, we rely on guesses and memorization and an intimate understanding of the rules. A text editor will never be able to provide as much information as a browser can.
Thursday, March 12th, 2020
Wednesday, March 11th, 2020
CSS is frustrating because you have to actually think of a website like a website and not an app. That mental model is what everyone finds so viscerally upsetting. And so engineers do what feels best to them; they try to make websites work like apps, like desktop software designed in the early naughts. Something that can be controlled.
Tuesday, March 3rd, 2020
A ludicrously useful grab-bag of prioritisation techniques from Chris—so, so handy for workshops and sprint planning.
I can see this coming in very handy at Codebar—pop any CSS selector in here and get a plain English explanation of what it’s doing.
Friday, February 28th, 2020
The headline begs the question, but Robin makes this very insightful observation in the article itself:
Tuesday, February 25th, 2020
I love, love, love this encounter that Stephanie had with high school students when she showed them her own website (“Your website? You have a website?”).
I opened the DevTools on my site and there was an audible gasp from the class and excited murmuring.
“That’s your code?” A student asked. “Yes, that’s all my code!” “You wrote all of that?!” “Yes, it’s my website.”
And the class kind of exploded and starting talking amongst themselves. I was floored and my perspective readjusted.
When I code, it’s usually in HTML and CSS, and I suppose there’s a part of me that feels like that isn’t special because some tech bros decide to be vocal and loud about HTML and CSS not being special nearly everyday (it is special and tech bros can shut up.)
And the response from that class of high school students delighted me and grounded me in a way I haven’t experienced before. What I view as a simple code was absolute magic to them. And for all of us who code, I think we forget it is magic. Computational magic but still magic. HTML and CSS are magic.
Yes! Yes! Yes!
Monday, February 24th, 2020
Jen kicked off a fascinating thread here:
It’s come up quite a few times recently that the world of people who make websites would greatly benefit from the CSS Working Group officially defining ”CSS 4”, and later “CSS 5“, etc.
The level is discourse is impressively smart and civil.
Personally, I don’t (yet) have an opinion on this either way, but I’ll be watching it unfold with keen interest.
Through planning and architectural design, Le Corbusier hoped to create a scientifically rational and comprehensive solution to urban problems in a way that would both promote democracy and quality of life. For him, the factory production process applied to high-rise buildings with prefabricated and standardized components is the most modern and egalitarian of urban forms.
Something something top-down design systems.
Tuesday, February 18th, 2020
I am the programming equivalent of a home cook.
The exhortation “learn to code!” has its foundations in market value. “Learn to code” is suggested as a way up, a way out. “Learn to code” offers economic leverage, a squirt of power. “Learn to code” goes on your resume.
But let’s substitute a different phrase: “learn to cook.” People don’t only learn to cook so they can become chefs. Some do! But far more people learn to cook so they can eat better, or more affordably, or in a specific way.
Friday, February 14th, 2020
In this interview, Biance Berning says:
Cassie Evans from Clearleft is an interesting person to follow as she combines web animation with variable font technology, essentially exploring the technology’s practicality and expression.
We’re only just scratching the surface of what variable fonts can do within more interactive and immersive spaces. I think we’ll see a lot more progress and experimentation with that as time goes on.
Monday, February 10th, 2020
The transcript of David Heinemeier Hansson keynote from last year’s RailsConf is well worth reading. It’s ostensibily about open source software but it delves into much larger questions.
Monday, February 3rd, 2020
We’ve industrialized design and are relegated to squeezing efficiencies out of it through our design systems. All CSS changes must now have a business value and user story ticket attached to it.
Dave follows on from my post about design systems and automation.
At the same time, I have seen first hand how design systems can yield improvements in accessibility, performance, and shared knowledge across a willing team. I’ve seen them illuminate problems in design and code. I’ve seen them speed up design and development allowing teams to build, share, and validate prototypes or A/B tests before undergoing costly guesswork in production. There’s value in these tools, these processes.
Wednesday, January 29th, 2020
Architects, gardeners, and design systems
I compared design systems to dictionaries. My point was that design systems—like language—can be approached in a prescriptivist or descriptivist manner. And I favour descriptivism.
A prescriptive approach might give you a beautiful design system, but if it doesn’t reflect the actual product, it’s fiction. A descriptive approach might give a design system with imperfections and annoying flaws, but at least it will be accurate.
I think it’s more important for a design system to be accurate than beautiful.
Meanwhile, over on Frank’s website, he’s been documenting the process of its (re)design. He made an interesting comparison in his post Redesign: Gardening vs. Architecture. He talks about two styles of writing:
In interviews, Martin has compared himself to a gardener—forgoing detailed outlines and overly planned plot points to favor ideas and opportunities that spring up in the writing process. You see what grows as you write, then tend to it, nurture it. Each tendrilly digression may turn into the next big branch of your story. This feels right: good things grow, and an important quality of growth is that the significant moments are often unanticipated.
On the other side of writing is who I’ll call “the architect”—one who writes detailed outlines for plots and believes in the necessity of overt structure. It puts stock in planning and foresight. Architectural writing favors divisions and subdivisions, then subdivisions of the subdivisions. It depends on people’s ability to move forward by breaking big things down into smaller things with increasing detail.
It’s not just me, right? It all sounds very design systemsy, doesn’t it?
This is a false dichotomy, of course, but everyone favors one mode of working over the other. It’s a matter of personality, from what I can tell.
Replace “personality” with “company culture” and I think you’ve got an interesting analysis of the two different approaches to design systems. Descriptivist gardening and prescriptivist architecture.
Frank also says something that I think resonates with the evergreen debate about whether design systems stifle creativity:
It can be hard to stay interested if it feels like you’re painting by numbers, even if they are your own numbers.
I think Frank’s comparison—gardeners and architects—also speaks to something bigger than design systems…
I gave a talk last year called Building. You can watch it, listen to it, or read the transcript if you like. The talk is about language (sort of). There’s nothing about prescriptivism or descriptivism in there, but there’s lots about metaphors. I dive into the metaphors we use to describe our work and ourselves: builders, engineers, and architects.
It’s rare to find job titles like software gardener, or information librarian (even though they would be just as valid as other terms we’ve made up like software engineer or information architect). Outside of the context of open source projects, we don’t talk much about maintenance. We’re much more likely to talk about making.
When tech culture only celebrates creation, it risks ignoring those who teach, criticize, and take care of others.
Anyone who’s spent any time working on design systems can tell you there’s no shortage of enthusiasm for architecture and making—“let’s build a library of components!”
There’s less enthusiasm for gardening, care, communication and maintenance. But that’s where the really important work happens.
In her book The Real World of Technology, the metallurgist Ursula Franklin contrasts prescriptive technologies, where many individuals produce components of the whole (think about Adam Smith’s pin factory), with holistic technologies, where the creator controls and understands the process from start to finish.
In that light, design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.
Humans aren’t always great at efficiency and consistency, but machines are. Automation increases efficiency and consistency, sacrificing messy humanity along the way:
Machine with the strength of a hundred men
Can’t feed and clothe my children.
Historically, we’ve seen automation in terms of physical labour—dock workers, factory workers, truck drivers. As far as I know, none of those workers participated in the creation of their mechanical successors. But when it comes to our work on the web, we’re positively eager to create the systems to make us redundant.
The usual response to this is the one given to other examples of automation: you’ll be free to spend your time in a more meaningful way. With a design system in place, you’ll be freed from the drudgery of manual labour. Instead, you can spend your time doing more important work …like maintaining the design system.
You’ve heard the joke about the factory of the future, right? The factory of the future will have just two living things in it: one worker and one dog. The worker is there to feed the dog. The dog is there to bite the worker if he touches anything.
Roll on snare drum.