On Big Picture Thinking in Web Development

Published on November 22, 2017 (↻ February 5, 2024), filed under Development (RSS feed for all categories).

As a former Googler I’ve been exposed to big thinking, by, as Larry liked to say, moon shots. As a student of Gary Keller’s The ONE Thing, I’m trying to learn more about big thinking and clear focus where I can (it wasn’t always like this, and I’ll share more about my dilemma). But here and humbly I want to briefly talk about big picture thinking. About thinking outside the box. In tech. Using five examples.

Contents

1. Selector Performance
2. Maintainability
3. Design Consistency
4. Accessibility
5. Vision

Selector Performance

I much like this example, I had also mentioned it in What We Should Teach Up-and-Coming Developers.

Years ago, performance evangelists—notably Steve—studied the performance of selectors and found that the universal selector is most expensive performance-wise. The instant response from our community was to get a collective nervous breakdown and YouTube-style troll anyone using universal selectors and: make everyone write more complicated, less understandable CSS code. Steve hadn’t suggested to do that—he had simply done important pioneering work—but the thinking became “slower = bad,” without noting how no one had style sheets so big as to even notice an effect of poor selectors. I still don’t want to pin this on anyone, but rather say that we, as the more experienced members of our field, should have probably stepped up sooner and more vocally saying that yes, selector performance differs, but no, don’t change anything, don’t sacrifice good CSS engineering practices for imperceptible performance gains. Big picture thinking.

Web performance can impact how we write CSS, and as such it’s useful to investigate what impact that is exactly.

Maintainability

Maintenance is important and so do we need to make sure that code is actually maintainable. In the “first paradigm” of web development, maintainability hinges on lean HTML and strict separation of concerns. But being that strict, as the maintainability specialist has a tendency to be, shifts a lot of complexity and responsibility and also the maintenance burden into the neighboring code—notably, into style sheets and scripts—and as such has to be gauged carefully, demonstrating contextual, big picture thinking. Example? An extreme (but nowadays more palatable) case is that of avoiding any use of IDs and classes in the markup. With ever more powerful and better supported selectors, this has definitely become a viable option, but the simplicity this can bring on the HTML end does make for a superb (but now less drastic) increase of complexity on the CSS end.

Maintainability is asymmetrical in parts, as such the effects of good maintainability may be felt somewhere else, and for that reason we need to carefully assess the effects of maintainability recommendations before making them.

Design Consistency

I haven’t worked with any people lately who would have pushed for, even talked about “pixel-perfect” implementations of websites. “Pixel-perfect” used to refer to a website’s equal appearance in different browsers, it was briefly discussed in the field under responsiveness considerations, and it still has a place in coding up designer mocks. Here a website or app is pixel-perfect when it completely matches the designer’s screens and ideas. Big picture thinking in a sense of understanding related fields typically means one thing here: that consistency is both the designer’s and the developer’s friend. Consistency is good from a usability point of view, and good from a code complexity point of view. When pixel-perfect means that a button that accidentally sits five pixels lower on one mock than on the other has to also be coded this way, instead of achieving better design consistency and simpler code by granting buttons the same placement, then something’s wrong.

Web design affects how we write HTML and CSS, and as such it’s useful to understand how HTML and CSS are written when designing websites, at least when accepting and approving them for release.

Accessibility

Accessibility takes up a special status for not only is there a moral side to it but also a legal one; and with that lopsidedness (an observation, no judgment), there’s no evident counter-weight in terms of assessing accessibility norms and techniques from the view of their effect on other disciplines in tech—re: big picture thinking. Accessibility has been super-charged so that often, only technical unfeasibility is taken as an argument. Again, I wish to only note the particular situation here, though I believe that we’ve seen large effects on the way we code because of it. The end may justify the means (just once), but the accessibility end here is, particular.

Accessibility is critical to allow everyone access to information and services but it affects many parts in professional web design, from content to design to code; as such, while we want to make accessibility an absolute priority in our work, we need a solid understanding of these effects for the accessibility norms and methods we put in place.

Vision

Vision, here, refers to our idea of web development. If we have one, because “get it done” or “make it work” are not visions; they are mere pragmatism. I’m not sure I want to try a bulletproof definition of “vision” here but a vision would need to provide long-term direction. The idea to build websites of high quality, to build websites that last, to build websites that have a low chance of unnecessary changes seems useful to me, for example; and it may allow us to see how it cannot mean to overshadow everything else, because one of the first things someone technical who’s reluctant to change (for the higher goal and vision of simplicity and stability) experiences is a particular skepticism around design changes (I’ve been there). What we may observe then is an odd twist of someone actually having a “vision” but working in a silo, of: not seeing the big picture.

Our ideas and visions of web development inevitably shape more than just code, and as such they require attention not to impair specific parts of our work and, with that, the greater whole again.

❧ I wish these five examples give an impression for how very different issues, generic and specific, can all reach beyond their perimeter. Yet although I’ve set them up to sound problematic as to require not only a good understanding of the whole range and field of web development, but also a delicate, diplomatic sense for priority and compromise, I don’t demand we always display that sense, that web development was now all about diplomacy, consensus, compromise. No: In my view things start with awareness, and an awareness that our decisions may bleed out into other areas of our work, as well as a curiosity about the effects and alternatives sound like quite a nice accomplishment, too. Web development is an increasingly powerful and increasingly interlinked field, and I believe we can appreciate the possibilities and responsibilities that means.

I’m writing about higher level aspects of web development and design quite regularly. Why not check the archives or one of my books on web development?

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)