CSS isn't where you become a better developer (1m02s)

Andy Bell opens with the deliberate misdirection: this isn't a CSS talk. After 15 years of consulting on CSS at small startups and global corporations, the difference between teams that ship good work and teams that don't is the soft skills — planning, communication, feedback, finding pragmatic solutions.

"the path to becoming a truly great CSS developer or general front-end developer is down to more than coding"

"an improvement to those organisations' core skills was the definitive difference in the quality of output at the end"

"I only say CSS in this talk about five times"

The bad old Photoshop-handoff hangover (2m05s)

The early-2010s pattern — designer makes a picture in Photoshop, throws it over the fence, developer pixel-pushes it for days, designer issues a three-page snag list — is still going strong, because Figma's Dev Mode has institutionalised pixel-perfect handoff rather than fixing the underlying problem.

"pixel perfection still wasn't the ideal way of designing websites even then"

"a hangover from print design, where everything is finalised in design tools, and then almost all of the time... the prints would come back looking exactly how you designed them"

"Dev Mode's done [is] just make pixel perfection more efficient for developers"

We're keeping up with new CSS for the wrong reasons (3m42s)

CSS is evolving fast and there's an industry-wide impulse to keep stuffing the skillset with :has(), container queries and the rest because Media queries are dead, long live container queries is the kind of headline that gets clicks. The casualty is the core skills.

"the algorithmic nature of Twitter — RIP, join Bluesky — and YouTube, we get lots of content that invokes a reaction"

"I do worry about the impact that that's having on people who are trying to stuff their skillset with this new syntax, and they're putting aside those core skills"

"tools are geared towards us not communicating, and instead just executing"

Async communication principles (7m24s)

Six rules: keep it short, don't recreate in-person preamble, don't ask for too many things at once, presume the other person is busy, never make it personal, and don't presume prior knowledge. Effective even within a four-person team in the same UK town, because everyone works different hours.

"if a request is blocking you, you're probably asking too late"

"effective planning and scheduling of your workflow will surface things you need to know well before they block you"

"folks' knowledge of stuff is spotty at best — don't presume people have the time and the same level of knowledge as you do"

"Hi" guys, urgency, and how to phrase a message (10m26s)

Don't be a Hi-guy — just send the whole message, including the explanation, the link to the WCAG criterion you're worried about, and the offer to help test. Don't panic-message someone with fix this now, because all you do is project your stress onto them. Send the urgency and the context and the offer of support in one message.

"even if you're extremely stressed, which I can attest I often am, you should never project that onto another person"

"you can get urgency from people without doing all that too"

"we're not attacking the designer — we're being descriptive, we're not asking for too much, and we're offering help and support"

Stop filling emails with weekend pleasantries (14m34s)

The world's most polite email opening — hope this email finds you well, did you get up to much at the weekend? — buries the actual problem under four paragraphs of cruft. Treat email like a chat message. The same short, focused, non-cruft message gets answered; the long polite one gets marked read and forgotten.

"it's just so lazy — people's inboxes are generally rammed full of emails, so be a good colleague and make yours concise and effective"

"you're actually more likely to get a response from the designer because you covered all the points that you need to address in that short email"

"just because it's an email doesn't mean you need to fill it with useless shit"

Feedback: sliders, designs, and not being a prick (17m08s)

Two worked examples. Tired old auto-playing hero slider — instead of "we shouldn't use this", ask for context, learn that three department stakeholders all wanted equal prominence, and use a data argument (let's check the average session time; users will never reach slide two) to give the designer ammunition. Randomise the first card on every page load — instead of "I can't, JavaScript would have to manipulate the DOM", propose an alternative (rebuild the static site on a cron, randomise on rebuild) that gives everyone what they want.

"what a designer doesn't need at this point is hostility, but instead, ammunition to go back with"

"remember, you're a team unit, not competing individuals"

"trust me, designers want the best for users as much as you do — so help them to actually achieve that, rather than being a prick"

Slow is smooth, smooth is fast (26m29s)

The closing story: a 2019 design-system project for a cruise-travel agent that skipped the discovery phase under deadline pressure, ended up with three different grid systems and a maintenance nightmare. Sprinting towards a goal without proper planning, research and analysis is more likely to result in harm than help. And the closing tie-back to CSS: focus on communication, feedback and planning, and the code that comes out the other end will be smaller, simpler and easier to maintain.

"slow is smooth, and smooth is fast"

"we had not one nor two, but three grid systems"

"the reason I'm talking about all this is because I have experienced a lot of bad working in this industry, and a lot of that bad was entirely avoidable by just taking one step back, slowing the process down, and making better decisions with a clearer mind"