Archive: February 19th, 2021
The story “Button, Button” by Richard Matheson describes a stranger delivering a box with a button to a struggling couple. If you press the button, you get money. But someone you don’t know will die.
I think Satoshi Nakamoto read it.
Replying to a tweet from @mikeindustries
It’s incontraverible. Proof of work deliberately wastes copious amounts of energy …by design.
It’s like someone heard about the trolley problem and thought “yeah, that’s let’s do this!”
Design Engineering - Snook.ca
Here’s a seven-year old post by Snook—this design engineer thing is not new.
Replying to a tweet from @tomkiss
Imagine how architects feel about the David Brents going around calling themselves “solutions architects.”
It’s been just over two years since Chris wrote his magnum opus about The Great Divide. It really resonated with me, and a lot of other people.
The crux of it is that the phrase “front-end development” has become so broad and applies to so many things, that it has effectively lost its usefulness:
Two front-end developers are sitting at a bar. They have nothing to talk about.
Brad nailed the differences in responsibilities when he described them as front-of-the-front-end and back-of-the-front-end web development:
In my experience, the term “full stack developer” is often self-applied by back-of-the-front-end developers who perhaps underestimate the complexity of front-of-the-front development.
Me, I’m very much a front-of-the-front developer. And the dev work we do at Clearleft very much falls into that realm.
This division of roles and responsibilities reminds me of a decision we made in the founding days of Clearleft. Would we attempt to be a full-service agency, delivering everything from design to launch? Or would we specialise? We decided to specialise, doubling down on UX design, which was at the time an under-served area. But we still decided to do front-end development. We felt that working with the materials of the web would allow us to deliver better UX.
We made a conscious decision not to do back-end development. Partly it was a question of scale. If you were a back-end shop, you probably had to double down on one stack: PHP or Ruby or Python. We didn’t want to have to turn away any clients based on their tech stack. Of course this meant that we had to partner with other agencies that specialised in those stacks, and that’s what we did—we had trusted partners for Drupal development, Rails development, Wordpress development, and so on.
Overall, our decision to avoid back-end development stood us in good stead. There were plenty of challenges though. We had to learn how to avoid “throwing stuff over the wall” at whoever would be doing the final back-end implementation. I think that’s why we latched on to design systems so early. It was clearly a better deliverable for the people building the final site—much better than mock-ups or pages.
Avoiding back-end development meant we also avoided long-term lock-in with maintainence, security, hosting, and so on. It might sound strange for an agency to actively avoid long-term revenue streams, but at Clearleft it’s always been our philosophy to make ourselves redundant. We want to give our clients everything they need—both in terms of deliverables and knowledge—so that they aren’t dependent on us.
That all worked great as long as there was a clear distinction between front-end development and back-end development. Front-end development was anything that happened in a browser. Back-end development was anything that happened on the server.
That’s why Brad’s framing resonated with me. Clearleft does front-of-front-end development, but we liaise with our clients’ back-of-the-front-end developers. In fact, that bridging work—between design and implementation—is where devs at Clearleft shine.
As much as I can relate to the term front-of-front-end, it doesn’t exactly roll off the tongue. I don’t expect it to be anyone’s job title anytime soon.
That’s why I was so excited by the term “design engineer,” which I think I first heard from Natalya Shelburne. There’s even a book about it and the job description sounds very much like the front-of-the-front-end work but with a heavy emphasis on the collaboration and translation between design and implementation. As Trys puts it:
What I love about the name “Design Engineer”, is that it’s entirely focused on the handshake between those two other roles.
There’s no mention of UI, CSS, front-end, design systems, documentation, prototyping, tooling or any ‘hard’ skills that could be used in the role itself.
Trys has been doing some soul-searching and has come to the conclusion “I think I might be a design engineer…”. He has also written on the Clearleft blog about how well the term describes design and development at Clearleft.
Personally, I’m not a fan of using the term “engineer” to refer to anyone who isn’t actually a qualified engineer—I explain why in my talk Building—but I accept that that particular ship has sailed. And the term “design developer” just sounds odd. So I’m all in using the term “design engineer”.
I can imagine this phrase being used in a job ad. It could also be attached to levels: a junior design engineer, a mid-level design engineer, a senior design engineer; each level having different mixes of code and collaboration (maybe a head of design enginering never writes any code).
Trys has written a whole series of posts on the nitty-gritty work involved in design engineering. I highly recommend reading all of them:
Reading Lagoon by Nnedi Okorafor.
ignore the code: Bookfeed.io
Such an elegant idea!
Bookfeed.io is a simple tool that allows you to specify a list of authors, and generates an RSS feed with each author’s most recently released book.
Small pieces, loosely joined.
Yax.com · Blog · Out of the Matrix: Early Days of the Web (1991)
Thirty years later, it is easy to overlook the web’s origins as a tool for sharing knowledge. Key to Tim Berners-Lee’s vision were open standards that reflected his belief in the Rule of Least Power, a principle that choosing the simplest and least powerful language for a given purpose allows you to do more with the data stored in that language (thus, HTML is easier for humans or machines to interpret and analyze than PostScript). Along with open standards and the Rule of Least Power, Tim Berners-Lee wanted to make it easy for anyone to publish information in the form of web pages. His first web browser, named Nexus, was both a browser and editor.