DEV Community: Richard Dillman

You're Not Blocked. Your Work Is.

Richard Dillman — Sun, 26 Jul 2026 20:12:23 +0000

What my grandfather understood about being indispensable

Let me tell you about the most productive week of my career, during which I accomplished absolutely nothing of value and was lavishly praised for it.

I was brand new to the company, early career. First week on the team, still learning where the coffee was, still doing that thing where you laugh a beat late at jokes you didn't understand because you don't yet know all the context. And the fellow who wrote the .NET side of our little operation, the man whose code my code was supposed to talk to, went on vacation.

For a week.

Of course, he was entitled to have a vacation, and I want to state that clearly and without sarcasm, because I'm about to spend a thousand words making his vacation sound like the Hindenburg, and none of this was his fault.

The work in front of me needed his endpoints. His endpoints did not exist. He wasn’t there to write them. I was a frontend person who was, at that point in his life, generously described as "learning JavaScript," and who knew precisely as much about .NET then as he does now, which is nothing.

So there I sat. Blocked. Stopped. Done. Free, arguably, to spend the week reorganizing my desk.

Now, here's where you might imagine that a wise senior engineer put a hand on my shoulder and explained the way forward. That's not what happened. What did happen is that I was raised by a man who would have found my situation morally suspect.

A word about my grandfather

He was a shop steward. If you're unfamiliar with blue-collar union shops of half a century ago, this means he was the person on the factory floor that a co-worker went to when something was wrong. He then took it to management, and was therefore trusted by everybody and beloved by nobody. This is a very specific kind of job and it makes a very specific kind of man.

He told me, more times than I can count:

Nothing and nobody stands in your way. If you don't have the thing you need, make do with what you have. And if the person who does the job you need done isn't here, then you learn to do their job.

Hold onto that last sentence. We're going to come back to it, and I'm going to reveal that I misunderstood it for roughly two decades.

What I did instead of nothing

I didn’t learn .NET. I had standards, and one of them was that.

What I figured out from whatever scraps of the internet existed at the time, was how to build a convincing imitation of a thing that doesn't exist yet. In the dev world, we call these mocks. Stubs. Fakes. We devs didn’t invent this concept. Go to a home show, or a home-improvement place, and you’ll see cabinets installed in a mock kitchen. The rest of the house isn’t needed to get the task at hand done.

It's honest work, oddly. Everybody knows it's fake. That's the deal.

And it worked. The backender came back from vacation, and his endpoints landed. Of course they were not shaped the way I'd guessed they'd be, because “guessing” isn’t “knowing”, so I spent some time pulling my placeholders out one at a time and putting the real thing in behind them. But the work was there, waiting for me to dive into. I had not spent the week rearranging my desk.

He was impressed. They asked me to show the other frontend folks how to do it.

The hero reading

Here's the thing about being praised for a workaround. It feels molecularly identical to being praised for a solution. There is no way to tell them apart from the inside. I have looked.

Let’s read my grandfather's line again:

If the person who does the job you need done isn't here, you learn to do their job.
I heard that as “Grit your teeth, kid, be the hero, don't be the person standing around with his hands in his pockets.”

That's the flattering reading, and I was twenty-something, and I took the flattering reading, because that's what twenty-something is for. Honestly, who doesn’t enjoy being a hero? I once worked for a company that had a little green hero cape for heroic saves. Everyone loves a hero.

And that reading isn't useless. It's the thing I still tell every new engineer who'll sit still long enough to hear it:

You can't be blocked. There is always something to do.

Write some documentation. Fix the linting errors. Increase the test coverage. Go learn the thing you've been avoiding because it's dull, or because you're a little afraid of it. Grab a broom. Empty the trash bins.

And I mean that last part literally, which is why I say it. I'm not above trash duty. I have never once in my life been above trash duty, and I'll tell you something, I've never met a good one who was. That instinct, to sit there blocked rather than do something useful that doesn't happen to look impressive, is real. It's just worth calling it what it is. That's vanity. That's not a blocker.

The half I missed

But notice what "you can't be blocked" doesn't say. It doesn't say the work can't be blocked.

Because the work absolutely can. That ticket can be dead in the water while you are perfectly fine, whistling, up to your elbows in something else entirely. Those are two different facts, and a standup meeting mashes them into one status, and the one that comes out of your mouth is the one about you.

Which is exactly the trap I walked into, and got applauded for. Look at what actually happened that week. A company discovered that it had exactly one human being who could write its backend, and that when that human being took a perfectly ordinary vacation, the work stopped. That's not a scheduling inconvenience. That's a structural fact about the business, and it walked right up to them and introduced itself.

And the reason they noticed is that some kid had to spend his first week building a papier-mâché backend to survive it.

There's always something to do

If "there's always something to do" just means you stay busy, you haven't solved a thing. You've hidden one. The board looks fine. Nothing's red. Everybody's productive. And the actual problem is sitting right where it was, running up a bill nobody is counting, precisely because you were good enough at your job to make sure it never showed a single symptom.

That's not grit. That's camouflage.

My grandfather was a shop steward, and a shop steward is not in the hero business. He was a cross-train-everybody man, his entire life. The reason a union hall insists that everyone on the floor knows more than just their own machine is that a shop where exactly one person knows how a thing works is one vacation, one illness, one bad afternoon away from stopping cold. On a factory floor, redundancy isn't a nice-to-have. It's the whole ballgame.

He wasn't telling me to be a hero. He was telling me that a shop where only one worker knows the machine has a problem, and that the fix is for more on the floor to know the machine.

Same sentence. Both halves sitting right there in it, the whole time. I took the half that made me feel good about myself.

To the company's enormous credit — and I want to be fair, because this story could have gone the other way and usually does — they did the right thing. We started cross-training the backend people across the different parts of the system. The next time somebody went on vacation, nothing happened. The most boring possible outcome, which is what a fixed problem looks like.

I didn't understand at the time that this was the actual ending of the story. I thought the ending was that I was clever.

Say both things

The work is blocked, and I am not blocked, both.

The work is blocked: Here's the cause. Here's what it's costing us. That goes to the room, and it goes to whoever's above the room, and you don't soften it, and you don't swallow it just because you found a clever way around it. A way around is not a fix. The bottleneck is still there, and it will be there next month, wearing a different hat.

I am not blocked: Here's what I’ve done, and here’s what I’m doing next.

The first part is the shop steward. The second is the kid. My grandfather was both, and he handed me both, and I spent an embarrassingly long time doing only the one that felt like winning.

The same split explains the PR sitting out there waiting on a review. Nobody is coming. Nobody is thinking about your branch. Nobody feels the little pang of guilt you've imagined them feeling. Their day does not get worse because your work is going stale.

It’s not their problem. It’s yours.

So go get it. Ask in the channel. Ask again. Walk over there. Put the ticket on the screen in standup where everybody can see what's waiting on what. Cut your nine-hundred-line monstrosity into something a human being could actually review without weeping, because a diff that size isn't a request, it's an imposition, and you know it.

Get pushy, but not rude. Pushy. And then a little pushier than feels comfortable, because the alternative is sitting there "blocked on review," which is the softest, most pitiful version of that word ever spoken in a conference room. You're not blocked. You just haven't asked hard enough yet.

Are you blocking somebody?

That's the shop steward giving me the side eye. But hero mode can blind a dev to that, which is the whole problem.

It can show up as being the only one who knows how the deployment works. Being the one with the credentials. Being the person they come to. I was the only SEO person once. The only Lighthouse person. Way back, I was the only one on the dev team who could get a thing done with a CSS selector instead of a heap of JavaScript, and I'll admit it felt terrific.

None of it felt like being a bottleneck. It felt like being valuable, which is the most flattering thing, and the hardest thing to see straight.

Being the person they come to while being the person they wait on - that’s the blocker.

You're a bottleneck with good performance reviews

So go look. Whose work runs through you? What breaks if you take a week off — which you are also entitled to do? If the honest answer is "quite a lot," then you're not indispensable. You're a bottleneck with good performance reviews.

Make do. Don’t be in the way. Be loud about what is in the way.

My grandfather would've had that figured out before lunch. Took me twenty years, but I got there.

Why Your React Component Is a Hot Mess (and How to Fix It)

Richard Dillman — Wed, 25 Jun 2025 17:27:44 +0000

Writing React components is kind of like doing laundry. Sure, you could toss everything in together and hope for the best… but you'll probably end up with pink socks and runtime errors. A clean, consistent order inside your functional components helps your code stay readable, maintainable, and most importantly, not broken.

React’s Rules of Hooks are like those “do not put metal in the microwave” warnings. They exist because someone did put useEffect inside a for loop, and things caught fire.

Let’s walk through a solid, time-tested order for organizing logic inside a functional component. You won’t always need every section, but knowing the ideal flow can save you from future debugging-induced hair loss.

Why Hook Order Matters

React tracks hooks by position, not by name. Think of it like calling roll in class, if someone swaps seats, the teacher starts marking the wrong student absent.

If your hook order changes between renders (say, putting a hook inside an if statement), React gets confused. Confused React is not fun React. You’ll likely see this cryptic gem:

React has encountered a hook call that is inconsistent with previous renders.

1 Hooks - Built-in (useState, useEffect, etc.)

Why they go first:

React’s built-in hooks need to run in the exact same order every time. No surprises, no detours, no mystery meat. Putting them right at the top ensures everything is predictable and in line with React’s rules.

function ExampleComponent() {
  const [count, setCount] = useState(0);
  const [name, setName] = useState("Guest");
}

Think of this section as the “meet the characters” part of a movie. Everyone’s introduced early, so the plot (i.e., the render) makes sense.

2 Custom Hooks

Why they’re next:

Custom hooks are like those helpful friends who show up with a toolbox and a pot of coffee. They usually rely on built-in hooks, so we want the foundation laid before they come in and start tightening bolts.

const user = useUser();
const theme = useTheme();

Stacking them under the built-ins gives you a nice clean "hooks zone" where all the magic starts.

3 Derived Data (from props or state)

Why it goes here:

Once you’ve got your raw ingredients (props, destructured props, and state), it’s time to prep them. Derived variables are like chopping onions, not exciting, but necessary before you start cooking the actual dish.

const { user } = props;
const isLoggedIn = Boolean(user);
const displayName = user?.name?.trim() ?? "Anonymous";

Put these right after hooks so you’re always working with declared and up-to-date values.

4 Callbacks (useCallback, useMemo, useRef, etc.)

What now:

Callbacks and memoized values depend on state or props, and you want them nicely memoized before you start rendering or passing them down. Think of this as labeling your leftovers before you put them in the fridge.

Note: If it can be easily done, move these outside the component, but if they rely on the hooks or modify them, don't.

const handleClick = useCallback(() => {
  setCount((prev) => prev + 1);
}, []);

Keeps things neat. Prevents unnecessary re-renders. Your future self will thank you.

5 Effects (useEffect, useLayoutEffect, etc.)

Why are they down here:

Effects are the "cleanup crew" running after shadow dom has been generated the browser. Effects are hooks so order still matters. Even if you wind up not needing a hook it is still counted. They need to be after other types of hooks, or data, but before any conditional logic.

useEffect(() => {
  console.log("Component mounted or count changed");
}, [count]);

6 Conditional Logic (Conditionals, loops, fragments, etc.)

Why it's here:

Before React can draw the UI, you might need to make decisions, like whether to show a login prompt or a dashboard. This is where that logic lives.

Critical rule:
Never put conditionals above your hooks. That’s how you get runtime gremlins.

if (!isLoggedIn) {
  return <LoginPrompt />;
}

const items = [1, 2, 3].map((item) => (
  <li key={item}>{item}</li>
));

This section is your last prep before serving the dish.

7 Return JSX

Why is this last:

It’s the final product! The visual output. The “ta-da!” moment. This is what the user sees, and it should be the last thing, after all your setup work.

return (
  <div>
    <h1>Hello, {displayName}!</h1>
    <button onClick={handleClick}>Click me ({count})</button>
    <ul>{items}</ul>
  </div>
);

Final Thoughts

React won’t force you to follow this order, but following a logical structure helps future-you (or your teammates) understand what’s happening and reduces the chance of hook-related surprises.

Want to enforce it automatically? Tools like ESLint (with eslint-plugin-react-hooks) and Prettier can keep your components nice and tidy.

Working with an LLM like Claude or ChatGPT? Add this structure to its coding style guide so your AI pair-programmer doesn’t throw spaghetti at your component tree.

Bonus dad joke: What do you call a TV vaccination?
A screenshot.

Hero Image Optimization Techniques

Richard Dillman — Tue, 17 Jan 2023 06:17:55 +0000

Page speed is essential in determining a website's user experience. If a user can’t experience the content, they’ll bounce. A site's ideal complete load time is below 2 seconds. Studies show that most users will abandon the page within 3 seconds. You can also expect a 1.3% increase in that abandonment for every additional 100ms. For this reason, Google rates page speed quite heavily for SEO, and Google's Search Console provides a report on LCP, which can help website owners understand and improve the loading performance of their pages.

Reasons why page speed needs to be a key KPI:

you want your page to rank well in organic searches
you want your ads to perform
you don’t want users abandoning your page out of frustration

Fortunately, a lot of low-hanging fruit can make a big difference in getting started. Following are some issues that I see a lot and have pretty straightforward ways to address.

Measuring page speed

One of the key metrics used to measure page speed is the Largest Contentful Paint (LCP). The LCP measures the time it takes for the largest content element visible in the viewport to load and render. Therefore, optimizing the hero image can improve LCP and web page speed. Your goal is to have LCP occur as quickly as possible. Google has defined this as within 2.5 seconds or faster measured from the start of page load.

We should always strive to set the hero image src in the initial HTML payload to reduce the length of the critical request chain. Some frameworks will add the src via Javascript or CSS. However, this will always take additional time.

The file size

One way to speed up the hero image is to reduce its file size through compression. You could also use a tool like ImageOptim, or NextJS’s Image Component. Additionally, a next-gen image format like WebP, available for all modern browsers, can significantly reduce the file size without sacrificing quality.

A content delivery network

Another way to improve the LCP is to use a Content Delivery Network (CDN) to serve the hero image. A CDN is a network of servers distributed around the world. It can significantly reduce the time it takes for file delivery by serving it from a geographically closer server.

Specify native height and width

Images should always have both height and width tags to allow the browser to calculate the aspect ratio. These should be the native size of the image while allowing CSS to set the actual rendered size. Adding the height and width allows the browser to hold this space open for the image; therefore, the page will not shift when it loads, allowing the measurement to take place more quickly.

Example of using the height and width:

<img
    src="hero-image.jpg"
    height=”400”
    width=”400”
    alt="Hero Image."
/>

The srcset and sizes attributes

A more responsive image optimization is to use the srcset and sizes attributes. These attributes allow you to provide different versions of an image for different screen sizes and resolutions and can significantly reduce the amount of data on smaller devices or lower-resolution screens.

Example of using the srcset and sizes:

<img
    src="hero-image.jpg"
    height=”400”
    width=”400”
    srcset="
        hero_400px.jpg 400w,
        hero_800px.jpg 800w,
        hero_1600px.jpg 1600w
    " 
    sizes="(max-width: 600px) 100vw, 50vw" 
    alt="Hero Image."
/>

The loading attribute

The loading attribute can prevent or encourage the browser’s loading order. The loading attribute can be set to lazy or eager, depending on the use case. “Lazy” loads the image when it becomes visible in the viewport, while eager loads the image immediately when the page is loaded, whether or not it’s in the viewport.

Example of using the loading attribute:

<img
    src="hero-image.jpg"
    height=”400”
    width=”400”
    loading="eager"
    alt="Hero Image."
/>

You can add the loading attribute with a value of “lazy” to other images on your page when they should not load early. Slowing these items down helps speed up the rest of the assets. Lazy images are requested immediately if they are within the viewport. Outside the viewport, they are delayed and only fetched when approaching it.

The link tag with preload

A link tag with the preload attribute tells the browser about critical resources before encountering them in HTML. So, for example, you can use preload to increase the download priority of late-discovered Hero images, especially if they load via Javascript or CSS.

Example of using the link tag:

<link rel="preload" as="image" href="hero-image.jpg" />

If you are already using the srcset in your hero’s image tag, you can also use that here in the link tag and ensure that the correct size image is selected.

Example of using the link tag with a responsive image:

<link
    rel="preload"
    as="image"
    href="hero-image.jpg"
    imagesrcset="
        hero_400px.jpg 400w,
        hero_800px.jpg 800w,
        hero_1600px.jpg 1600w
    " 
    imagesizes="(max-width: 600px) 100vw, 50vw"
/>

The fetchpriority attribute

You can use a fetchpriority attribute to do the same thing as a link preload, although you will have to wait for the processor to discover the image tag. A priority hint can adjust the loading order of assets such as images, CSS, iframes, scripts, and fonts. So the Hero can be requested before other lower-priority assets.

Example of using the fetchpriority attribute:

<img
    src="hero-image.jpg"
    height=”400”
    width=”400”
    fetchpriority="high"
    alt="Hero Image."
/>

Putting it all together

Using all the resources we have learned, we can apply them all to receive an optimal loading path.

Example of using all the tools:

<head>
    <link
        rel="preload"
        as="image"
        href="hero-image.jpg"
        imagesrcset="
            hero_400px.jpg 400w,
            hero_800px.jpg 800w,
            hero_1600px.jpg 1600w
        " 
        imagesizes="(max-width: 600px) 100vw, 50vw"
    />
</head>
<body>
    <img
        src="hero-image.jpg"
        height=”400”
        width=”400”
        srcset="
            hero_400px.jpg 400w,
            hero_800px.jpg 800w,
            hero_1600px.jpg 1600w
        " 
        sizes="(max-width: 600px) 100vw, 50vw" 
        alt="Hero Image."
        loading="eager"
        fetchpriority="high"
    />
</body>

Optimizing the hero image is essential in improving the LCP and web page speed. Applying the above techniques can get your site dramatically closer to that 2.5 seconds goal!

Head tags organized

Richard Dillman — Thu, 14 Jan 2021 20:41:48 +0000

Order (still) matters

A minimal number of tags are allowed within the HEAD of HTML documents. Those tags are title, style, base, link, meta, script, and noscript. Oddly enough, these elements’ order can drastically alter the loading of your document and its dependencies. Here are some things I have discovered trying to scratch out better performance within the sites I work on.

1: Character Encodings

The meta tag for the charset declaration should fit entirely within the first 1024 bytes of the file. If the charset is included later in the code, the HTML will be re-parsed once encountered, wasting precious time before rendering anything. So always put it first. The same reasoning applies to the viewport and other meta tags that describe how a page should render.

<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">

2: Title Tag

The title tag’s purpose is to declare the name of the document. It will replace the URL within the browser's tab, so it is good to place it as early as possible to avoid confusion if the user notices when the tab name updates.

<title>Page Title</title>

3: Preconnected Links

Here we are focused on third-party domains that we know for sure will be requested. Preconnect will handle the DNS lookup, navigate the connection, and any redirects necessary to reach the targets. It will not download any content. Requesting these connections is particularly helpful on slow connections to establish the route as early as possible. However, this can be costly for mobile devices as multiple connections can consume unnecessary bandwidth. Only preconnect to servers you are certain will be needed, such as analytics, your CDN, or your static asset site.

<link rel="preconnect" href="https://www.google-analytics.com" />

4: Synchronous Scripts

Synchronous scripts include any JavaScript that must run before the page renders, such as populating the dataLayer. Here we include script blocks and external scripts but not deferred or async ones. No matter where it is, any script in the head will block applying CSS, even after the CSS. The browser must process anything that might modify the DOM before processing your styles. So you should add those synchronous scripts before your style sheet.

<script>...</script>
<script src="app.js"></script>

5: Synchronous CSS

This includes inline style blocks and style sheets that are used for rendering. Consider using media queries and breaking your styles into multiple files. The media attribute will let the browser know if this CSS is going to be render-blocking or not.

Inline styles are parsed first. It is important that we remember that styles are parsed as they are encountered.

<style>...</style>

External files are requested and parsed next.

<link href="style.css" rel="stylesheet">

Next to be requested and parsed are the styles with media queries. If they match your current breakpoint, orientation, or pixel density.

<link href="other.css" rel="stylesheet" media="(min-width:768px)">

Next up for request and parsing are the print style sheets.

<link href="print.css" rel="stylesheet" media="print">

Stylesheets with media queries that do not match the current environment will not be requested.

<link href="other.css" rel="stylesheet" media="(min-width:1024px)">

Knowing this, you can also trick the browser into loading non-critical CSS a bit later with the onLoad method. By pretending this is a print sheet, it will load after all other CSS but before any containing media queries. Once its load event fires, the media changes to all. With this being async, that will happen after the DOM has been parsed and images begin loading.

<link rel="stylesheet" href="lazy.css" media="print" onload="this.media='all'">

6: Preloaded Links

We should preload as few files as possible. These should be visual elements that are required for above the fold rendering. This includes items like fonts, hero images, or icons. As for fonts, you most likely only need the woff2 version. Also, consider loading the fonts from your own server.

<link rel="preload" as="font" href="font.woff2" type="font/woff2" />

7: Asynchronous or deferred Scripts

All other scripts[?] requested, such as those that add interaction handlers, go here. We should put these at the bottom of the body to allow for quicker parsing of the DOM. But if you must put them in the head due to CMS or framework restrictions, place them here, and set them to either async or defer depending on your need.

<script src="foo.js" async></script>
<script src="bar.js" defer></script>

8: Prefetched Links

These are assets that you know for sure you will need later within this page's render cycle. This includes things that you want in place before they are needed. This could include logos in the footer, Twitter feeds, or videos.

<link rel="prefetch" href="jwpplayer.js" />

9: Prerendered Links

Entire content pages that you are reasonably certain that your user will visit next. You can download the assets for that page before it is even requested. I would render things like login, search, cart, or the next page in a series.

<link rel="prerender" href="/search/" />

10: Non-rendering assets

This includes meta tags and scripts that do not affect rendering in any way, such as OpenGraph, manifests, structured data. These tags are for bots and sharing in social media but are not necessary to render the page. To include a script in this spot it must be inline as this content will be inspected in the first pass through the document.

<link rel="shortcut icon" href="icon.png" />
<link rel="apple-touch-icon-precomposed" href="icon.png" />
<meta name="apple-mobile-web-app-title" content="Company Name" />
<link rel="canonical" href="https://companyname.com" />
<meta name="twitter:card" content="summary">
<meta name="twitter:image" content="icon.png">
<meta name="twitter:description" content="">
<script type="application/ld+json">
{
  "@context": "https://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
</script>

Those are the most common tags that could be in your head. Do you wonder about any not listed here? Bring them up in the comments, and let’s discuss!

Creating readable names

Richard Dillman — Thu, 14 Jan 2021 20:41:22 +0000

I have seen a proliferation of easy meaningless words that look like documentation but explain very little. Naming is one of our most challenging problems. The importance of meaningful names cannot be overstated and should not be an afterthought. Attention to naming increases code readability and trust. Well-named methods and variables are more likely to be reused, and creating reusable code is the purpose of creating shared libraries.

Combining words

Camel: (camelCase)
Kebab: (kebab-case)
Pascal: (PascalCase)
Snake: (snake_case)
Screaming Snake: (SCREAMING_SNAKE_CASE)

Each language has its preferred cases for various things. Always follow the lining standards for your language. I use JavaScript and Python so here are those.

Javascript

Camel: variables, methods, and functions
Pascal: types, classes, and constructors
Screaming Snake Case: global immutable constants

Python

Snake Case: variables, methods, and functions
Pascal: types, classes, and constructors
Screaming Snake Case: global immutable constants

Meaningless words:

Never use the following words. They add no meaning to the name and can always be replaced with a better, more specific term.

code
data
meta
mutate
parse
payload
transform
util

Consider the difference between two methods called getArticle and getArticleData. As an outsider reading that API, if there is nothing else known about those methods, it would be very difficult to know which one to use in each situation. The word data is adding no information.

One could say that people should just read the documentation if they want to know the method details. getArticleData becomes tough to understand when nested within other functions.

For example:

function getAuthors(id) {
  const data = service.getArticleData(id);
  const article = service.getArticle(id);
  return article.getAuthors(data);
}

Although we can see this method is supposed to get the authors of an article, the internal logic is difficult to read because it is unclear what the internal methods do. The word Data doesn't add enough meaning to warrant, adding it to the name.

Consider the difference between the three methods mutate, transform, and parse. Having not read the implementation of those methods, you can not know the convention for what these words mean within the context of the project. It is challenging to see the purpose of those methods or the order in which they should be used.

For example:

function getArticle(uri) {
  return Article.fetch(uri)
    .then(mutateAuthors)
    .then(parseAuthors) // bug: authors should have been parsed before being mutated
    .then(transform);
}

Although it is evident that this method gets an article (of some unknown state and type), finding bugs with the ordering or functionality of this method is impossible without resorting to debugger statements or console logs. It is forcing the developer to run the code to understand the expected values between each step.

Obfuscation

When the purpose of the function or variable name is to hide or limit understanding (i.e., black boxes, facades, moderators), then obviously this does not apply. The words referred to here as having low informational value may be useful in those cases where we're deliberately trying to hide.

For example:

return getArticle()
  .then(applyTransformations(options));

In this case, we're deliberately hiding what the transformations are behind a layer of obfuscation or abstraction. There are many reasons this is valuable, including preserving the right to change the contents of the functionality in the future dramatically.

Acronyms, Initialism, Abbreviations, and Disemvoweling

Shortened words are a constant source of confusion. It is generally better to enter the full name and not the abbreviation, but there are cases where it would be redundant to do so, as in the case of well-known acronyms like AMP or HTML. In this case, stick to the camel case and only capitalize the first letter of the acronym, especially when the initialism is beginning.

Single Characters

Single-character names should be avoided, even within a loop where the temptation to use an “I” for the iterator. Think of the group you are looping over. Doesn’t the following make a lot more sense?

for (const dog in dogs) {
  console.log(`${dog}: ${dogs[dog]}`);
}

Better Verbs:

get: Retrieve some state.
set: Change some state.
reset: Reset some state to its default value.
add: Add new content to some state.
remove: Delete some existing state.
apply: In-memory replacements
compose: Create a new dataset from existing information.
fetch: Retrieve some state from an external data store.
handle: Deal with an action. Often used in callbacks.
is/has: A pre-verb to denote a boolean.
$: A pre-verb to indicate a JQuery reference.

Duplication

Any named item that is a child should not duplicate its parent name, nor should it repeat any synonym of that patents name. In the following example, we see breakpoints. We know that breakpoints refer to widths, and as our project is mobile-first, we know they are all minimum widths.

BAD

$breakpoints = {
  minWidthLg: “1440px”,
  minWidthMd: “1200px”,
  minWidthSm: “992px”,
  minWidthXs: “768px”,
  minWidthXxs: “500px”
};

GOOD

$breakpoints = {
    xl: “1440px”,
    lg: “1200px”,
    md: “992px”,
    sm: “768px”,
    xs: “500px”
};

Classes

Classes must be named with an appropriate proper singular noun in PascalCase, and tell us that this variable contains a type with properties and methods.

class Animal { }
class Dog extends Animal { }
class Dachshunds extends Dog { }

Class Methods and properties

Class methods and properties use the verb + noun convention, but the methods can get away with omitting the noun in some cases. In this case, the noun is the parent class. User.get() assumes you are getting the user User.name assumes a user name.

Dog.getName()
Dog.setColor()
Dog.wagTail()

Numbers, Strings, and Objects

Name all Numbers, strings, and objects with the most appropriate singular noun.

Booleans

The names for booleans are in the form of a question, asking what it is or has or can be. So our verbs are: is, has, can, or will.

Arrays

Name arrays with a plural noun, allowing us to address each child as a singular noun. If need be, you can replace plural with a collection name birds becomes flockOfBirds.

Functions

Functions are always actions. So we start with a verb then add a noun. Verb + Noun results in a command for a thing.

getBirds();
goHome()

Some languages have their own rules around specific types of things (TypeScript prefers interfaces begin with a capital I). I am mostly interested in language-agnostic naming. Do you have any preferences around naming? Bring them up in the comments, and let’s discuss!

Operation Code at The Muse

Richard Dillman — Fri, 25 Sep 2020 15:58:21 +0000

This spring we were honored to connect with Operation Code to host their April Meetup. Operation Code is a non-profit organization serving America’s veterans and their families to help them to sort out their next steps after their service - or sometimes, while they’re still serving. Helping people to find their passions and turn them into fulfilling careers is exactly what we do at The Muse, and we were delighted to pitch in. This being Operation Code, Engineering and Product were particularly excited to get involved.

How do you transition into the civilian workforce as a developer? Senior Application Engineer Richard Dillman moderated a panel of Musers to explain how to master the technical job search, and how to maintain that success once hired. Director of Talent and Acquisition Lillian Landrum shared how candidates can stand out in the selection process. Manager of Client Project Management Danielle Incontrera discussed how people on the technical side can more effectively communicate with product about goals and timelines. Account Manager Christina Giordano explained how engineers help in both sales and client acquisition at The Muse.
Director of Engineering Peenak Inamdar fielded questions on what skills developers need to have on his team and how we at The Muse determine if a candidate’s skills meet those needs.

Following Peenak’s remarks, Associate Product Manager James Mayr gave a presentation on Google Tools for Product and Engineering, an overview of how developers can use Google tools such as Optimize, Analytics, Tag Manager, Lighthouse and Google Search Console to monitor site performance, dynamically add or modify content, and develop approaches to increase speed and reliability. We spent quite a bit of time on accessibility and usability too.

Afterwards there was more pizza and more networking amongst all, with the most popular topic being breaking into the developer role as a fresh code camp graduate. Our conversation carried well past our 9PM target with some of us not leaving until well past 10.

Meetups and Operation Code are both great ways to meet people you otherwise might not, learn new skills, and possibly make a connection for a new career.

Check out the full video of the event

How to write a readable commit message.

Richard Dillman — Sun, 09 Aug 2020 05:43:19 +0000

Having a good guideline for creating commits and sticking to it makes working with Git and collaborating with others a lot easier.

Subject

The subject should be around 50 characters or less. You want it to fit in an email subject line. If you need to explain why you made some decisions or tradeoffs, those comments should be in the code.

An adequately worded commit should fit grammatically into the sentence below:
- If applied, this commit will [Subject]
Use an imperative mood. These changes will not be applied right away
Capitalize the first letter
No punctuation at the end
Consider using a conventional commits prefix like karma:
- feat: a new feature for the user, not a new feature for a build script
- fix: bug fix for the user, not a fix to a build script
- docs: changes to the documentation
- style: formatting, missing semicolons, etc.; no production code change
- refactor: refactoring production code, e.g., renaming a variable
- test: adding missing criteria, refactoring tests; no production code change
- chore: updating grunt tasks etc.; no production code change
A scope or section of the codebase can optionally follow the prefix

Instead of writing down everything you did, think of each commit as a command. These are instructions to your future self. Git will apply your commits to the codebase, not you, and only once the PR is approved and merged.

git commit -m "feat(login): Add a google OAuth endpoint"

Body

If you need to offer more information within your commit (code examples, external references, documentation, explain complexity), you could do it here. But most times, this information belongs either in the code or the final pull request. Please keep this as short as possible. It is not a blog post. Focus on the following:

Give the reasons why you made this change
Explain the way things worked before this change (and what was wrong with that)
Describe why you decided to solve it the way you did
Describe how the code works differently now than it did before

git commit -m "feat(login): Add a google OAuth endpoint" -m "This includes the handler, routes, and templates."