Write about what you learn. It pushes you to understand topics better. Sometimes the gaps in your knowledge only become clear when you try explaining things to others. It’s OK if no one reads what you write. You get a lot out of just doing it for you.
Lots of good advice from Addy:
Saying no is better than overcommitting.
Obviously, no one does this, I recognize this is a very niche endeavor, but the art and craft of maintaining a homepage, with some of your writing and a page that’s about you and whatever else over time, of course always includes addition and deletion, just like a garden — you’re snipping the dead blooms. I do this a lot. I’ll see something really old on my site, and I go, “you know what, I don’t like this anymore,” and I will delete it.
But that’s care. Both adding things and deleting things. Basically the sense of looking at something and saying, “is this good? Is this right? Can I make it better? What does this need right now?” Those are all expressions of care. And I think both the relentless abandonment of stuff that doesn’t have a billion users by tech companies, and the relentless accretion of garbage on the blockchain, I think they’re both kind of the antithesis, honestly, of care.
How do you keep knowledge alive over centuries? Stuff that seems big enough for a group of people to worry about at the time, but not so big it makes world news. Not the information that gets in all the textbooks, but just the stuff that makes the world gently tick over.
Don’t blame it on the COBOL:
It’s a common fiction that computing technologies tend to become obsolete in a matter of years or even months, because this sells more units of consumer electronics. But this has never been true when it comes to large-scale computing infrastructure. This misapprehension, and the language’s history of being disdained by an increasingly toxic programming culture, made COBOL an easy scapegoat. But the narrative that COBOL was to blame for recent failures undoes itself: scapegoating COBOL can’t get far when the code is in fact meant to be easy to read and maintain.
It strikes me that the resilience of programmes written in COBOL is like the opposite of today’s modern web stack, where the tangled weeds of nested dependencies ensures that projects get harder and harder to maintain over time.
In a field that has elevated boy geniuses and rockstar coders, obscure hacks and complex black-boxed algorithms, it’s perhaps no wonder that a committee-designed language meant to be easier to learn and use—and which was created by a team that included multiple women in positions of authority—would be held in low esteem. But modern computing has started to become undone, and to undo other parts of our societies, through the field’s high opinion of itself, and through the way that it concentrates power into the hands of programmers who mistake social, political, and economic problems for technical ones, often with disastrous results.
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.
Design systems can often ‘read’ as very top down, but need to be bottom up to reflect the needs of different users of different services in different contexts.
I’ve yet to be involved in a design system that hasn’t struggled to some extent for participation and contribution from the whole of its design community.
Aaaaaand the circle is now complete.
It is a crisis of care.
As with anything, it’s not about the technology itself:
A well-made design system created for the right reasons is reparative. One created for the wrong reasons becomes a weapon for displacement. Tools are always beholden to values. This is well-trodden territory.
Episode 226 – Create Your Own Website Write about What You Discover and Be Dependable with Jeremy Keith – IT Career Energizer
This was a really fun podcast chat—nice and snappy at just 20 minutes.
Here, then, is my speculation. Work is something we struggle to get and strive to keep. We love-hate it (usually not in equal measure). Sometimes it seems meaningless. I’m told this is the case even for surgeons, teachers and disaster-relief workers: those with jobs whose worth seems indisputable. For the mere facilitators, the obscure cogs in the machinery of the modern economy whose precise function and value it takes some effort to ascertain, the meaning in what we do often seems particularly elusive (I should know). I contend, however, that while our lives need to be meaningful, our work does not; it only has to be honest and useful. And if someone is voluntarily paying you to do something, it’s probably useful at least to them.
Tim ponders the hard work that goes into adding standards to browsers, giving us a system with remarkable longevity.
So much care and planning has gone into creating the web platform, to ensure that even as new features are added, they’re added in a way that doesn’t break the web for anyone using an older device or browser. Can you say the same for any framework out there?
His parting advice is perfect:
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.
I love the way that Amber is documenting her journey—I think this is so useful for others making the progression from junior to mid-level developer.
This is such a lovely farewell from Ellen. We’re all going to miss having her around.
Clearleft really set an example to other companies when it comes to their mission to help their staff pursue their ambitions — their training has given me a much bolder confidence for public speaking, for developing my voice and for getting my ideas out there. The generous attitude to learning, sharing and bold experimentation at Clearleft is one of the best things about working there.
When we talk about HTML and CSS these discussions impact the entry point into this profession. Whether front or backend, many of us without a computer science background are here because of the ease of starting to write HTML and CSS. The magic of seeing our code do stuff on a real live webpage! We have already lost many of the entry points that we had. We don’t have the forums of parents teaching each other HTML and CSS, in order to make a family album. Those people now use Facebook, or perhaps run a blog on wordpress.com or SquareSpace with a standard template. We don’t have people customising their MySpace profile, or learning HTML via Neopets. We don’t have the people, usually women, entering the industry because they needed to learn HTML during that period when an organisation’s website was deemed part of the duties of the administrator.
I agree with every single word Rachel has written.
I care not a whit what tools or frameworks, or languages you use to build something on the web. But I really care deeply when particular tools, frameworks, or languages become mandatory for even getting a foot in the door.
This is for everyone.
I might be the “old guard” but if you think I’m incapable of learning React, or another framework, and am defending my way of working because of this, please get over yourself. However, 22 year old me would have looked at those things and run away. If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged. I have plenty of fight left in me to stand up against that.
Something that I am increasingly uncomfortable with is our industry’s obsession with job titles. I understand that the landscape has gotten a lot more complex than when I started out in 2009, but I do think the sheer volume and variation in titles isn’t overly helpful in communicating what people actually do.
I share Andy’s concern. I kinda wish that the title for this open job role at Clearleft could’ve just said “Person”.
An excellent thorough analysis by Chris of the growing divide between front-end developers and …er, other front-end developers?
The divide is between people who self-identify as a (or have the job title of) front-end developer, yet have divergent skill sets.
On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.
I share many of Cole’s concerns. I think we’re in fairly similiar situations. We even share the same job title: Technical Director …whatever that even means.
I worry about our over-reliance and obsession with tools because for many these are a barrier to our discipline. I worry that they may never really make our work better, faster or easier and that our attention is increasingly focussed not on the drawing but on the pencils. But I mostly worry that our current preoccupation with the way we work (rather than necessarily what we work on) is sapping my enthusiasm for an industry I love and care about immensely.
There are of course things worth your time and deep consideration, and there are distractions. Profound new thinking and movements within our industry - the kind that fundamentally shifts the way we work in a positive new direction are worth your time and attention. Other things are distractions. I put new industry gossip, frameworks, software and tools firmly in the distractions category. This is the sort of content that exists in the padding between big movements. It’s the kind of stuff that doesn’t break new ground and it doesn’t make or break your ability to do your job.
Following on from Ben’s post, this is also giving me the warm fuzzies.
I, in no uncertain terms, have become a better designer thanks to the people I’ve had the pleasure of working alongside at Clearleft. I’ll forever be thankful of my time there, and to the people who helped me become better.