One of the hardest learnings from managing distributed teams for several years is that there is no single “best” environment for everyone on the team. Offices will eventually reopen with every individual strategizing what comes next. Some can’t wait to be in a busy, humming office five days a week. Others are cutting the cord entirely, moving away from big cities, and going fully remote. Some prefer a mixture of several days of the week in an office, the rest elsewhere.
It’s a challenging situation because managerial decisions around work environments can favor some and upset others. So over the years of managing engineers all over the country and across multiple time zones, I’ve established three simple rules to set expectations around work. Obviously companies have their own policies, so consider these more idealized or preferred for when there’s flexibility:
For an engineer’s “core work” environment, we treat every individual as a full time remote employee.
Outside of core work, we acknowledge experiences will be different. We strive for empathy, not equality, for this aspect of the job.
As long as we equip individuals to do their best work, location, and in most cases time of day, is entirely up to them.
For engineers building user interfaces, I find there’s heavy emphasis on technical chops and little to none on design comprehension. Yet a subset of design skills can distinguish great from merely good UI engineers.
I’d term these skills “pre-visualization”: understanding design specifications before writing any code, and at a level beyond what designers formally deliver. A big part of pre-visualization is the ability to break down specs into reusable components. You discern visual patterns from existing parts of your app, site, or larger OS, and apply them to a designer’s work. In many, if not most cases, much of the spec maps cleanly to what came before. Common UI patterns like buttons, form elements, and navigation generally repeat themselves. Some will not.
To become a better web UI engineer, study design, communication, and vocabulary. Even if you cut back on some extra technical training, it’s worth it. That’s because the difference between good and great UI work rarely comes from technical prowess alone. It’s distinguished by creativity, visual insight, and sound organization.
Yes, JavaScript and styling fundamentals are important. You need to understand the tech behind your craft. But the solution to a tech blocker can be a tool or coworker away. And once you learn the basics of one MVC JS framework or CSS coding methodology, you can learn another.
Reusability is a bigger issue. Every time you change styling or write a new UI element, consider its impact elsewhere. Think ahead to where the application will grow and how you can cut repetition. It’s more than an blind grep through the code. It’s finding patterns. And visual patterns or usage trends are especially tricky to detect.
Flexbox is a powerful web styling tool, one my favorite recent CSS additions. It’s an effective replacement for hacky, float-heavy layouts. Given its wide browser support and mature feature set, I lean on Flexbox for most project work.
However, I’m surprised many developers stay away from Flexbox. They’re worried about browser support, a big learning curve, or otherwise strange behavior. They shouldn’t. Here’s how to get started.
Inefficient web styling slows performance, adds inconsistencies, and harms developer and designer productivity. But many teams don’t prioritize CSS tech debt; gains are subtle and hard to measure. And CSS testing suites aren’t as robust as those for JavaScript, Rails, and other web languages.
Yet the effort necessary to keep web styling lean and efficient is overblown. The key is abstracting page level styling into reusable components.
Components are distinct groups of elements on a page. Common examples include navigation bars, carousels, and form sets. Components should be standalone, easily moved to different pages without breaking layout. Some styling methodologies substitute other terminology for components, calling them modules or blocks. And the size and scope of component usage differs widely among projects. Large projects, given their size and scope, tend to rely more on components than smaller works.
Web styling advances at a ferocious rate. Vanilla CSS is a rarity. Almost every web presence relies on new frameworks, preprocessors, and workflows. Yet even in the midst of progress, the fundamentals often trip up our work.
Our CSS fights against the natural DOM (Document Object Model) flow. The DOM flows from left to right, and from top to bottom. Block elements expand as wide as possible within a bounding container. Elements grow only as tall as absolutely necessary. The more we resist this flow, the more likely things break.
To avoid this, I follow three rules. Whenever my layout feels janky or otherwise hard to debug, it’s usually because I’ve strayed off course from these guidelines.
Fog Creek software has been running a series of video interviews about software engineering. They cover hiring, firing, culture, and much more. Their most recent post with Kate Heddleston is particularly strong. Onboarding, from my experience, is a greatly underrated topic. It makes a huge impression on new staff, and a wrong move here can set the wrong tone for an extended period.
I could recommend this post to almost any designer who works with front end web developers. It’s surprising how many designers I’ve worked through over my career that have little knowledge of what’s mentioned here, especially this:
It is the nature of the web to be flexible, and with this flexibility comes a degree of letting go of control. The first step in this process is to leave behind the idea of pixel perfection.
Very solid design (with an unusual color palette) to a free 5-week email course. As author Jarrod Drysdale writes:
The Tiny Designer is a course about the big (monumental, even) design that we can make together. Non-designers will learn the important parts of design, so that you can understand what designers do, achieve your goals, and better communicate your ideas. Designers: learn to teach and guide others through your design process so they’ll better appreciate what you do.
I’ve written previously (and given a webinar) about team relationships and how important collaboration is. This course looks like it could share some helpful, related advice.
The Tomorrow Lab’s Derek Johnson writes one of the smartest pieces I’ve read on why sudden interruptions (or last minute, poorly planned meetings) can wreck such havoc on a developer’s workflow:
Developers don’t wear headphones because we enjoy music more than anyone else, it’s because headphones shut everything out and give us the mental space we need to build a very complicated model…
…If you’re an interrupter and you get a terser response than you might have expected please don’t take it personally. We’re just aware of the model starting to loosen at the more precarious points and are getting frantic about the need to get back at work.