Forem: Hunter Miller

What Can You Do with Tailwind 2?

Hunter Miller — Tue, 24 Nov 2020 16:26:29 +0000

Tailwind CSS finally announced it's new 2.0 version on November 18th, 2020.

If you've been around the industry lately, you've probably heard of Tailwind CSS, because they seem to be everywhere! But maybe you haven't, and in that case, it's time for a short introduction. If you have, skip to 2.0 Features

Intro to Tailwind CSS

Something that started out as some handcrafted CSS used personally by Adam Wathan became an extremely popular, productivity-boosting CSS framework used by millions over the last three years. The core mindset behind Tailwind is that CSS should be composed of small single-purpose utility classes which pull from a standard set of values.

At first you may think, "This seems like inline styles, why would I want to bloat my markup and aren't those bad anyway?", and while your statement about inline styles is correct, Tailwind's utility classes aren't that at all. Here's why:

By sticking with only classes, styles all stay at the same specificity.
By using classes instead of inline styles, we encourage reuse and ensure that we're sticking to a standard set of values.
While our markup may be larger than those who use other CSS methodologies, we always know exactly what styles are coming from our classes because there is a 1-to-1 mapping.
The breadth of utility classes allows us to write 95-100% of our CSS using just utilities. This encourages a small footprint and very little maintenance overhead.

There are other benefits like increased authoring speed and others that I'd like to cover in a more thorough post later.

In case you're wondering, what does this look like? Here's an example component from Tailwind's homepage:

Now that you've gotten a short introduction, let's get back to why we're here.

2.0 Features

Since this is a major version, it needed a major launch which included not only a teaser and trailer, but also a whole new website and docs! If this isn't maximalist launching, I don't know what is! Let's see the most exciting changes, with a few examples that you couldn't make without customizing version 1.

Theming and Design

I don't think it would be a major version launch if Tailwind didn't touch these two topics because they are the main pillars of why we use Tailwind in the first place. They didn't just touch these though, they brought big changes.

Colors

With regards to theming and design, the biggest of change is colors. The Tailwind team created an all new color palette which includes 17 colors and 5 grays.

This is a huge jump in expressiveness for designs, especially with alternate grays because the old gray was on the cool side. The new sets add two cooler grays and two warmer grays so you can have something that jives better with your design's palette.

Color docs

Dark Mode

Another big change is the new support for dark mode. Tailwind doesn't force one color to another for dark mode, but instead let's you control which colors get applied through the new modifier dark:. This will apply whatever style follows whenever a .dark class is above it.

Dark Mode docs

New Breakpoint and Extended Scales

In an effort to support even more refined designs, the team has added support for a larger breakpoint 2xl which now allows more specification for larger layouts. I often added this as a custom breakpoint anyway. Breakpoint docs

They also added extended scales for spacing, typography, and opacity. For spacing, a few half values were added near the bottom for nudging smaller spacing layouts. For typography, a few values were added to the top end for larger hero text. Opacity had the largest set of adds with steps every 10, and a few half steps at the ends. Spacing, typography, and opacity docs.

A Practical Look at New Theming Changes

I've put together a small demo of landing page hero to show off the new changes. Try toggling the dark class to see dark mode:

New and Extended Utilities

It wouldn't be Tailwind without utilities, and in a major launch like this, we're going to see some new ones. I think both the new forms plugin and ring utilities are big wins for accessibility, because they encourage good practice. The new colors are sure to help us get good contrast!

Forms

Forms have always been a struggle to style. We often resort to hacks and custom implementations with Javascript to be able to make them look good and match our designs. The Tailwind team has worked hard to make standard HTML form inputs able to be styled without custom elements or hacks. There are some limitations here, but I think the result looks great.

Forms plugin docs

Ring

Another issue that we often encounter when auditing the accessibility of our apps is showing clear focus indicators. The default web version of this is accomplished through the outline property. Unfortunately, outline ignores border-radius and isn't quite as customizable as something like box-shadow. The new ring utility will use box-shadow and that will work alongside the standard shadow utilities in Tailwind without overriding them. Our focus indicators can now look as good as the rest of our UI! 💅

Ring docs

Text Overflow

A small change, but still helpful: you can now specify overflow-ellipsis and overflow-clip to control text overflow in a multi-line scenario. Text-overflow docs

Default Line-heights

Something that I feel I'm always tweaking is line-height. I think good line-heights can make or break type styles. In an effort to help improve the quality of typography in Tailwind, the team has shipped default line-heights for each text size, and like always, you can change that with the leading utility. Font-size docs

Practical Example of New Utilities

I've put together a small form component to show off the new utilities:

Internal Mechanics Changes

Quite a few internal changes have taken place, one major one being that Tailwind dropped support for IE11 in 2.0. Given that IE11 has very little representation globally and is officially unsupported by Microsoft, I think this was a good move, especially because it allows them to do even more with the framework.

In addition, @apply can now work with all variants which is a huge boost to anyone who heavily used it. Previously, you were required to implement those variants as you would normal CSS, but no longer, yay!

Two things changed with config. You can easily extend variant's by adding an extend property to your variants config object. This allows you to just add new variants without having to list out all of the default variants which is just a lot nicer.

The other new thing in config is that we can now set default transition timings and easing functions. This allows us to no longer need to specify a duration or easing function if we're just fine with the default, which is probably 80% of the time for me personally.

@apply, variant, and transition docs

The Road to 2.0

Whether you already use Tailwind or you just got converted above, there's a lot to be excited about with version 2.0. A ton of work went into it and it shows in the quality of what was launched.

Creating and maintaining Tailwind quickly became the work of a small company, unfortunately Adam is only so powerful 🤣. He and Steve Schoger needed extra help which they found this year using funds made from their launch of TailwindUI and RefactoringUI. They hired Brad Cornes, Robin Malfait, and Simon Vrachliotis to assist with developing the entire ecosystem that surrounds Tailwind and to push out this new version.

The team's desires for the new version were deliberated at length over many of Adam's tweets, Github issues/discussions, and even podcast episodes from Adam's very own Full Stack Radio. Something especially important to point out is the team's desire to stick to semantic versioning. Creating a new version opens up a lot of doors for change which is great, but that door also closes at the same time. Now the Tailwind team has to wait until 3.0 to make changes that will break, but I think they made good calls on what to include in this version.

What's Next?

If you're as excited as I am, you can head straight to this upgrade guide to dig through what changes you might need to make in your current Tailwind codebase. If you'd like to hear more straight from the creators themselves head on over to their announcement blog post to get an in-depth look at each change.

For some of us, it might not be time to change and that's ok. The current version is still a serious piece of craftsmanship with all the same well-thought features. Version 1.9 will be the last update in version one and will retain support for IE11.

I think Tailwind has proved to be more future-thinking than most frameworks to date including frameworks in other languages. Their attention to detail and quest for excellence shows up in the quality of their work. As a company, they're just getting started. Hopefully the future holds even more new innovations in this lovely little CSS framework, and beyond!

This Dot Labs is a modern web consultancy focused on helping companies realize their digital transformation efforts. For expert architectural guidance, training, or consulting in React, Angular, Vue, Web Components, GraphQL, Node, Bazel, or Polymer, visit thisdotlabs.com.

This Dot Media is focused on creating an inclusive and educational web for all. We keep you up to date with advancements in the modern web through events, podcasts, and free content. To learn, visit thisdot.co.

Front-end Practices That Changed My Life

Hunter Miller — Sat, 25 Apr 2020 20:35:43 +0000

Hey there! My name is Hunter Miller and I've been developing web software for about 6 years now. Along the way I've taken many paths to produce effective software, some that worked well and some that didn't. I've collected those that I found most influential so that maybe you can get a jump start. Although I've had some success using "larger" patterns I find the smaller ones more powerful and better for overall quality.

By no means is this an exhaustive list. Also please excuse some of the examples, I had to make most of them up. 😂

General

You're Never Too Far Along to Learn/Relearn the Fundamentals

It's awesome to jump in, start building things, and get something working especially as a beginner. Without learning the fundamentals though, you will often find that you aren't quite sure precisely why something is happening, leading to lots of headaches when trying to fix bugs. The fundamentals help you narrow down what's happening so that you can piece it together. For HTML that means learn the basic tags and when it's appropriate to use them. For CSS that means knowing all the different properties that affect layout and how they interact together. For JS it means knowing what this is at all times 😂.

Prefer the Simplest Tech When Possible

When building web experiences, I try and use HTML first, CSS second, and finally JS if necessary. HTML + CSS can get you really far before you have to reach for JS. It's often simpler and more performant to not have to handle such interactions in JS.

Read Documentation and Source Code (Especially MDN for the web)

Documentation and source code are your gateways into learning how things really work. Every time you take the time to read the documentation/source code you gain new little bits that you've never noticed before. There's lots of functionality in the web that you probably don't know. And if you only ever read blogs, tutorials, and Stack Overflow you'll never see the full potential of the tools you are using. It's especially helpful for open source libraries where authors don't always have time to write documentation. This made me a better programmer.

Accessibility Is Necessary

Without proper accessibility your site will be unusable by those who need to use screen readers, high-contrast text, keyboard navigation, etc. Taking the time to learn the accessibility features of the browser will set you up for success the next time you're trying to create a new experience. I found these people and organizations helped a lot when learning more about accessibility:

Learn How the Browser Loads Resources

This one's tricky because browser's aren't always opaque on how they prioritize loading different types of resources. But you can learn a lot about performance from these people and organizations:

CSS

Atomic or Utility-first CSS

Atomic CSS is a way of structuring your CSS classes which mimics the properties and values available in CSS. At first this sounds pretty crazy. There are tons of properties in CSS and each has multiple or even infinite values, so how could this possibly work? Well, first off you don't actually produce a class for each and every value. For those properties with numerical values, we come up with a standard set to use so that will benefit us the most.

For example, we might have a set of classes for various vertical margins. They might be my-0 my-1 my-2 my-3...where each number represents some "level" of margin. So maybe my-1 equals margin-top: .25rem; margin-bottom: .25rem;, and each level after is just + .25rem. Now we have a very useful set of classes to apply pretty much whatever vertical margin we need, and we no longer have to write margins in CSS unless it's an extremely specific case. Not only that, but we've given everyone who uses this a standard set of values to choose from. A third benefit is that we know exactly what the class does, there's no guesswork or hidden values. Finally, we've now opened the possibility for any element or component to have their margin changed, if the situation arises, without making a specific override in CSS. This is probably the most powerful pattern in CSS that I've encountered, even more so than LESS/SASS/SCSS.

If you want to read more about it here are some great links, In Defense of Utility-First CSS, Tailwind CSS, Tachyons CSS, and a whole slew of articles linked at The Case for Atomic CSS.

Consistently Ordering Properties

This is really small and has no actual effects on your CSS (unless it's duplicate properties for fallbacks of properties that aren't supported). However I find it really helpful when reading/writing CSS to stick with a consistent order. My preferred order is layout/positioning, sizing, spacing, typography, colors/visual effects, transition/animations, and then finally "miscellaneous". Within each category I try to stay ordered as well. It helps to spot bugs and speed things up.

Single Class Specificity

I learned this the hard way after nesting way too much SASS and before I got deep into atomic CSS. I was working at a design agency building boutique level websites so everything was very creative and unsystematic or at least each component had lots of exceptions 😉. I quickly found that it was becoming difficult to override CSS I had previously written because everything varied in specificity. By flattening all of it to as close to one class level of specificity it became much easier to override properties on a class. This works hand-in-hand with atomic CSS because as long as your utility classes come last (or have important applied because let's face it if you put that class on their you wanted it) it'll override the component class. This leads to much less specificity wars.

Performant Transitions and Animations

This one is very simple, but can be annoying in practice. There are only two properties in CSS that can be reliably performant, transform and opacity. Everything else is subject to more expensive operations that can cause jank. In general I try to use only these, but I still use color, background-color, and border-color often in low-impact situations, like links or buttons. Read more here about high performance animations.

HTML

Semantics, aka Learn the Basic Tags

There are so many HTML elements. It's hard to know them all and everything that they do, but they will help you build web experiences that are more accessible and maybe even help you write less CSS and JS. Proper HTML also helps your site get crawled by search engines, which helps your content get found. They are the basic bits of the web and using them properly helps you create websites that work.

Responsive Images

Here's the best way to save bytes on your images. Responsive images allow you to serve just the right size to your users by giving you channels to describe images of different sizes and when those sizes will apply. There's a great doc written by MDN that explains it here.

<input> + <label> = interaction (<dialog>, <details>, and more)

There are a lot of interactions built into the default browser elements. We can leverage those to build interactive elements that do not require Javascript. And since they don't require JS, they're just a little more robust. Sometimes though, JS is required to really make a set of elements usable and accessible. In those cases we start with the HTML+CSS and layer on the additional functionality required with JS.

We can build custom toggles, file inputs, and many other types of elements using an <input> + <label> combination by simply using the :checked selector to update the state of the visible element.

Popovers and collapsible elements can also be built with the details element. A great presentation on this: The Details on Details by Mu-An Chiou and a similar one on modals/dialogs by the same author A Dialog on Dialogs

JS

State and Special Attributes as Strings (or getting rid of boolean addiction)

When writing Javascript we have a tendency when starting out to write states as a set of boolean flags. We might simply start with one state, isError, and assign that a boolean value. And at first this might be fine if it's the only state we're tracking. Soon though we'll probably add more, maybe we need an isInProgress state. Now we have two flags to represent what should realistically only be one state for the whole component. If both of those states are true, then what state should we be in? We quickly get into situations where invalid states are possible.

The simplest way to resolve this is to track state with a string. The string should be part of a limited set that represents all the states that our component can be in. This helps clean up all the isX properties that litter our components and we can simply check the state with a function that returns a boolean value.

Here's a basic example of an ajax call to a server to load some data:

const loaderStates = {
    initial: 'initial',
    loading: 'loading',
    success: 'success',
    error: 'error'  
}

let state = loaderStates.initial;

function is(status) {
    return Array.isArray(status) 
        ? status.indexOf(state) > -1 
        : state === status;
}


async function loadTodos() {
    state = loaderStates.loading;

    try {
        const todos = await fetch('/todos').then(response => response.json());
        state = loaderStates.success;
    } catch (error) {
        state = loaderStates.error;
        console.log(error);
    }
}

You can see we've created an object to hold our states called loaderStates. We also created a function which lets us check if the current state matches a state we want to know about, equivalent to what we had before isError vs is(loaderStates.error). Now we can use this function to trigger things like spinners when loading or error messages when we're in an error state.

A much more advanced version of this pattern is called state machines which you can find out more about here from David K Piano where he uses the library he wrote xstate.

Similarly, we tend to use these types of boolean flags to describe attributes like CanUpdate, CanEdit, etc. which is just as unmaintainable. In the same way as above, we can move to strings to give us a more succinct way to represent some set of attributes. This is also gives us the added benefit of being able to iterate through the set of strings with array functions, whereas before we might have had to have a huge if-else statement to check all the attributes.

const admin = {  
    id: 1,
    name: 'Hunter Miller',
    canEdit: true,
    canPublish: true,
    canManageUsers: true,
    canApprove: true,
    canViewOtherUsersContent: true,
    canAccessBackend: true
}

vs.

const admin = {
    id: 1,
    name: 'Hunter Miller',
    permissions: [
        'edit', 
        'publish', 
        'manage-users', 
        'approve', 
        'view-others-content', 
        'access-backend'
    ]
}

Making Maps

There's a common pattern in JS where we want to run some functionality or get some data based on a key. Instead of using a chain of if statements or a switch with cases, we can use an object to associate a particular key with whatever we need, and then just access what we need with map[key].

Data we're working with:

const transaction = {
    id: 88,
    price: 33.93,
    loginId: 'hmillerdev',
    email: 'hunter@hmiller.dev',
    paymentId: 'e2b7291d-8838-4435-942a-ec6bec938673'
    paymentType: 'credit-card'
};

Using ifs:

function processTransaction(transaction) {
    ...
    if (transaction.paymentType === 'credit-card') {
        processCreditCard(transaction);
    } else if (transaction.paymentType === 'paypal') {
        processPaypal(transaction);     
    } else if (transaction.paymentType === 'bank') {
        processBank(transaction);       
    } else if (transaction.paymentType === 'bitcoin') {
        processBitcoin(transaction);        
    } else if (transaction.paymentType === 'seashells') {
        processSeashells(transaction);      
    }
    ...
}

Now with a map:

const processors = {
    'credit-card': processCreditCard,
    paypal: processPaypal,
    bank: processBank,
    bitcoin: processBitcoin,
    seashells: processSeashells
}

function processTransaction(transaction) {
    ...
    const processPayment = processors[transaction.paymentType];
    processPayment(transaction);
    ...
}

Functionalize

This one is pretty near and dear to me. One of the first things I learned was to break my functions down as small as they can be, so that we can reuse that chunk of code later. This comes with the added benefit that now we've given that chunk of functionality a name. So when we read through the code, we can get a better sense of what's going on. It also lets us leverage one of the main features provided to us in JS, that let's us pass functions around to alter the functionality of other functions.

One of the best examples, is the array function map. We call this function off of an array and pass it a function which will transform each item in the array returning a whole new array.

const itemPrices = [25.00, 10.00, 48.00];

function priceWithHalfOffDiscount(price) {
    return price * 0.5;
}

const discountedPrices = itemPrices.map(price => priceWithHalfOffDiscount(price));

So now discountedPrices equals [12.50, 5.00, 24.00].

Anytime we need to transform each item in an array and get that transformed array back, we can use map with whatever transforming function we need. We now have an immense set of functionality with just one function, because we can give it something to change what it does.

This is the very tip of the iceberg to a style of programming called functional programming which you can learn about from Mattias at Fun Fun Function from his functional programming playlist or you can learn from this fun little online book called the Professor Frisby's Mostly Adequate Guide to Functional Programming. I've found that this style of programming has vastly improved my code quality and resiliency and makes a lot of problems much easier to think about. However it can be very confusing when you first learn it because it is a bit of a brain change for most people.

Don't Repeat Yourself (Too Much)

Related to the previous section, if we have two blocks of code that are very similar, it can be beneficial to combine them into a function and let the parameters dictate the differences. Sometimes this can get us into trouble if we're trying to force things that are too different together. It might force us to make a function that has way too many branching paths or long lists of parameters. I find that is less often the case though. We actually more often have a ton of things that are very similar and once we start de-duplicating one part of the code it can lead to a waterfall of changes that makes the code much cleaner and easier to read. A good rule of thumb is that if this helps the code handle things more consistently and improves the readability then it's a good time to remove the redundancy. This can be a double-edged sword, but mostly beneficial when not overused.

function processOrderWithShipments(data) {
    if (!data) {
        return;
    }

    const order = new Order(data);
    const shipments = assignItemsToShipments(order.items);
    const paymentProcessor = new PaymentProcessor();

    if(!order.isValid()) {
        throw new Error("Order is invalid");
    }

    const receipt = paymentProcessor.pay(order.paymentMethod, order.Total);
    sendOrderConfirmationEmail(order, receipt);

    const shipments = assignItemsToShipments(order.items);
    alertFulfillment(shipments);
}

function processRecurringDigitalGoodsOrder(orderData, timePeriod) {
    if (!data) {
        return;
    }

    const order = new Order(data);
    const paymentProcessor = new PaymentProcessor();

    if(!order.isValid()) {
        throw new Error("Order is invalid");
    }

    const receipt = paymentProcessor.pay(order.paymentMethod, order.Total);
    sendOrderConfirmationEmail(order, receipt);

    setupSubscription(order.paymentMethod, order.items, timePeriod);
    sendGoods(order.goods);
}

function processOrder(order) {
    const paymentProcessor = new PaymentProcessor();

    if(!order.isValid()) {
        throw new Error("Order is invalid");
    }

    const receipt = paymentProcessor.pay(order.paymentMethod, order.Total);
    sendOrderConfirmationEmail(order, receipt);
}

function processOrderWithShipments(data) {
    if (!data) {
        return;
    }

    const order = new Order(data);
    const shipments = assignItemsToShipments(order.items);

    try {
        processOrder(order);
        alertFulfillment(shipments);
    } catch (error) {
        console.log("😭😭😭😭", error); 
    }
}

function processRecurringDigitalGoodsOrder(orderData, timePeriod) {
    if (!orderData || !timePeriod) {
        return;
    }

    const order = new Order(orderData);

    try {
        processOrder(order);
        setupSubscription(order.paymentMethod, order.items, timePeriod);
        sendGoods(order.goods);
    } catch (error) {
        console.log("😭😭😭😭", error); 
    }
}

Getting Rid of a Few Ifs

Often in our code we want to provide some default values or not call a function if something's null. We can get around using if statements by using boolean checks. For example if we want to default a value based on a parameter that may or may not be null we can do something like this: const items = newItems || []. Because of the way JS works, boolean checks like this return the value of the expression so items will be assigned [] if newItems is null or undefined. This is a tip I picked up from Addy Osmani though I can't seem to find the article he wrote about it. Sometimes this can result in code that's less readable and in those cases you should use an if statement.

Separate API Calls into Their Own Module

If you have multiple calls to a shared endpoint or API, it can often be helpful to encapsulate all those AJAX calls into a module where each call is a function. Now, setup and the handling of the response can be the same across the application. Anytime something changes about that API all the changes can be made in one place and we don't have all that clogging up our specific component's logic.

class todoAPI {
    getTodos() {
        return fetch('/todos').then(response => response.json())
    }

    editTodo(id) {
        return fetch('/todos', {
            method: 'POST',
            body: JSON.stringify({ id })
        }).then(response => response.json())
    }
    ...
}

export const todoAPI = new todoAPI();

Later on when you need to get the todos:

import { todoAPI } from './todoAPI';

const todos = await todoAPI.getTodos();

This gives us the ability to pass around the API to whatever module or component needs it, and it's not stuck in some specific component. Yet another way to increase re-usability and reduce duplication.

Conclusion

The web evolves constantly and so do my practices and philosophies around development, but the thoughts above have stuck around. These things are like old regulars that just keep coming back to the cafe even though the rest of the customers keep changing. A lot of what I've picked up above came from trial and error. I also read a ton of web dev Twitter, and am never scared to Google something to try out new methods. Like my good friend Bennett Dungan said, learning to code is a marathon. It takes time to build practices and methods that make you productive. Try some of these things and let me know what you think on Twitter.

– Hunter ✌

Originally posted on hmiller.dev. Cover photo by Tim Gouw on Unsplash

The Psychology of Building Software During a Crisis

Hunter Miller — Fri, 27 Mar 2020 13:07:21 +0000

I haven't lived through too many crises. Mostly, it's been hurricanes, and I was a child during the ones that actually affected my day-to-day life. COVID-19's effect is quite unprecendented, both in my life and the lives of others. Today marks two weeks since I started self-isolation with my wife. We've done well so far, cooking a lot, spending time in our backyard with our animals and the birds, keeping up with friends and family through video chats, and trying to enjoy all our hobbies that can be done at home. We've been very fortunate especially since we both can work from home and keep a paycheck whereas others have not.

Business (not) as usual

Even though we're both big introverts, we're still going a little stir crazy. Not only that, but the weight and severity of the current pandemic is affecting our moods and energy. Certain things feel more important now, much more than ever, and other things that might have felt somewhat important before, now feel meaningless.

For example, minor things like keeping a particular sleep schedule, cutting grass, washing the car, etc. start feel a little meaningless. Side projects that I might have picked up to work on after work don't quite call my name like they used to. So maybe a small boon of this time is that it shows us what really matters.

And yet, this hasn't quite seemed to have hit my company's psyche yet. We're still mostly business as usual (besides now all working from home and taking precautions), building the same software for the same projects that we were working on before. With mostly the same deadlines. It feels wrong or at the least off. It feels like we should be contributing to the problem at hand, the pandemic. If not that, it feels like we should be working on cleaning up and bolstering the core software. But we aren't. We're building for new features, like we always are.

Before this crisis, we operated as a feature factory for the large ecommerce site we run, at one of the world's largest jewelry manufacturers. The feature factory pace/prioritization has been written about many times before. The business comes up with a new feature to offer users in an attempt to get more sales, and then we build it. Repeat.

The effects of this style can be seen everywhere. Complicated UI that appeases the 1% of users who actually use it while confusing the 99% who don't need it. Tons of code that hasn't been touched in years. Over burdened teams with ever depreciating code bases and little to no time for maintenance of the core features.

What's missing?

A mindset. A mindset that keeps the essence of our business and the majority of users top of mind. We're like magpies. Every customer with a shiny new problem or every teammate with a new brilliant feature stops us in our tracks. It's easy to forget that 95% of our customers go through the same five pages of our site nearly every day. If our gemstones deptartment is looking to improve their numbers, and we start building a new experience to make it easier, maybe we'll improve the numbers by 3-10%. But gemstones might only be 5% of our total web revenue. So, globally this nets us a 0.5% increase in revenue. If we instead make a change like improving checkout flow, or globally decreasing page load by 1s, we might see a total web revenue improvement by 1% or more while also improving all of our customer's experiences.

That's not as glamorous as making a new feature and not nearly as marketable, but it's more helpful overall. It also puts us in a stronger position over the long run, because our core is resilient, forged to perfection over time. If we continually choose working on what's essential, our customers won't want to leave, and they'll have more confidence we're invested in what they actually came for. Sometimes you have to build the glam to attract people or innovate to find unreached markets. And I think that's perfectly fine some of the time, but you need the right mix.

Getting back to crisis time, what can we even be certain of right now? This could all last much longer than we thought. A new program or feature we wanted to release might get lost in the malaise of the time, a waste. People aren't seeking novelty right now. They want security and certainty. Which is why it feels wrong. What can we build to shore up weaknesses during times like this? If we have to shut down for weeks, what can we focus on that saves us money or cleans up something really messy? Our customers won't be expecting new and fresh.

Everyone's huddling in place or courageously fighting. By trying to run business as usual, I feel out of place, almost guilty. And definitely mentally and emotionally low on energy. When I normally would be working on side projects, I find myself just wanting to relax and spend time with friends and family. The universe is shoving the essential in my face. I've been wanting to consistently write for a long time, and this might be the only way to feel like I'm contributing to the larger problems at hand.

If you just feel like chatting with someone, you can email me at hunter@hmiller.dev or schedule something on my calendly and we can video chat. Stay safe out there and keep connected with those you love.

– Hunter ✌

Originally posted on hmiller.dev

Photo by Robert Metz on Unsplash

Senior Developers, Let Us Learn Too

Hunter Miller — Fri, 23 Aug 2019 04:56:50 +0000

If you have a team of developers there will always be a mix of experiences and ages. Something I've noticed especially from senior and older developers is a tendency to be negative, doubtful, cynical, and quick to shoot down ideas that don't jive with what they know. This creates a culture without sharing because some ideas are worth more than others. This culture leads newer devs to censor themselves, and if I'm less likely to share what I think, then I'll be even moreso afraid to question what seniors say.

I've had to develop a strong will and confidence to be able to question seniors and have my ideas heard. When making decisions about a new project, senior devs often have flimsy reasons, deep assumptions or very little passion to support their decisions. Sometimes I can sway them over a prolonged discussion because I'm often more passionate about a solution than they are, but frequently decisions get made quickly without the group because they decide to go ahead of the team.

Senior devs that go off to "hero" a project are toxic. Just because you can fully implement a project top to bottom doesn't mean you should. Sometimes it's not even their choice to do so, but they often have the choice to include others on the project. If they don't and start making all the decisions, it feels like they are taking all the fun. Development thrives on shared knowledge, exposure to others' ideas/cross-pollination, criticism of code style and architecture. Too much code that has not been designed for readability and understanding especially without including others becomes a black hole. Their code is optimized for their own understanding. This creates artificial bottlenecks in the codebase. It becomes the sole responsibility of the person who wrote it, which leads to siloing, more context switching and overall a larger burden on the team. You may even make memes about the obtuse, complex, and messy code that no one wants to touch or untangle.

If you read Twitter at all, this is the "10x engineer" everyone was memeing about. When devs like this have strong opinions and loud voices, they will dominate a team. Too often these people are propped up by middle/upper management because they see them as high producers. Which leads to even more influence in their favor. It can be stifling. Seniors tackling the majority of the difficult work prevents the mids and juniors from reaching their full potential and perpetuates their status. And when others go to tackle hard problems they get stuck easier because they haven't had enough practice. It becomes a self-fulfilling prophecy.

What does it take to reverse the situation? Like in most crafts, devs need room to make mistakes and fuck up. We need time to learn. We don't come out of the womb knowing all the intricate knowledge that we are expected to know, especially intimate business knowledge. Plus, no one knows everything. We need seniors with a beginner's mind, open to learn something even from the noobiest junior. Because as we've seen, the world of development changes quickly and there's always something new to learn. Encouraging others to own projects, removing your ego from solutions, asking hard questions that help others to arrive at the correct architecture/solution, guiding architecture but not dictating it, pairing, helpful code reviews. When you find a senior who takes support of the teams seriously, it's a breath of fresh air and helps the team move faster as a whole.

It can be tough balancing this with business needs, especially if it's a particularly toxic business culture too. Really it all boils down to time and patience. Good senior devs will take time with others and really help to make sure they understand. Like any good leadership they should be willing to get their hands dirty, pave the way, but ultimiately trust that the rest of the team can carry out the majority of the work.

Originally posted at hmiller.dev

Achieve Greatness by Striving for Quality

Hunter Miller — Sat, 03 Nov 2018 06:19:32 +0000

Building effective and resilient software is hard. Building software that is a joy to use is even harder. Software developers and their teams manage a number of goals and often struggle with meeting them, whether it's business goals, making deadline/budget, finding the right talent, avoiding technical debt, etc.

All of those goals are important, but none of them trump creating usable software. Being usable is simply the lowest bar. Any lower and the product will simply fail. Does your app annoy people? Do users have to trudge through mud to do even the simplest of tasks? Questions like this can lead us to great reward, if we would only spend the time it takes to resolve the problems uncovered.

Developers seem to have a blind-spot and a particular endurance for clunky experiences. We understand what it took to make. Even a few mis-steps can lead us down a path where our app becomes frustrating to even look at. And while we can have sympathy towards others who build software, we cannot expect sympathy from our users. They deserve better and shouldn't be burdened with our struggle. We've got to be better than that. Especially for developers just getting into the field, we have to give them principles to uphold and an image to strive for. We have to show them what it takes and what it really means to do development well.

True quality can only be achieved by deep understanding and collaboration with our colleagues outside of development, but we need to control how we work and be firm with our principles. This is what it takes to create truly gratifying software.

Technically UX

To help developers strive towards this goal, I'm starting a weekly newsletter, Technically UX. We will be discussing what it takes to build better, usable software and introduce a new topic called technical UX. Technical UX is a whole class of problems that fall under developers' responsibility that range from foundational issues like poorly performing architecture, all the way up to final polish issues like optimizing animations. It's part of what separates the good developers from the great and often part of the reason why we fail at making usable experiences.

If you want to learn more, check out the first newsletter that just launched on performance!