Link tags: skills

I don’t have time to learn React - Keith Cirkel

React is a non-transferable skill.

React proponents might claim that React will teach you modern UI, but from what I’ve seen it barely copes with modern UI. autofocus is broken, custom elements don’t work in all but the experimental version, using any “modern” features like dialog or popovers requires useEffect, and the synthetic event system teaches you so little about how DOM actually works. This isn’t modern UI, it’s UI from 2013 at its inception. I don’t have the time left in my career to pick up UI paradigms that haven’t evolved much beyond from when Barack Obama was in office.

When I mentor early career developers and they ask me what they should learn, I can’t say React, they don’t have time. I mean sure, pick up enough React to land you the inevitable job doing it, but it’s not going to level up your career.

Hire HTML and CSS people

Every problem at every company I’ve ever worked at eventually boils down to “please dear god can we just hire people who know how to write HTML and CSS.”

The Frontend Treadmill - These Yaks Ain’t Gonna Shave Themselves

Your teams should be working closer to the web platform with a lot less complex abstractions. We need to relearn what the web is capable of and go back to that.

Let’s be clear, I’m not suggesting this is strictly better and the answer to all of your problems. I’m suggesting this as an intentional business tradeoff that I think provides more value and is less costly in the long run.

New Web Development. Or, why Copilots and chatbots are particularly bad for modern web dev – Baldur Bjarnason

The paradigm shift that web development is entering hinges on the fact that while React was a key enabler of the Single-Page-App and Component era of the web, in practice it normally tends to result in extremely poor products. Built-in browser APIs are now much more capable than they were when React was first invented.

The quiet, pervasive devaluation of frontend - Josh Collinsworth blog

It’s like CSS exists in some bizarre quantum state; somehow both too complex to use, yet too simple to take seriously, all at once.

In many ways, CSS has greater impact than any other language on a user’s experience, which often directly influences success. Why, then, is its role so belittled?

Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.

The Chimeralogists

I might just be pattern-matching, but I recognise myself in what Robin describes here:

No one can explain what you do. Let’s face it, you don’t do a great job explaining it either. People come to you for advice on issues that they introduce with “I’m not entirely sure how to describe this problem or what exactly I’m looking to do here, but…” Your colleagues and your communities genuinely value your contributions even as they remain entirely mystified by the exact contour of your position.

Front-of-the-front-end and back-of-the-front-end web development | Brad Frost

These definitions work for me:

A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.

A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.

The Widening Responsibility for Front-End Developers | CSS-Tricks

Chris shares his thoughts on the ever-widening skillset required of a so-called front-end developer.

Interestingly, the skillset he mentions half way through (which is what front-end devs used to need to know) really appeals to me: accessibility, performance, responsiveness, progressive enhancement. But the list that covers modern front-end dev sounds more like a different mindset entirely: APIs, Content Management Systems, business logic …the back of the front end.

And Chris doesn’t even touch on the build processes that front-end devs are expected to be familiar with: version control, build pipelines, package management, and all that crap.

I wish we could return to this:

The bigger picture is that as long as the job is building websites, front-enders are focused on the browser.

Design muscles

Look. Observe. See.

You got this. | Zeldman on Web & Interaction Design

I can relate to this.

What Does it Mean to Be “Full Stack”? | CSS-Tricks

I’m not trying to convince anyone they aren’t a full-stack developer or don’t deserve that particular merit badge — just that the web is a big place with divergent needs and ever-morphing stacks that all require different sets of skills.

The “Backendification” of Frontend Development – Hacker Noon

Are many of the modern frontend tools and practices just technical debt in disguise?

Ooh, good question!

The Great Divide | CSS-Tricks

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 one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.

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.

Stop Learning Frameworks – Lifehacks for Developers by Eduards Sizovs

It’s a terribly clickbaity (and negatively phrased) title, but if you turn it around, there’s some good advcie in here for deciding where to focus when it comes to dev technology:

• Programming languages are different, but design smells are alike.
• Frameworks are different, but the same design patterns shine through.
• Developers are different, but rules of dealing with people are uniform.

Big ol’ Ball o’ JavaScript | Brad Frost

Backend logic? JavaScript. Styles? We do that in JavaScript now. Markup? JavaScript. Anything else? JavaScript.

Historically, different languages suggested different roles. “This language does style.” “This language does structure.” But now it’s “This JavaScript does style.” “This JavaScript does structure.” “This JavaScript does database queries.”

I Don’t Believe in Full-Stack Engineering • Robin Rendle

A good ol’ rant from Robin.

HTML and CSS and JavaScript have always been looked down upon by many engineers for their quirks. When they see a confusing and haphazardly implemented API across browsers (HTML/CSS/JS), I see a swarming, writhing, and constantly improving interface that means we can read stuff that was written fifteen years ago and our browsers can still parse it.

Before jumping to conclusions, read the whole thing. Robin isn’t having a go at people who consider themselves full-stack developers; he’s having a go at the people who are only hiring back-end developers and expecting them to automatically be “full stack.”

You are not your tools

The technologies you use, the tools you build with, are just that: tools. Learn to use them, and learn to use them well. But always remember that those tools are there to serve you, you are not there to serve your tools.

Twenty Eighteen Preparation: Becoming an Endless Newbie - Airbag Industries

In the past, when I brushed off new advances or updates to technology and processes I preferred to stick with a simple path of “it still works fine,” but in doing so I realize now that I have l lost a lot beginning with the ability to function with current best practices in certain areas of my skill sets and the degradation a few projects, especially Airbag.

5 things CSS developers wish they knew before they started | CSS-Tricks

1. Don’t underestimate CSS
2. Share and participate
3. Pick the right tools
4. Get to know the browser
5. Learn to write maintainable CSS

Introducing the Made by Many professional development programme – Made by Many

This resonates a lot—we’ve been working on something similar at Clearleft, for very similar reasons:

We rode the folk knowledge train until it became clear that it was totally unscaleable and we struggled to effectively commute know-how to the incoming brains.

At Made By Many, they’ve sliced it into three categories: Design, Technology, and Product Management & Strategy. At Clearleft, we’re trying to create a skills matrix for each of these disciplines: UX, UI, Dev, Research, Content Strategy, and Project Management. I’m working on the Dev matrix. I’ll share it once we’ve hammered it into something presentable. In the meantime, it’s good to see exactly the same drivers are at work at Made By Many:

The levels give people a scaffold onto which they can project their personalised career path, reflecting their progression, and facilitating professional development at every stage.