A great explanation of
A great explanation of
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.
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 encourage you to think about and make sure you are using the right elements at the right time. Sometimes I overthink this, but that’s because it’s that important to me - I want to make sure that the markup I use helps people understand the content, and doesn’t hinder them.
Léonie makes a really good point here: if you’re adding
When to use
aria-hidden="true", and when you might need
aria-hiddenby itself is not enough to completely hide an element from all users, if that is the end goal.
When to use
aria-hiddencan be used to completely hide content from assistive technology, modifying an element’s
roleto “none” or “presentation” removes the semantics of the element, but does not hide the content from assistive technologies.
I like this distinction between coders and developers.
The Coder is characterized by his proficiency in a narrow range of chosen skills.
By contrast the Developer’s single greatest skill is in being an applied learner.
I’m definitely not a coder. Alas, by this criterion, I’m also not a developer (because I do not pick things up fast):
Quite simply the Developer has a knack for grokking new [languages|frameworks|platforms] and becoming proficient very quickly.
I prefer Charlie’s framing. It’s not about speed, it’s about priorities:
I’m not a “developer” in that I’m obsessed with code and frameworks. I’m a “developer” as in I develop the users experience for the better.
In my experience, “full-stack developers” always translates to “programmers who can do frontend code because they have to and it’s ‘easy’.” It’s never the other way around. The term “full-stack developer” implies that a developer is equally adept at both frontend code and backend code, but I’ve never in my personal experience witnessed anyone who truly fits that description.
When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.
Following on from Ire’s post about linting HTML with CSS, here’s an older post from Ebay about how being specific with your CSS selectors can help avoid inaccessible markup getting into production.
I really, really like Heydon’s framing of inclusive design: yes, it covers accessibility, but it’s more than that, and it’s subtly different to universal design.
He also includes some tips which read like design principles to me:
- Involve code early
- Respect conventions
- Don’t be exact
- Enforce simplicity
Come to think of it, they’re really good design principles in that they are all reversible i.e. you could imagine the polar opposites being design principles elsewhere.
This is relevant to my interests because I think I’m supposed to be a senior developer. Or maybe a technical director. I’m really not sure (job titles suck).
Anyway, I very much appreciate the idea that a technical leadership position isn’t just about technical skills, but also communication and connectedness.
When we boiled down what we’re looking for, we came away with 12 traits that divide pretty cleanly along those three areas of responsibility: technical capability, leadership, and community.
For someone like me with fairly mediocre technical capability, this is reassuring.
Now if I only I weren’t also mediocre in those other areas too…
Well, this pretty much sums up the front-end team at Clearleft:
I’ve often said that at Clearleft, development is always in the service of design. And like Brad, I often find myself defining that work by what it isn’t:
They understand UX principles and best practices, but may not spend their time conducting research, creating flows, and planning scenarios
They have a keen eye for aesthetics, but may not spend their time pouring over font pairings, comparing color palettes, or creating illustrations and icons.
They understand the importance of backend development, but may not spend their time writing backend logic, spinning up servers, load testing, etc.
This could come in useful for updating the Clearleft website.
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.
The truth …it burns!