Look. Observe. See.
I can relate to this.
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.
Are many of the modern frontend tools and practices just technical debt in disguise?
Ooh, good question!
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.
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.
The sentiment is that front-end development is a problem to be solved: “if we just have the right tools and frameworks, then we might never have to write another line of HTML or CSS ever again!” And oh boy what a dream that would be, right?
Well, no, actually. I certainly don’t think that front-end development is a problem at all.
What Robin said.
I reckon HTML and CSS deserve better than to be processed, compiled, and spat out into the browser, whether that’s through some build process, app export, or gigantic framework library of stuff that we half understand. HTML and CSS are two languages that deserve our care and attention to detail. Writing them is a skill.
A good ol’ rant from Robin.
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.”
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.
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.
- Don’t underestimate CSS
- Share and participate
- Pick the right tools
- Get to know the browser
- Learn to write maintainable CSS
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.
Mike lists five tool skills he looks for in a designer (not that every designer needs to have all five):
- Visual Design & Animation
- Interaction Design
- Getting Things Done
Swap the first one out for some markup and CSS skills, and I reckon you’ve got a pretty good list for developers too.
Be willing to look like a dork:
Embarrassment about what others think has to be the biggest block to any learning. Embarrassment of looking silly. Embarrassment of looking stupid for asking the question everyone else is wondering about but no one is willing to make.
Chimes nicely with Charlotte’s recent piece, Be comfortable looking like an idiot.
Following on from her great conversation with Jen on The Web Ahead podcast, Rachel outlines a strategy to avoid feeling overwhelmed by the deluge of tools, frameworks, libraries, and techniques inundating front-end developers every day:
Learn your core skills well. Understand HTML and CSS, be able to build a layout without leaning on a framework. Get a solid understanding of how a website actually gets from the server to a browser, an understanding of security and accessibility. These are the basics, the constants. These things change slowly. These things sit underneath all the complexity and the tooling, the CMSs and the noise of thousands of people all trying to make their mark on this industry.
She also makes this important point:
As you are doing this don’t forget to share what you know.
My interest in rich client-side apps has almost entirely reversed, and now I’m more interested in doing good ol’ server rendering with the occasional side of progressive enhancement, just like we did it in 2004.
This post resonates with me 100%.
I can very much relate to what Dan is talking about here. I have no idea what I do any more.
No doubt we’ll always feel we’re behind the curve as there always seems like more to learn. That’s OK. No-one knows it all, but it is hard knowing what people expect of you.
I like Cennydd’s thoughts on the fundamental difference between skill and process:
Skilled people without a process will always find a way to get things done. Skill begets process. But process doesn’t beget skill.
A plea for more time.
We tend to think in 2 to 5 year scales, maybe we need to be thinking in longer time lines about our own careers and skills.