In our last installment, we talked about how to build a great portfolio no matter what goes on at your job. This time out, we’ll discuss what to do when your boss is satisfied with third-party code that would make Stalin yak.

Article Continues Below

My team builds stuff for other companies. We handle the server side and outsource the client side to a company that does a pretty ugly job, code-wise (although the look and feel is good). My team doesn’t seem to care what this means for development. For them, it’s a question of price: the product we provide is working, and the customer has no complaints. I don’t have any idea how to make them see my point of view. What can I do? Stuck in the 20th Century

Dear Stuck:

Oh boy, and I mean this literally, do I feel your pain. It’s the same pain I felt personally, on every single project, from 1997 until web standards finally went mainstream sometime in the mid-2010s. And even then, I would still feel it from time to time: such as this one time when a client who shall remain nameless insisted on using a third-party CMS that shall also remain nameless.

The CMS makers assured us that they understood semantic markup and progressive enhancement, and that their product would deliver our painstakingly wrought and torture-tested templates intact. But in fact, the CMS delivered our templates in JavaScript. Web pages wouldn’t load without it. The fact that we’d built a progressively enhanced experience that could run on anything from the latest browser to a smartphone, with or without JavaScript, didn’t matter. You had to have JavaScript running to see this site that didn’t require JavaScript to run.

Logic like that makes me wish I had a nice job in the sewers instead of in web design and development.

I feel your pain every time I encounter a shop or company that brags about its full-stack expertise but writes markup like it’s 1999. Or, just as bad, like it’s 2003: all meaningless spans and divs, half of them there purely as visual hooks, and the other half there because the developers didn’t know what to cut out of the framework they used (and didn’t consider that a problem, figuring that gzipping everything would take care of the performance aspects).

I feel your pain today worse than ever, as three quarters of our industry gets high on these bloated frameworks, and abandons core principles like progressive enhancement and building lean.

It’s particularly troubling when the code schools turning out tomorrow’s coders by the tens of thousands neglect to teach their students the vital importance of separating structure from appearance and behavior; the overwhelming urgency of marking up content semantically so that it is accessible to any person, of any ability, using any device; the genius (and long-term viability) of designing with progressive enhancement instead of targeting specific devices as manufacturers spawn ever more of them; and other fundamental tenets of an open web designed and built with standards.

It also kills me when these schools teach responsive design as a bloated, top-down enterprise rather than the lean, content-first experience its creator intended.

I’ve seen agencies where an HR person who doesn’t understand the web hires designers and developers based on the candidates’ meeting a checklist of skill areas. The more tools and software the candidate knows, the likelier they are to get hired. Understanding of accessible, standards-based design doesn’t even enter the picture.

And then there are places that exist by coding faster and cheaper. The clients of those companies want “something that works.” They need it yesterday and they don’t want to pay what it’s worth.

Above all, the kind of “pretty design but bad code” you’re stuck with, dear Stuck, comes from stone age companies that heavily silo their employees. In such places, the developer’s job is to comply with a list of specifications as quickly and cheaply as possible. The designer’s job is to make it pretty. If there is a user experience person, her job is to create wireframes in isolation, and slip them under the designer’s door.

More than a decade after we won the battle for web standards, too much code is still crap. So what do you do, if your company is satisfied with this crap?

Ethan Marcotte and I dedicated 432 pages to providing rationales why accessible, semantically structured sites designed and built with web standards are the only kind of sites it makes business sense to create. I can’t summarize those 432 pages here, but they are available online and in almost every library in the world, and I humbly commend them to you.

Mr. Marcotte then went on to create responsive web design, which takes these ideas to the next level. The whole world has embraced it, as you know, and there are now hundreds of places to read about it, including many in this magazine (where Ethan premiered it exactly five years ago on May 25).

The future-friendly folks have a wide range of recommendations for the even wider range of devices serving today’s web—from watches to phones to desktop browsers to game consoles. “We want to make things that are future friendly,” they say. So does your company, surely. “By anticipating what’s next, we can react to today’s concerns but also build long-term value for people and businesses,” say the future-friendly folks, linking to articles and ideas you can bring to your boss.

Remember: the future will come whether you design for it or not. If your company charges $300,000 for a website that won’t work on next week’s most popular device, your company won’t be able to stay competitive in this business. It might not even be able to stay in the business, period. After all, clients who pay for sites that break too soon will look elsewhere next time—leaving your company perpetually hunting for new clients in a downward spiral of narrowing margins and diminishing expectations.

Your company’s survival is tied to the ability of the products it makes to work in situations you haven’t imagined, and on devices that don’t yet exist. This has always been the challenge of web design. It’s one A List Apart has taken seriously since we began publishing, and our archives are filled with advice and ideas you can boil down and present to your bosses.

If none of this changes their minds (deep breath! ready?) you need a new job. Because the one you have now won’t last. And because the next one will be far more fulfilling—for you, for your company’s customers, and mainly for the people who use their sites and applications. And isn’t that what this is all about?