“inkle blog - ink version 1.0 release!”
Ink by Inkle Studios has been on my list of things to try out for ages. Looks like a great tool for interactive storytelling.
“Functional vs. OO: The Debate that Imprecise Language Destroyed – Chelsea Troy”
I love posts like this where the author puts the work in to clarify the language behind a long running debate.
One thing that does unfortunately have to be said: a lot of the people doing the pushback against excessive formalism/minimalism are total dicks. It seems to be a go-to opinion for a lot of angry designer assholes, for example.
“After Minimalism - David Perell”
“The problem with minimalism is that it’s boring.”
More pushback against the excesses of modern formalism
I’m not the only one who finds app design formalism to be boring
“No More Boring Apps - ANDY.WORKS”
“Despite being perhaps the largest professional creative field today, Product Design seems to be missing something fundamental that exists in every other design field.”
There are three explanations for the design wasteland that is modern app design. All three are probably true at the same time.
- Apple, Google, et al. had a solid go at commodifying apps and UX design.
- The education, training, and recruitment processes in UX design collapsed under excessive demand the same way that front end dev training collapsed.
- This particular swing of the formalist-romanticist pendulum swung particularly hard in the formalist direction this time around.
For those of you who didn’t study art or literary history: design and the creative arts in the west have tended to cycle between formalist movements, where perfection can be found in pure structure, and romanticist movements that maintain that meaning and utility largely resides in society outside of the work. Most other cultures tend not to have these cycles and instead have multiple concurrent cultural traditions going on at the same time. Which is where we’re heading, in general, because of globalisation, but it’ll take a while for the West’s nonsense to peter out, as usual.
We’ve gone through these cycles a dozen times in drama, design, art, and literature. We’ve been going through a formalist reaction to the romanticist postmodern movements that defined the 80s and 90s. If you were wondering why movies in the twenty teens all had a similar structure, whereas those in the 90s and 2000-2010 had more formulas going around and most of them hinged around an obsession with cinematic intertextuality, it isn’t just because everybody first loved Quentin Tarantino and then hated him. It wasn’t just a question of money although money tends to favour formalism/modernism as it tends to commodify the field.
UI design has just gone through a similar cycle and we’re now starting to see a push for it to cycle back into letting designers be more playful.
Aside:
What I’ve found interesting about the current formalist iteration is that they’ve formalised the media property cultural reference. It isn’t a coincidence that Disney’s Marvel movies didn’t reference the Fox X-Men movies, even obliquely, until they owned fox.
To put it more plainly: Deadpool is a postmodernist movie and in many ways a stylistic throwback to earlier trends. If you wanted to be unkind you’d call it a (cultural) living fossil. Almost every other big studio movie these days are ultra-modernistic exercises in formula and structure.
End Aside
The Layers of Development: Design Engineer, UI Engineer, Full Stack Developer, Server-Side Developer
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.
A proposal for naming every layer in the web development roles cake
Like Jeremy Keith and many others who work in front end development, I’ve taken a liking to Brad Frost’s framing of web dev as being divided into front-of-the-front-end and back-of-the-front-end, which seems like a neat way of acknowledging that with SPAs and component frameworks, big chunks of back end development (state management, authentication, business logic) has moved into the front end.
(You can debate whether that’s a good idea or not for most web services but that point is generally moot. As an industry we no longer know how to do it any other way. Isolated pockets of developer communities have broader skill sets that let them pick and choose an architecture that’s the best for their task. It’s like having a team that’s capable and comfortable with reaching for the Scheme programming language when it’s appropriate for the task. It’s a great capability to have in a team but let’s not pretend that it’s normal or usual. Flexibility and diverse capabilities is not what web development in general is any more.)
What most stumble over is the name: front-of-the-front-end doesn’t exactly roll off the tongue. So, again like Jeremy Keith, I jumped on the term design engineer as a name for my preferred speciality.
(Preferred being the key word here. I’ve had to work on pretty much every layer of web development for extended periods at one time or another.)
It’s about translating design into implementation, usually in close collaboration with the design team.
That still leaves us with awkward names for the other roles in the layer cake that is web development.
Thankfully, in the same way that ‘design engineer’ has been percolating in the background for a few years, we also have ready-made terms for the other layers that are already in use.
A key term comes from Dan Abramov, one of the engineers who works on React, describes his job as being an UI engineer. He sees himself as being responsible for the consistency, reliability, performance, and state in the front end.
You know… back of the front end stuff.
Which leads me to propose the following names for each of these roles in web development.
- Design Engineer: front-of-the-front-end. Translator between design and implementation. Collaborates closely with the design team.
- UI Engineer: back of the front end. Builds the foundation that the design engineer builds on and hooks into. Works on state management, UI performance, tricky foundational implementation details for the front end, and tough abstraction problems.
- Server-side developer: business logic on the server. Nowadays that usually means they’re making an API server but can also be a CRUD server working mainly with HTML.
- Full-stack developer: a developer that does both server-side work and UI engineering work. They work on business logic and abstractions wherever those need to be implemented. Sometimes it’s server-side in, say, a Lambda function. Sometimes it’s client-side in a component delivered via Netlify or similar service.
The paradox of web development over the past decade is that we’ve steadily been losing specialisation, which is usually a sign of collapse. We’ve gone from having CSS specialists to demanding that twenty-year-olds understand every single layer in a complex, thirty year old, tech stack. No wonder they are burning out.
(I’d argue that we have experienced a collapse, just one that looks different from most other collapses. What we’ve seen is the structure of web dev education and recruitment collapse because it can’t come close to meeting the true underlying demand for web developers. IMHO.)
I’m hoping that these conversations people have been having about the various roles in web development is the first step in bringing back specialisation in web dev.
I don’t think the field will be able to thrive without it.
“Unfortunate things about performance reviews”
“If you take nothing else away from this post, take this: a sufficiently skilled manager can take the same body of work and make it work for you OR against you.”
“Ursula K. Le Guin’s translation of the Tao Te Ching - Austin Kleon”
This book is one of the most personally important books in my collection. I read it regularly.
“On Design Engineering: I think I might be a design engineer… - Trys Mudford”
“My build tool boilerplate goes v2 - Go Make Things”
Lots of nice little details in this.
“Choosing between Netlify, Vercel and Digital Ocean - Zell Liew”
I’m a huge fan of Netlify’s design and ergonomics but you’re definitely paying for that fancy, world-class, global CDN when it comes to bandwidth pricing.
“Why I Still Use RSS - atthislink”
I use RSS a lot. Over 90% of the links I post (like this one) I find through my feed reader. Trying to keep up with web development or publishing using social media feels like a very addictive way to accomplish nothing.
“Storytelling — Harmon vs. McKee”
An interesting meditation on the role of intuition in strategy and analysis
On the deteriorating quality of Apple’s software
“Why reporting bugs to Apple may harm software quality – The Eclectic Light Company”
The quality of Apple’s software deteriorates with every release. Bugs languish for years. Small features, like search indexing of some file types, break.
These aren’t minor bugs either. Michael Tsai has been documenting a serious data loss bug in Apple Mail that is still unfixed after a year and a half in the wild.
This is as good a theory as to why this is happening as any other I’ve heard.
The only software team at Apple that stands above the rest is the Safari team, which seems to deliver software at a much higher standard than the rest. Which makes the Chrome team’s claim that Apple is deliberately sabotaging Safari development by starving the team of resources all the more annoying: it’s clearly Apple’s highest performing flagship software team.
That Safari seems to do better supports the process thesis in the original blog post. Safari has an open source library at it’s heart and works with open standards. It has to use a different process, one that clearly works better than what takes place at the rest of Apple.
“Leading your engineering team with ‘experiments’ not ‘processes’ - LeadDev”
On “The Curious Case of “Are you sure?” – the Usecrime That Just Won’t Die”
“The Curious Case of “Are you sure?” – the Usecrime That Just Won’t Die”
I’m as guilty as others of overusing confirmation dialogues but, in my defense, I’ve actually never even been asked to try to implement undo in any of the front end interfaces I’ve worked on.
The curious thing about this case (and other usecrimes) is that I keep hearing about UX designers running into programmers who are hesitant to implement features necessary for good UX.
And I keep hearing from programmers who are never asked to implement these things.
This leads me to think that something’s being unevenly distributed here.
“Running a Successful Membership / Subscription Program — by Craig Mod”
“Two songs from The Muppet Movie / Snarkmarket”
Always post links to discussions of Muppet songs.
Everybody is pussyfooting around the actual problem in front end development
This blog post by Chris Coyier does a good job of pulling together the various threads of dissatisfaction that have been cropping up in the front end development community.
He almost, almost gets into the problem.
Minor pushback there: a lot of people don’t get any choice in the technologies they are tasked with.
That isn’t minor pushback. That’s the heart of the issue: we are beset by crap managers who don’t understand tech, don’t understand how programming works (PDF), resort to React because it simplifies recruitment (no matter whether it’s appropriate to your project or not), and—to top it all off—don’t view their own job, management, as the craft that it is. They’d rather read a fluffy airport management book than ever pick anything up by Deming, Reinertsen, or Gareth Morgan.
It’s a rare manager in tech that actually practices—actually puts a constant effort into improving their management craft.
Our managers choose the wrong tech, wrong processes, wrong platforms, and then never invest in training. Without their backing, the complexities you witness in modern front end web development would never have had the resources to exist in the first place.
Even those of use with good managers still suffer because the managers the rest of you have made sure that the field’s standard practices are toxic as hell and its processes are broken as designed.
There’s actually nothing wrong with much of the tech in front end dev. The tools are fine. Some are complex and are used much to much with little attempt to control the spread of complexity. Some are simple and horrendously underused. The frameworks are useful when used appropriately and magnify complexity when used inappropriately. Browsers are fine and have amazing APIs out of the box but also have stupendously hard-to-use capabilities that you should rarely reach for without a framework.
The field of web development, however, has been mismanaged to within an inch of its life by people who think they know what they are doing but put no effort into studying what they are doing. And their mismanagement has poisoned our practices.