Andy Bell

More often than not, front-end developers will focus purely on improving their technical skills. Andy is going to show you a better way by demonstrating how you can produce simpler, more resilient codebases by improving your planning and core skills. Specifically improving how you provide and receive feedback from designer colleagues.

Transcription

(Applause)

Wow.

Thank you.

What an honor.

Thanks so much, everyone.

There’s a couple of conferences that are on the bucket list.(...) And beyond tellerrand is right at the top. So this is a real honor. So should we get stuck in?

Awesome. All right, let’s talk about React.

AI? No? All right, let’s talk about the good shit then.(...) So do you want to get better at writing CSS?

Do you want to get better? Yeah, good. You? Awesome. So how do you go about it? Do you read the specifications boring?(...) Or do you do tutorials?(...) Can be quite boring, especially if you do mine.

Or do you do coding challenges, which are really fun? Or do we do the best bit? Do we build websites?

Hell yeah.

All of those things are really good things to do. But let me throw a little bit of a curve ball into the mix for you.(...) The path to becoming a great CSS developer.(...) In fact, a great developer all around is down to much more than coding. It comes down to how you approach everything else, like communication,(...) giving and receiving feedback,(...) finding pragmatic solutions, and planning.

So I’ve been working with CSS now for nearly 20 years at this point. And a lot has changed in its capabilities.

What hasn’t changed, though, in that time is that the core skills, which are often called soft skills-- which I can’t stand, by the way-- and they’re required to push you to that next level.

So I’ve spent a large chunk of those 20 years as a consultant(...) helping organizations, both global corporations and tiny little startups, write better CSS.

And in almost every single case in those engagements, an improvement of the organization’s core skills was the overarching difference in the quality of output at the end.

So that’s a little bit of history.

So back in the bad old days of web design, aka the Web 2.0 era,(...) we had a pretty bad habit of designers designing pictures of websites in Photoshop(...) and then handing them off to web developers who would try and recreate that picture of a website as a real website.(...) And they’d valiantly try and make it look exactly the same as that picture made in Photoshop.

So even during this period of the web where we could make a reasonable presumption about the browser and the viewport,(...) pixel perfection and design handoff were not an ideal way to design websites, even then.

And it’s a hangover from print design, where everything is finalized and then handed off to the printers.(...) Almost all the time, unless you’re me,(...) the prints would arrive looking exactly like your design file.

And frustratingly, design tools have progressed an awful lot in that time. But that tired old way of flinging a web design over the fence has stuck around like poop sticks on your shoe.

It’s stuck and it will stick around for years to come, especially as tools like Figma actively encourage design handoff with their dev mode capability, for example.

CSS is moving really fast, too, which is great. It’s really exciting. Such a good time to be in CSS.

But what’s not great is that people are starting to feel a bit behind, because there might not know container queries, or anchor positioning, or has.(...) Or the fact that you can vertically center elements in a standard block element now.

Did you know that?

Pretty cool, eh? I never actually used that, but it’s still cool.

And then these people, they feel like they have to stuff their existing skill set with these new features as a priority over everything else.

And I know it’s anecdotal of my experience, but I see very little material on how this new exciting stuff can help the vast majority of people in our industry who are slinging websites for a living.

We see a lot of demoware content, and oh, this is a cool abstract thing you can do.(...) Sorry about this, by the way.

Fortunately, thanks to the algorithmic nature of social media and YouTube,(...) we get lots of content that invokes a reaction.(...) You know the type. You get some knobhead like this, and with a thumbnail, and they were saying, media queries are dead. Long live container queries. And I get it.

They’ve got to make money on this stuff, right? And that sort of controversial content sells.

But I do worry what impact this is having on people that are brand new into the industry, who are spending all of their time learning new syntaxes to get ahead,(...) rather than refining those all-important core skills.(...) And then they watch a video like this, and they get even more confused.

We’re also quite bad at communicating. It’s not our fault, though. Tools are geared towards us not communicating with each other, and instead just executing.

I’ll turn my attention to Figma’s dev mode for a second here.(...) Instead of tackling that problem that handoff is not really compatible with the flexible nature of the web,(...) the tool focuses instead on highlighting pixel perfection more efficiently for developers.

Communication isn’t really helped by the nature of the business we work in now, either. There’s a lot of KPI chasing and a rush to deliver features, which naturally overworks people.

The last thing people want to be doing is attending even more meetings and writing even more emails, right?

So to combat that, a wealth of tools are deployed to distill features into the deliverables and not the impact of those deliverables.

All you have to do is think how many products have shoehorned AI into the system with a clear disregard for how that probably isn’t even helpful for anyone other than the fucking shareholders.

But it’s not all doom and gloom, I promise. I’m not going to stand here and run for 45 minutes.

I’m just setting the stage for us, because it’s really healthy to look at the industry and say what you see. I think we’d actually be a lot better off as an industry if more people did that.

And don’t be downbeat.(...) I’m going to show you how to work in these antiquated systems more effectively.(...) Design, handoff, and a focus on the tools is not going to go anywhere anytime soon. So we might as well learn to excel within the bounds of those, right?

And if it all does go away, which we can only hope, there’s lots of transferable skills that I hope to give you in this session that will see you right for years to come.

It’s a bold statement, but I really hope after this session you won’t be the same as before I opened my gob. I mean, after listening to 40 minutes of a Yorkshireman talking, it’s a transformative experience for a lot of people, right?

(Laughter)

(...) Maybe not in the best way. And I’ll be really delighted if in the future you can go back and say, you know what? That talk that Andy did in Berlin actually triggered some genuine positive changes around here. And even if only one person in the audience today benefits from this, I’ve done my job.(...) So let’s get stuck right in.

OK, so what I’m not going to do today is going to stuff hundreds of slides down your throat and show you loads of CSS code.

I’m not going to show you any CSS code today, which for someone who’s seen me speak before, that’s usually what I do. I speak at 1,000 miles an hour,(...) slide after slide after slide. But no, today we’re going to have a conversation and we’re going to work out what’s actually important and what I think, as someone who’s been doing this for too long, what’s really, really important. And I’m going to go through some principles with you. And the first principle I’m going to look at is communication, because I think that’s actually the most important thing to get right.

So asynchronous communication is critical. In fact, even if you work in the exact same time zone as each other, even in the same office as each other.(...) So I run a design studio, such studio, and we’re a team of four, all based in the UK.

And our primary mode of communication in the studio is Slack and GitHub.

Asynchronous communication is critical, because even though we’re all in the same time zone, we all work in the same company, we all work completely different schedules to each other, because life is more important than work, right?

So that means that we all work different schedules, and we also work with clients all over the world, spread over all sorts of different time zones.

So for example, there was a period where we had concurrent projects running with clients in India, the UK, and the USA,(...) all running at the same time, while we had stakeholders based in the USA, Panama, and we had a freelance developer helping that’s based in Hong Kong, too.

Pretty spread out, right?

So with this time zone spread, getting written communication right was really, really important.

So I’ve got a little quick listicle,(...) just to give us a throwback to the Web 2.0 era, of quick principles I like to deploy when it comes to written communication.

So the first thing is, keep things short.

There’s no need for filler content. Just get to the point. And I know I’m preaching to the choir here in Germany,(...) and I really do appreciate talking to Germans. Yeah, you’re my people.(...) But try not to recreate in-person preamble and pleasantries in text-based communication.(...) Obviously, you can ask how people are, but get to the point, too.

Never ask for too much, either. If you ask for multiple questions, or ask for multiple pieces of information at the same time, it’s really likely that you’re not gonna get the answers that you want. If you need to know multiple things, create a nice thread, and unless it’s an emergency, let your colleague know that there’s no rush to get back to you and have all of the answers ready for you.

Presume people are busy.

This is so important, especially like now. We’re all so busy and so overworked. And remember, you’re not the only busy person. Everyone else is busy, too. And this is also especially the case when you’re dealing with stakeholders and people in positions of management.

They’re spinning a lot of plates.

What you need to know is often way beyond that person’s daily responsibilities, too, which is especially the case with stakeholders, if you work in client services. A stakeholder has already got a full-time job,(...) and then they’ve got you going, can you tell us how big the logo needs to be? Can you tell us what color to use? Do the job for them and then ask them things that are really important instead.

And if a request is blocking you, there’s a very good chance you’re asking too late.

So effective planning and scheduling of your workflow should surface things that you need to know well before you actually need them to do your work.

This is the most important principle that I want everyone to get, is you should never ever make it personal.

Because if you make it personal, you’re just gonna upset people and get the backs up. It’s unnecessary and it harms relationships almost permanently, too. There’s never a need to be an asshole.

And then finally, be descriptive and never presume prior knowledge.(...) So I can tell you from working with the smallest and largest organizations,(...) the people’s knowledge of stuff is spotty at best.

Don’t presume people have the same level of knowledge as you do on specific elements of the work either.

All right, so I know there’s one of you in here.

So we use Slack internally and I know a lot of you will do too or some other cursed chat tech.

And these principles are universal regardless. So this is a really important one. Don’t be a high guy.

So let’s just break down.

(Audience Applauds)

Thank you.

There’s one thing to take away from today. Don’t be that dick.

So let’s break down what’s wrong here. So firstly, I’m presuming the designer is both online and staring at their messages, which is almost certainly not the case.

Just sending the high can be a source of anxiety too because they might be quite anxious that they’ve done something wrong or they might rightly just be pissed off that you’re distracting them for no real reason.

You almost certainly are going to distract them with this approach because they’re likely just gonna be sat there waiting for you to continue.(...) So here’s a better way.

So there’s a few of these and I’m gonna stand and read them because how awkward would it be if I just stood here in silence and waited for you all to finish? So I started a new chat and I said, hey, hope you’re good. I picked up a couple of bits on the design which look really great by the way.(...) I’ll create a thread here so we can chat it out as and when you get time.(...) And design comes out with awesome, that sounds great. I’ve got some free time later so I’ll check in then.

So the difference here is big. Like we’re being descriptive and we’re not asking for too much.(...) And we’re also presuming that the designer is busy. That’s three of the six.

And we kept it short too.

Not bad, we’re four. We’re also keeping the tone neutral and not personal. And finally, we’re working in advance of when we need the information, therefore getting the full house.

The main thing though is the designer knows that I’m gonna thread out the notes. So I’m not expecting an immediate response either.(...) And they’ll probably just add a quick to do item to the list and then get back to what they were working on without being massively distracted.

There are times when you do need a quick response that I get it. I run an agency, my life is quick responses.

But there is ways to do it right and to do it wrong too.

So for example,

I need you to fix the colors on the designer immediately because of accessibility.(...) The client is pissed off.

The designer rightly comes like, "What do you mean by because of accessibility? "What did the client say?" So all I’m doing here is I’m panicking the designer.

Even if you are really stressed, you should never project that onto other people.

You can get urgency from people without doing all that too. So let me show you how.

So hey, I’ve been speaking to the client and they’ve picked up some color contrast issues with the latest round of designs, specifically on the smaller text. The colors.conf are on to back out double A, which is a requirement for this project. Notice how there’s a link there because I’m not presuming knowledge.

It’d be really helpful if you can make some adjustments quite urgently because the client is rather concerned. I’m here to support you if you need help with testing, et cetera. Sorry to break you off from what you are doing.

The designer comes back with, "Ah, my bad, I’ll get on that ASAP.(...) "Thanks for the link too, that’s really helpful. "Do you have any recommendations or tools "I can use in Figma to test compliance?"

Sure thing, I’ve found Stark to be a really, it’s a really good tool, by the way, really useful all-round good accessibility tool.

Designer gets it installed and jobs are good.(...) So see how much more productive that is. We’re not attacking the designer here, but instead we’re being descriptive and we’re not asking too much of them. And we’re offering help.(...) So this becomes less of a, "You have done this wrong," and more of a, "There’s an issue, "but it’s quite trivial to fix, "and we’ll fix it together."

In the prior example, the designer could have easily and understandably felt attacked. Whereas here I’m communicating the urgency, but I’m rightly making it a team issue.

Sure, it’s gonna be the designer that’s gonna need to work out these new colors,(...) but by offering tools and testing support, the designer will feel supported with that as well.

All right, this is my favorite tool of communication.(...) I know that at least 99% of the people in this room hate email,(...) you’re just doing it wrong, it’s a skill issue.

All right, okay.

Let’s cover this favorite medium of mine, the best medium.

Oh yeah. Aside from the relentless amount of emails that we get there on a daily basis, there is a real problem with email in the sense that people fill them with absolute cruft.(...) So let’s take that same conversation context, the accessibility issue, and apply it to email.

So, hi designer, I hope this email finds you well.

I hope you’ve had a fantastic weekend.(...) Did you get up too much? The family and I went to the beach and had a great relaxing time.

For the project, the client has raised concerns about color contrast and accessibility.(...) You can read the email thread below.

Best regards,(...) Andy Bell,(...) front end developer, made of company.(...) We are a carbon conscious company, so please don’t print this email.

(Audience Laughing)

It’s funny, but it just hurts.

So, you notice all the cruft in this email, like it’s great to talk about weekends, for sure, but not an important emergency email.(...) In fact, I’ve talked more about my weekends than the actual problem, which is barely even covered. I’ve not even talked about it. I’ve said go and look in the email thread yourself.

And you’ve got to remember that people’s inboxes are generally rammed full of email.(...) So be a good colleague and make yours concise and effective, (...) like this.

Hey, I’ve just been speaking to the client and they’ve picked up some color contrast issues with the latest round of designs, specifically on the smaller text.

The colors that conform to WACAGAA, which is a requirement for this project, it’d be really helpful if you can make some adjustments quite urgently because the client is rather concerned.(...) I’m here to support you if you need help with testing, et cetera. Sorry to break you off from what you’re doing. Right, I know a lot of you had a late night last night.

Might be hanging today. You’re not hallucinating though? I promise, it’s fine. This is exactly the same as the Slack message from earlier.

(Audience Laughing)

Just because it’s in an email, it doesn’t mean you have to write it differently. You’re not writing to a pen pal. You’re writing to a colleague.

So treat emails much like messages, especially internal email,(...) and you’ll do lots for reducing people’s overwhelm. My favorite emailers are the one sentence emailers and if one of you out there is there, thank you, because that’s what I am too.

But another important point here is that you’re more likely to actually get a response to this email instead of the designer marking it as red and then carrying on with the work that they were doing.

All right then, so that’s a communication tick. We’ve done it. Let’s now look at feedback, the most precarious of things in our industry.

So as we covered earlier in this session,(...) it’s these core skills like communication that are crucial to writing better HTML,(...) CSS, and even JavaScript.

You might be thinking like, how?

And allow me to try and change your perspective.

By nailing communication, you will by proxy simplify and sanitize design work.(...) This results in simpler code, which is what you should always be aiming for.

Simpler code is easier to maintain and it’s harder to break. It’s more likely that it’ll handle the plethora of conditions that can break it too, such as overloaded content, dodgy connections, and clashing browser extensions, all of which happen every single day, no matter how much you put your head in the sand, that is the reality of the internet.

So what we’re gonna be avoiding is writing code that when you came back to it in the future, you go, what the hell is going on here?(...) It’s communication, review, quality of feedback, and planning that’ll get you to that almost utopian point.

Dealing with and giving feedback well is really important. So let’s just have a little look at that for a minute.

So I’m a designer by trade, as you can see.

And I don’t really get to do it much anymore. I’m not allowed to don’t let me anymore. But I had a chance to express myself here. I think we can all agree.(...) It’s absolutely stunning, isn’t it? It’s the passion of the high five that gets me. You can really see the synergy.

Anyway, so related to our principles of not presuming knowledge when providing feedback to a designer or another stakeholder like a project manager,(...) you need to explain in detail what the issue actually is.(...) So let’s take a look at this stunning website.(...) There’s a hero at the top of the page. And you might notice there’s four little dots there which indicate that we’ve got ourselves a little slider.

Auto-plane, of course.

And these are actually really common in the real world because they’re often implemented to squeeze as much content as possible above the fold. Now, I don’t know about you. I’ve never folded a website in half.

(Audience Laughing)

That’s how you break your screen.(...) So don’t do it. But we still believe in the fold for some reason. And it is a really tired design pattern. But feeding that back to the designer alone is just not gonna cut it. So here I am.(...) We shouldn’t use a slider on the homepage because it’s such a tired old design pattern.

The designer comes back with, “Well, it’s what the client wants and it’s what they signed off, so there’s not much I can do.”

This has got us absolutely nowhere. All we’ve actually achieved in this bit of communication is we’ve got the designer’s backup.(...) So any chance now of making any positive adjustments is probably gone. And guess what, everybody?(...) We’re building ourselves a slider.

(Audience Laughing)

Horrendous. So sure, you can keep prodding away like this. You can keep telling yourself this is how you do it and being an edgelord.(...) But really, all you’re gonna do is keep creating more problems. So here’s what I do instead.

Hey, the designs are looking really great. There’s one section that I’m quite concerned about and would like to understand the decision more. With the homepage here, our slider, I’ve got concerns about potential accessibility problems, overwhelming user experience.(...) Here’s a useful quick read, just a link to that, though, user Caron and Sol website, on the subject to give you more context about my concerns.

So design comes back with, “Ah, I’ve got you.” So to give you some context, this section was a nightmare to get over the line because different stakeholders all thought their departments were equally important as each other.(...) Ain’t it?

I get that and really feel for you, having to navigate that situation. Considering their departments are so important, they’ve not produced much content for them, have they?

(Audience Laughing)

This is like a trauma,(...) reliving it right in front of you all. I start crying, just ignore me.

So design comes back with, "Not at all. I’m gonna have to produce a background for each one too, which isn’t ideal, which of course results in a problem there. Is we might not achieve the right levels of color contrast with the text on each slide, especially if this is CMS content. It might be right when we hand it over, but that could change really quick and oh boy, it will change.

So maybe we should get some data to support our concerns. It’ll be worth looking at what the average session time is on the current homepage because we’re going to have to wait at least a few seconds before the next slide changes, right?(...) We could argue a user will likely never get beyond the slide. I can tell you right now, this is canonical advice. The user will never get beyond the first slide.

(Audience Laughing)

(...) Trust me, we’ve tested it.

So design comes back with, “Well, that’s a good shout.” The problem is, is that they still want an impactful hero, in quotes, and to promote each department equally. It’s like a fever dream, isn’t it? I’ll get some data for us to look at and I’ll have a think about other design ideas too in the interim.

So what a designer doesn’t need in these situations is hostility and instead they need ammunition to go backwards.

Developers are actually in a really strong position to provide that ammunition because they tend to have a more broader understanding of all the problems that can arise in the browser.

Always remember, you’re a team unit. You’re not competing individuals.

All right then, so a few days have passed and we’ve gone and built this beautiful website.

Now, I just want, while I’m talking, read the copy because I spent so long writing this copy(...) and I was grinning like a Cheshire cat all the way through it.

All right then, so let’s just imagine for a moment that a new design approach arrived to replace the slider.

And the designer came up with this cool new pattern that we still maintain the eye-catching hero which I’ve cropped the high five out on desktop.

But then we’ve got underneath that we’ve got a grid and we’ve got four columns in that grid and each item’s got a heading, a subheading and a little summary and then a little learn more link because we need to learn more link, right?

So on smaller screens, that grid does remain but we’ve got a little overflow pattern. So you can see a little bit of the second item peeking through as it suggests, why do you have a little look at my content too? Okay,(...) so I’ve been built, it’s looking great.

But the problem is I’ve missed one really important detail.(...) The content’s supposed to shuffle on each page load because remember, every department’s as important as each other.(...) So every department wants their card to be first on small screens.(...) And we’ve not implemented that because we’re lazy developers.

So the designers picked us up on that and they said, hey, the new homepage section looks really great, I agree. But the first grid item is the same on each page when I look at it, even after refreshes. The client really wanted those to change on each page load.

I can’t do that because they’ll all shift around. Large manipulations of the DOM aren’t good either.(...) This is straight up useless. Like what is the designer expected to do with this?(...) In these situations, it’s all about landing on a solution that pleases everybody. So try this for size instead.

So I’ve got the same bit of feedback, which is good feedback. And now I come back with, thanks. Yeah, I struggled to get this working because I’d have to rearrange the content with client side JavaScript.

The problem with that is there’s a good chance that JavaScript will fail and or not be available. It’s true, by the way, it will not be available.

It’s why I got the overflow scrolling setup working with CSS only.

If JavaScript does work, big emphasis on if, manipulating the DOM like that can be quite clunky,(...) especially on low-powered devices.

And as the designer comes back, we’ve got it. The reason I wanted to randomize the order of the content is similar to why they wanted a slider in the first place. They’re adamant that each department is as important as each other, and they don’t want one department being prioritized over the other. It’s really frustrating because they won’t move on that.

Sounds very frustrating to me. The content comes from a CMS, but the site is built with a static site generator. Notice all the links in these chats. This means it’s built once, and then a static HTML page is served to the user.(...) What if they change the order of the content in the CMS quite regularly, which would trigger a rebuild of the static site?

It’s a good idea, but I know they won’t wanna do that. They’re really quite lazy as well as demanding.

Like I said, I’m on the verge.

Okay, how about this? We set the site to rebuild every hour with automation, and when it does rebuild, it randomizes the order of the content each time. Now that’s a good idea. No client legwork required, and they get what they want in essence. Let me run it past them.

To see how much more productive that is, not only have we avoided implementing a slider in the hero unit, but we’ve also avoided writing some nasty-ass JavaScript that will almost certainly fail too.

This is the trick with feedback. Use it to make things better together.

I know each project has different text stacks and different challenges. You don’t wanna see what I’ve seen doing client work for the last 20 years, nearly.

But the point I’m making is that collaborating rather than battling will likely get you that happy medium that’s importantly simple.

Trust me, designers want the best for users as much as you do, so help them achieve that rather than being a prick.

Okay, descendants does make sense, I promise.

But time management people on LinkedIn might tell you to create a complex project management system with statuses and velocity tracking, which is bullshit.(...) But all this stuff does is abstract away what’s actually important when producing websites, apps, and design systems, and that’s caring for the people that you’re building these things for.

And also not creating yourselves a long-term maintenance nightmare with oodles and oodles of technical debt.

It’s tempting when deep in the woods of a project to descope to save time, and yeah, that happens a lot in my line of work in an urgency.(...) But all of this is to go faster and to get to the finish line. And the compromises made to go faster are often unseen and more horrific than you could ever imagine until later down the line.

Then there’s chasing the pack,(...) not getting left behind, as it were.(...) My mind immediately goes back to so-called AI.

And I’m thinking about when very large corporation, Google,(...) chasing down AI like I imagine a dog chases a butcher’s van down the road if there was a string of sausages hanging out of the back.

The desperation to not be left behind results in not only humorous missteps with Google’s AI summaries on search, but also potentially damaging outcomes as users were being told to add glue to the pizza sauce so the toppings didn’t fall off.

And the LLM learned this from a shitpost on Reddit, where there was an in-jerk where people used to make shit up, but LLMs don’t understand that because they’re dumb.(...) And the point I’m making is that sprinting towards a goal, be it profit, deadlines, or any other outcome, is that moving very fast without proper planning, research, and analysis is more likely to result in harm rather than help.

So let me tell you a story.(...) Gather around and give me a moment to share one of my personal failures in this industry.(...) We go back to 2019 and I was a consultant and I assisted on a design system build for a large, well-known cruise travel agent.

Aside from the frequent giggles, as regular cruise travelers describing themselves as cruisers, honestly they do, it was a resoundingly horrifying project.(...) Instead of all the usual steps of research, discovery, analysis, and thorough planning, we dove straight into the build because of a very tight, hard deadline.

The problem is, is that this design system had been solely designed in sketch by extremely talented designers, really nice people, but it had really limited technical awareness.

So unfortunately, that resulted in lots of inconsistencies that would be very exposed if we’d have done proper design system planning.

One of those inconsistencies, for example, was there were multiple layout systems depending on which designer touched it last.

Not to mention there were various conflicts in technology choices that were never truly ironed out because I just ran out of energy arguing with them.(...) So developers went rogue with their own choices, which is just great fun.

I could and I should have thrown the anchor down on the build, obviously selling analogies, but I didn’t. I went full steam ahead instead.

In my mind, we get it done and then we survey the damage after the fact.

What an idiot.(...) So the damage was extensive. We had not one, not two, but three different grid systems. We had components that were so fragile that they would blow up at the mere hint of any stress.(...) And so many technical inconsistencies and lack of technical documentation that it would be a miracle if someone could even make an effort at maintaining it in the future.

Why am I telling you this? Why would I make myself so unemployable?

I want you to learn from my mistakes. The reason I’m talking about all of this is because I’ve experienced so much bad in this industry and the vast majority of that bad was entirely avoidable by taking just one step back, slowing the process down and making better decisions with a clearer mind.

As the old saying goes, (...) slow is smooth and smooth is fast.

“Hey, Andy, you’ve barely mentioned any CSS.”

And that is by design.(...) With a slot like this, I wanted to make sure that I gave you the really important information. I’ve done so many talks over the years on CSS specifically. It’s about time I talked about the really important stuff that sits underneath CSS.

CSS is really important, though, in writing scalable, maintainable frontends. But what’s more important in achieving that goal is that the core skills. It’s why this talk is called "Get the Core Right" and the Resilient Code Will Follow.

I couldn’t in good faith stand up here and tell you to write your CSS specifically in your organization,(...) because every organization has different goals, different text tags, different problems.

I need more time to be able to deliver content in a consultancy context instead, wink, wink.

You might think, “Well, I’m working in an industry standard way.” But you’re not, because there’s no such thing.(...) Because every company has different outcomes, different goals, and different text tags.

You might be working with web standards, you better be.

But there’s no industry standard way of working,(...) because everywhere’s different.

But if you focus on improving your communication, improving your feedback loops, and invest more time up front to planning, prototyping, testing, and research,(...) your code bases will be smaller, they will be simpler, and they will be easier to maintain.

Don’t get hung up on the tools over dissecting every piece of a project, too.(...) Sure, if there’s time after getting the core right, you can spend time working out which framework you want to use, or whatever else gets you. The point I’m making is that the core, the planning, the prototype, the testing, the research, should be the priority of everything else at the early parts of a project.

It’s all about iteration, too.(...) So, for example, when you’ve decided which hot framework you want to use, you better then make sure that you go back to the start of the drawing board, do the thorough planning, do the thorough prototyping, do the thorough processing, and then you can do the work. Do the thorough prototyping, do the thorough testing, because the framework will pull your pants down at some point, and you want to make sure that happens in the really early phases of a project, rather than when you’re right near the deadline, because you can still change your minds at the start.

This is all content from my course, Complete CSS. I’ve made all of that stuff free now for everyone to read, so go ahead and check it out. But that’s me. I’m Andy Bell. Thank you very much. Cheers.

(Applause)