More thoughts by Emily Lewis:

• There's this home improvement show called Holmes on Homes, where a contractor visits a home that has been plagued with problems like electrical issues or roof leaks. The contractor, Mike Holmes, inspects the house from its foundation to its insulation and identifies the culprits of the issues.

  99% of the time, the reasons for the problems with the home is that the original contractor simply did a shitty job. Sometimes, the shitty job can be blamed on money: the home owners didn't want to spend the money, so they hired an unlicensed contractor. In those cases, you get what you pay for.

  But most of the time, the shitty job comes down to a lack of fundamentals. Over and over, Holmes points out areas where the original contractor did the job without following best practices or even relying on fundamental techniques and materials.

  And 100% of the time, these homes look great. They appear grand and fancy, with all the modern amenities.

  From the first episode I watched, I immediately drew parallels with the web industry because I don't think the majority of practitioners in our field focus on fundamentals. In fact, I'm not even sure the majority of practitioners even know the fundamentals. And this lack of knowledge and/or execution is damaging our industry.

  Consider the scenario I currently find myself in: I have a client with a custom, in-house-built CMS who needed a design and front-end development for their CMS templates. Straightforward enough. That is, until I got into the templates.

  The HTML was a sea of nested (and nested and nested) <div>s, inline CSS and <span>s for headings, just to name a few offenses. The linked CSS was even worse, bloated with unused selectors, overly-specific selectors and redundant styles.

  These templates weren't developed years ago … not even a month ago. December 2011. By a developer who says he has “many years of experience”.

  While I will hold my tongue regarding the aforementioned developer's actual "experience," this situation is far more common than I think people realize. Especially if you find yourself insulated by the web standards bubble, where we all talk to each other and buy each other's books and read each other's blogs and work on projects where standards are a given.

  Amongst "our own" we think everyone is passionate about semantic markup or that everyone cares about progressive enhancement or even that everyone already knows how to build with standards. But this, sadly, isn't the case … especially in an industry where skills are overwhelmingly self-taught.

  Outside the web standards bubble I like to reside in, the web seems like the Wild West. Standards? What standards?

  If a <span> gets the job done, who cares about semantic markup? If you can't get your specificity right, use !important and use it everywhere! If text won't indent, throw five <div>s around it and give each padding! If a column won't align, put it all in a <table>. Who cares if it doesn't work if JavaScript is disabled? Who cares if a blind user can't turn off the audio that started playing on page load?

  Pedantic? Perhaps. But though these things may seem small, they are actually a big deal. For me, as the front-end developer who has to work with that kind of crap, I get frustrated and I tend to hate my job in those moments. But that hassle isn't my main concern. It's the cascade effect this kind of development leads to.

  It's now a big deal to my client, who has to pay me more because working in such convoluted markup and CSS takes more time than the alternative. It's now a big deal to that developer, who is has a very unhappy employer.

  But even worse, it's now a big deal when my client talks to other prospects or considers future work. Because, from my client's perspective, he's paid two developers and still doesn't have a solid system that meets his needs and is easy to maintain.

  No, it isn't a bomb that goes off to destroy our industry. It's a trickle of water that slowly (but surely) erodes opportunities, trust and perceptions of value.

  And let's not forget, it just isn't possible to build something awesome on a shitty foundation. Whether it is a house or a web site, the latest techniques and trends require a solid understanding (and execution) of fundamentals.

  Take responsive web design. If you don't understand the basics of the box model and how an element's true width is determined, good luck getting a fluid design working before you bang your head so hard against your desk you pass out.

  Fundamentals are important. Not just to sate the pedants and standardistas, but to ensure that we all have great opportunities for work. To ensure our clients feel satisfied with their investment and remain positive about future development with people they can trust. To ensure that our field is respected so that we can all earn pay commensurate with our value.

  I'm hopeful efforts like Move the Web Forward will help slow the steady stream of crap that plagues our industry. The project offers a variety of fundamental ways designers and developers can get involved to make our industry (and the web) better. Please go check it out, and then spread the word far and wide.

  Pretty please? Because I want to dream of a day where I never again encounter 20 nested <div>s inside a <form> that encompasses everything between the opening and closing <body> tags, all of which styled with inline CSS.

  Continue Reading

  Friday, 27 January

• One of my favorite parts of developing web sites is working with markup. HTML fascinates me because it is deceptively simple. How it impacts assistive technologies, browsers and devices is an ongoing journey of education. Understanding the semantics is challenging, yet satisfying, like the New York Times Sunday crossword.

  And my fascination has only intensified with HTML5.

  So I find it particularly frustrating when I read articles that poo-poo the value of semantic markup, or whine that it's too hard to figure out whether to use <article> or <section>, or complain that something in the draft HTML5 spec isn't where it "should" be.

  If semantic markup and HTML5 is confusing to someone, it only suggests to me that someone needs a bit more experience and knowledge. My first site with HTML5 took at least three times longer than if I'd stayed with good old XHTML Strict. But this experience didn't leave me believing that it was pointless to attempt writing more semantic markup. That's just how it goes when learning something new. Not acknowledging a learning curve and blaming the technology doesn't do anyone any good.

  And let's not forget, HTML5 is a draft. Even once it's formalized, that doesn't mean vendors are going to magically support everything all at the same time. In our industry, this is just how it is. Complaining won't change that, but it certainly could discourage other people from learning something new.

  I get that it's human nature to bitch. I'm a pro at it, myself. But when it comes to helping move things forward, bitching is at the bottom of the list. At the top of the list: education and openness. That's what has helped me move forward in my career.

  As I build more sites with HTML5, I continually get better and the semantics make more sense to me. Through this process, I'm becoming a craftsman (craftsperson? whatever …). I'm a better developer because of the struggles I had learning and the challenges of staying up–to–date with a draft spec. But the best part is I'm differentiating myself from the folks who don't care to master the craft, which means more and better opportunities for me.

  Continue Reading

  Saturday, 18 February

• I often find myself in absolute awe of my colleagues' work. But when I was still new to web development, it wasn't just the work I was in awe of… it was the people too. I put those folks on pedestals. And the fact that I only “knew” these people online made it easier to idealize them and even hold them to standards of perfection.

  It wasn't until I attended my first conference that I realized how this mentality was hurting me. I was terrified to introduce myself to people I admired and genuinely wanted to know. And because I believed these people were somehow better than me, I wasn't pursuing opportunities to challenge myself and be a better designer and developer.

  Over time, I also began to suspect that this mentality hurts the people being idealized. The negative tone in our industry — that doesn't seem to be getting better — can't be blamed entirely on the easy firing off of casual insults on Twitter. I wonder if it's because of idealization and expectations of perfection. When someone is flawed, or makes a mistake or simply doesn't meet someone else's expectations, why is the response anger and name-calling?

  Maybe it's my age and the glorious maturity that comes with it, but today, I'm more interested in connecting with my colleagues than putting them on pedestals and judging them when they fall off those pedestals. It not only makes it easier for me to understand them, their work and their decisions, but it makes it easier for me to have meaningful relationships with people I admire. And those relationships have given me far more — both professionally and personally — than my youthful idealization ever did.

  Continue Reading

  Tuesday, 27 March

• If there is one thing that is guaranteed to damage — if not doom — a project, it's ego.

  Consider the project manager who hoards information because only she knows what's relevant to other team members and when. Or the new developer who just joined the company and wants to change established procedures because he knows how to do things better. Or the designer who won't consider critical feedback because she knows what she delivered is exactly what's needed.

  I've worked with all of these types of people. In fact, at stages of my career, I've even been these types of people. At those times, I thought I was being passionate or committed to the project. But the truth of it was, I was letting my ego drive. And my ego wasn't interested in considering anything external. Because that's how egos are.

  Egos don't care about requirements, timelines, budgets, user needs, limited resources or legacy systems. They don't care about other opinions or ideas. They are roadblocks to everything essential to making a project successful, especially compromise, collaboration and communication. And, worst of all, ego keeps you from growing. Your ego won't let you learn something new. Or see a different perspective. Or even get inspired.

  Knowing this is so much easier than doing something about it, though. It can be hard to distinguish your ego from your opinion (or passion or commitment). But it's just as important to hone that skill as it is to keep up with changing technologies, because employers want someone with a point of view who is open to other points of view. Clients want to work with an expert who listens to them and considers their realities. Colleagues want to work with someone who has great ideas and welcomes others'. All of us want to be inspired, but not if it means tolerating assholery.

  One of the simplest ways to keep ego in check is to take your time. I've learned to never respond immediately to a change request or a demanding question. Ego is always ready with the first answer, which is rarely the most thoughtful one. A little bit of time can make the difference between an ego-driven reply and a well-considered response.

  It also helps to keep your focus on what's important. For example, if I feel myself getting defensive when a client wants to change a design, I try to shift my focus back to the client and what he needs and wants. This doesn't mean sacrificing my expertise or the project goals. It simply opens me to communication, which is the gateway to a successful project and a happy client who wants to work with me again.

  Continue Reading

  Sunday, 29 April

Back To Top

Here are the dates of Emily Lewis's future thoughts:

• Thursday, 24 May
• Monday, 25 June
• Saturday, 21 July
• Monday, 27 August
• Friday, 28 September
• Sunday, 28 October
• Thursday, 29 November
• Thursday, 27 December

Back To Top