If you’ve already through through the vision and strategy, don’t try to convince yourself to start over when things get hard. Instead, CTFD and JFDI.

In large companies, it's easy to lose the original thread.

1. There is a problem with the product
2. A meeting happens
3. A solution is proposed to correct the problem
4. The solution is added to a feature list
5. Work begins
6. Something changes and the feature no longer solves the problem
7. No one remembers what the problem was
8. A feature ships that makes the problem worse

This can be corrected by changing the way we make our todo lists: instead of writing down a feature to implement ("add new header"), write down the problem to be solved ("people can't find the get started button").

Features lock you into a narrow scope of thinking; problems remind you why a feature should exist in the first place and encourage iteration instead of feature-driven deadlines.

Hey man, love the site. Was looking for a Gatsby site that was open source and public so I could see how Gatsby did from an SEO perspective.

In my audit of your site and a few others, I found 2 reoccurring themes:

• Linking to the non-trailing slash version, resulting in 301 redirects between pages. e.g. https://lengstorf.com/not-a-phony to https://lengstorf.com/not-a-phony/
• Tags, categories, and paginated archives, don't have unique title tags.

Here is a crawl of your site for your records. :) https://www.dropbox.com/s/sdzwzdtbhvn5fvk/lengstorf.csv?dl=0

Ping me with any questions. Overall, I think Gatsby may be a workable long term solution. :)

We always talk about how to achieve peak performance, but we never call out that not every day is a peak performance day. There are ebbs and flows in productivity, and they're part of the process.

Follow-up on a thought in this post about "Someone Like Me".

Some people — myself included at times — develop a "personal brand" that encapsulates who they are. They're not "John Brown" anymore; they become "John the Good Ol' Country Boy", who's conservative and religious and has a "family-first" mindset.

Later, when John Brown feels something that's in conflict with John the Good Ol' Country Boy, there's an issue where a decision has to be made about which John takes precedence — and more often than not it's the brand.

Is this a problem? I don't know. It's probably good sometimes and bad others. Which is why I want to write about it.

I've been working on this one a while, and I've been hesitant to post it because I'm worried it'll offend some people. But... nothing ventured, nothing gained, right?

Anecdote: drinking terrible instant coffee at home vs. drinking great espresso 10 minutes' walk away

It's hard to find things on the blog. Tags and categories are fine, but there needs to be a fulltext search available. This has come up on Twitter, and also I find myself opening the source code to "find in all files" because the UI doesn't help me find things.

Not sure if I can really write this, because we didn't exactly restrict ourselves — but we also only bought things we knew we'd use regularly.

The core concepts would be:

• Don't buy shit "just in case"
• Don't hesitate to spend the money on things you will use often
• Focus on multi-functional items (e.g. a Dutch oven serves the sames purposes as a casserole dish + slow cooker)

idea from a reader:

• on text selection, offer an option to share the selected text on Twitter
• use the Twitter compose URL
• include the URL of the post being shared
• [bonus] create a Cloudinary image with the selected text on it

In #24 and myriad other posts, I recommend that people Find the Why behind their emotions, desires, problems, and plans.

I need to write something up that explains what the hell I mean when I say that.

Every act of creation is first an act of destruction.

– Pablo Picasso

I had a conversation at Generate Conf about how hard it is to finish a project because it requires eliminating options. In order to create a final product, we have to destroy an infinite number of potential final products — and it's really hard to close a door. (See also research where people took lower rewards to keep doors open — the clicking game [find this study].)

Forever ago, I ran a series in the newsletter around Small Adventures: little things that don't take a ton of time or cost a bunch of money that keep things fun, interesting, and challenging. It was a ton of fun, and I got tons of idea from folks, but I never compiled it into a coherent post.

So I should do that.

I started a draft of this a long time back but tabled it because I was worried it would alienate people. After all, this is a post that effectively says, "I'm sad because I don't have any problems."

However, yesterday I had dinner with Ivan, and this idea came up. And I realized that we both had the same fear: if we talk about it, people will take offense because this isn't a "real" problem.

(And for the record, I agree that on the overall spectrum of problems, feeling despondent because you've solved all of your problems and feel restless is entirely in the shallow end.)

But just because this isn't a life-threatening problem — and if we get into a dick-measuring contest about whose problems are "real", it'll get humbling in a hurry: "Oh, you can't afford to buy food? There are people in Louisiana who don't even have access to food, even if they could afford it." "Oh yeah? Well, 87% of the people in Afghanistan don't even have access to clean water." — doesn't mean that it shouldn't be discussed.

So I'm nervous about this one because I don't want to appear to be a privileged, fragile whiner. But I want to put it out there because I think there are a lot of other reasonably successful people who might be feeling the same thing — both the anxiety about what to do now that they've met their goals and the hesitance to share that feeling with anyone else.

But fuck it: I need to be willing to risk my ego if I expect to write anything interesting, right?

I had a great conversation with @shinytoyrobots about the importance of spending the time, effort, and money up front to get something solid in place — whether that's the underlying foundation of a software product; the reasoning and planning behind major decisions; or just spending the money on truly high-quality cookware — and he reminded me of this quote from Terry Pratchett’s Men at Arms:

The reason that the rich were so rich, Vimes reasoned, was because they managed to spend less money.

Take boots, for example. He earned thirty-eight dollars a month plus allowances. A really good pair of leather boots cost fifty dollars. But an affordable pair of boots, which were sort of OK for a season or two and then leaked like hell when the cardboard gave out, cost about ten dollars. Those were the kind of boots Vimes always bought, and wore until the soles were so thin that he could tell where he was in Ankh-Morpork on a foggy night by the feel of the cobbles.

But the thing was that good boots lasted for years and years. A man who could afford fifty dollars had a pair of boots that’d still be keeping his feet dry in ten years’ time, while the poor man who could only afford cheap boots would have spent a hundred dollars on boots in the same time and would still have wet feet.

I want to use this as the seed for a post on investing in yourself and your projects in a way that will make the penny-saved-is-a-penny-earned types flip their shit.

First image is broken. Probably a path issue. https://lengstorf.com/dirt-floors/

I tried to check your algolia searching feature. When search for example for "1b3a9374-1a8e-434e-90ab-21aa7b9b80e7" (I used this string to be sure to get the one and only page) the result links to

https://lengstorf.com/get-form-values-as-json

but it should be

https://lengstorf.com/code/get-form-values-as-json

Description

Hey Jason! I've found myself in the Gatsby community recently while learning React. After catching glimpses of your raised eyebrow and bald head both on Twitter and among the Gatsby contributors, I decided to check out learnwithjason.dev and your blog. Super inspiring stuff! Between your videos and writing about modern JavaScript tools, design, working (freelance) remotely, and sensible productivity strategies, I'm hooked.

One thing I noticed is that the footnotes for some of your blog posts have been pulled out of the popup <aside>. Do you think the problem lies within useFootnotes in the gatsby-theme-jason-blog plugin, gatsby-remark-numbered-footnotes, or elsewhere?

Screenshots

Working

The footnote appears as expected.

Not working, Exhibit A

Footnote text is missing from the popup box, and appears as a paragraph where it's defined:

Not working, Exhibit B

Footnote text is missing from popup box...

Only to appear as paragraphs at the bottom of the page.

So you've got an amazing idea. How do you convince:

• your team?
• the team that owns the thing you want to change?
• your manager?
• the executives?

In each case, you're selling the same project, but there are different interests, motivators, and levels of understanding. Write a post with some ideas and past experiences of generating buy-in across all the different layers of a large organization — both when it worked, and when it didn't work, and when it only sort of worked.

Mid Level, Medium Fidelity — this is where the high-level vision gets gets chopped up into goals. You may hear this called “strategy” or “roadmapping”.

I'll open up a PR for this if it's cool? It's been a minute since I've contributed to OSS!

The footnotes wrapper I've created causes a rerender whenever a footnote is toggled open/closed, and that's causing the Twitter embeds to get dumped. See this post for an example; there's a footnote right above the embed.

This means I probably need a portal or something, since we don't want to rerender the whole page whenever the footnote drawer toggles.

hi there!

Just noticed that the older posts link in your blog is broken. The linking is point to:

https://lengstorf.com/blog//2/

with the extra '/', which lands on an empty page.

https://lengstorf.com/overcoming-fear/

Amplitude is encouraging all of our customers using our JavaScript SDK < v4.1.1 to update immediately in order to avoid possible data contamination. We plan to stop collecting data from older versions of the SDK in early 2019. For more context, please see this article.

This project seems to be currently using v3.4.0. Please update to the latest SDK version v4.5.0.

What do dirt floors have to do with skipping school?

Let me veer off into a seemingly unrelated story to illustrate a point: imagine you’re tasked with getting kids to show up to school. If we approach this as developers, we might start by looking at the schools themselves: is the curriculum engaging? Are the kids being supported? Can we incentivize attendance somehow? Maybe we should look at the buses and other transportation?

And if those efforts failed, we might throw up our hands and call the kids unreachable, or blame their parents and community.

But if we think about it from the UX perspective, we ask different questions: do these kids want to be in school? (It turns out they do.) Why are they missing school? (They’re sick.)

Oh. That’s a problem. And it starts a deeper line of questioning.

Why are these kids sick? (They have parasitic worms and other infections.)

Why do they have worms? (They live in houses with dirt floors.)

How can we fix that?

Through this line of questioning, we’ve discovered a deeper problem. And it leads to a solution that might seem nonsensical at first: “if we want more kids to attend school, we need to get rid of dirt floors.”

But the data supports this: deworming children reduces absenteeism at school by about 25%, and replacing dirt floors with cement reduces parasitic infestations by 78%.

Where are the dirt floors in our projects?

In my experience, every organization has at least one “dirt floor” problem.

When I was a front-end architect at IBM, my team was supposed to be improving the performance of several problematic UIs. As we started our research, though, we realized that there was more than just front-end dev involved: our devs were burning a lot of time and energy struggling with other tasks — by the time they got to UX tuning, they were already stressed out, exhausted, and up against looming deadlines.

We couldn’t just say, “Hey, team, you should be prioritizing UX!” They would agree with that — we all knew UX was the most important thing. However, after spending four hours fighting with a local development environment to get the reverse proxy server to cooperate, there just wasn’t enough time or energy left to give UX the care it deserved.

So before we could fix our UX problems, we needed to fix our dirt floors. We built a few small, internal utilities to remove that frustration: a reverse proxy configuration tool, a helper library that set the proper default configurations for connecting to other microservices, a GraphQL data layer to improve the DX of discovering and using data on the front-end.

Once we fixed the dirt floors, the team made incredible progress on timelines that seemed bureaucratically impossible.

By dedicating time to correcting the DX problems, we went from every dev paying the cost of setting up their dev environment — which meant our users paid the cost of bad UX — to a couple devs paying the cost by building helper tools. We paid once, the DX improved, and the UX improved with it because our developers were focused on the important stuff instead of wrestling with their environment.

Looks like the URL is undefined: https://twitter.com/fquednau/status/1087750356094906368

This makes sense, now that I'm thinking about it, because the location probably doesn't exist during the build. For now the fix is probably just to hard-code the base URL and grab the slug from GraphQL.

page routes have an extra slash: https://lengstorf.com/blog//2/

this causes everything to explode; hopefully this is a quick fix (likely in gatsby-theme-jason-blog)

When you go to the blog post pages and click on older links, the app goes to https://lengstorf.com/blog//2/, which leads to a blank page. There's an extra / after blog. Probably something is off on the link generation logic.

I wrote this as part of another post, but it was way off-topic. I’d like to come back to this and make it more coherent later:

Stories don’t have beginnings and ends. There’s just the moment where someone starts paying attention, and the part where the hero’s life stops being interesting and people wander off.

I’m a long-time believer that everything we do is based on stories. This is true in business, too.¹

One of the hardest parts of working on a project is choosing where to draw the boundaries. Where does this project start? What story is it going to tell? And what does it not do?

Even harder than making that decision for yourself is getting an entire team to agree on the same beginning and ending.

Early businesses, whether they’re startups, side gigs, or passion projects, face myriad problems, all of which could potentially be solved by the business.

Imagine you want to start a restaurant. Where does the restaurant story start? Is it when someone walks through the door? Or maybe it’s where the produce is sourced from? Does your restaurant have its own garden? Do you partner with a local farmer? Or do you not worry about that and get all the food from Sysco? Is your approach to food political² or historical³ or unabashedly hipster⁴?

Software is even harder, because most of us are just making up the rules as we go along, and if we screw it up, we can just make up a new story and turn that into success. TKTK pivot

The challenge with this is focusing. When we can solve any problem, how can we settle down and focus on “the right problem”? And how do we keep our whole team on the same page?

Right about now, the user experience designers are flipping the table and screaming, “That’s literally what we’ve been trying to tell you the whole time!” while furiously pointing to a wall full of personas, complete with and user journeys: business-flavored micro-fiction following Elaine the Low-Attention Executive or Danny the Grumpy Developer on their adventures through our products.

Near my house there’s a sushi place called Bamboo that starts the conversation with their clientele by saying, “Sustainably caught, humanely raised, naturally grown. No compromises.” The web site talks about making an impact and saving the ocean long before it talks about the hours, location, or menu.

Teardrop Lounge focuses on the history and tradition of bartending, and if you sit at the bar on a quiet afternoon you can get a free master class on the stories behind all your favorite cocktails from extremely knowledgable bartenders.

I poke fun at this bar all the time, but Expatriate is one of my favorite places to spend an evening in Portland. Imagine spending an evening inside a Decemberists song; it’s like that.

I've been asked about this on multiple occasions, and I'm overdue to write the follow-up to https://lengstorf.com/remote-work-travel/

Hi there,
Can you elaborate how this variable is used? I see that it determines what schema.org template is used in your SEO module, but in your POST template, it doesnt seem to be set at all. Am I missing something?
Thanks!

Another section that got cut that I want to use later.

Modern tools and frameworks give developers superpowers

Modern tools and frameworks have made things that used to be prohibitively difficult possible for absolute beginners. With just a few lines of code, we can dynamically bind an input’s value to another element on a page. In the DHTML days, this was an expert-level request; today, it’s taught as a “hello world” example by modern JavaScript frameworks.

These improvements come from introducing abstractions. Developers tend to simultaneously love and hate abstractions: we tend to love the abstractions that helped us learn, but we hate the abstractions that make the stuff we’ve already learned easier for other developers.

Feelings aside, the fact remains developers live in a world of abstractions, from compilers to development environments to frameworks. And each of these abstractions has an impact on our developer experience.

Some abstractions changed our whole industry: jQuery made JavaScript accessible to an entire new generation of developers. Other times, they’re small conveniences that add up to huge time savings: tools like Autoprefixer and Prettier have likely saved millions of developer hours by automating small chores in our workflows so we don’t have to think about them.

In the front-end world, these abstractions have created so many possibilities that we’ve started to complain about it, publishing op-eds about JavaScript fatigue and starting Twitter fights about whether stylesheets should be moving into JavaScript.

Regardless of how we feel about any particular abstraction, there’s no denying that it’s now easier than ever before for developers to create incredible apps. The tools and environments we work in are better designed to let us focus on creation rather than struggling with the low-level details. On average, DX today is objectively better than it’s ever been before. (That’s not to say, however, that it’s as good as it could be.)

Don’t forget the community and ecosystem

Beyond the enhanced capabilities and simplified workflow offered by modern tools and frameworks, there’s also the community aspect. Developers around the world are all using the same tools, meaning we’re able to trade support and insight with total strangers.

Popular open source frameworks have active forums and chat rooms, huge back-catalogs of tutorials and deep dives, active issue trackers, local meetup groups dedicated to using them, and even conferences dedicated to pushing the technology forward.

On top of that, there’s an extensive ecosystem around many of the most popular tools, full of plugins, extensions, and add-ons to make tasks that were murderously difficult in the past into trivial configuration tweaks.

For example, consider optimizing images for the web. For a time, this was only possible with deep knowledge of the various image formats. Then, a few developers built command line utilities to optimize images, but these were manual processes that still required a decent amount of knowledge to get the settings just right. More recently, services like TinyPNG have created abstractions around those command line tools so that optimizing images is as easy as sharing them on social media. Or, even better, these tools can now be stuck into a build pipeline so that humans don’t even need to be aware of it at all; it just happens, and the world is a better place for it.

Good abstractions put the right guard rails in place

Another advantage of modern tools and frameworks is they establish best practices and tend to enforce them through convention.

Putting the right guard rails in place is critical for the success of any app with two or more developers, because they help guide decision making toward doing the best thing according to the project’s goals. By choosing abstractions with guard rails that match your app’s needs, you’re able to make the right thing the easy thing — your team will make good decisions by default, and that’s an enormous benefit to any project.

We haven’t even touched team dynamics yet

It’s beyond the scope of this article to go into detail here, but we can’t talk about DX without bringing up its effect on a company’s ability to attract the best talent. If the company is using a stack that developers are excited to work with, it becomes that much easier to convince someone to join the team.

In contrast, if the stack is one that developers dread or that’s known to have a poor DX, it can be tough to hire high-quality developers, and even harder to keep them around.

The dark side of DX

The downside of improving DX through abstractions, though, is that relying on abstractions built by other people means accepting the opinions, decisions, and limitations of those people. Tools and frameworks are built from a particular point of view: for example, ReasonML is (in part) an assertion of its authors’ belief that type safety is worth limiting some of JavaScript’s flexibility. That’s neither a good nor a bad thing, necessarily, but choosing to use ReasonML is choosing to build your apps according to that worldview.

When we choose an abstraction, whether it’s a language, a tool, or a framework, we’re also choosing to live with the opinions of the people who built that abstraction.

One example of developers being bound by their abstractions is WordPress, which infamously maintains support for out-of-date versions of PHP, limiting the ability of developers to use newer features of the language inside their WordPress themes and plugins.

If the developers who maintain your tools and frameworks don’t share your goals, it can lead to problems ranging from naming disputes (#teamsmoosh) to breaking the internet.

This got cut from another article, so I'm tracking it here for publication later.

Abstractions make it easier for things to slip through the cracks

A much bigger risk of using abstractions is the removal of developers further from what actually happens in their apps. Using a framework like Angular or React makes it possible to build apps extremely quickly, but it can also mean we never even notice we’re creating non-semantic, inaccessible content.

As a contrived example, let’s take a look at this React code:

const App = () => (
  <Wrapper>
    <Title>Hello Friends!</Title>
    <Subtitle>Doesn’t this look semantic?</Subtitle>
  </Wrapper>
);

From a DX perspective, this is great. We see right away that our app displays a title and a subtitle, and if our job was to edit one of those, it would take little effort to figure out how to do it.

Underneath this abstraction, however, there’s trouble. The developers who wrote this code weren’t thinking about semantics or accessibility, so the final result of this code is a mess of div soup:

<div id="root"><div class="css-1jm59wz"><div class="css-xb3uqj">Hello Friends!</div><div class="css-18fjbby">Doesn’t this look semantic?</div></div></div>

Through no malice or ill intent, we’ve created a poor user experience because our abstraction didn’t take semantics into consideration.

In some cases, like open source projects, these oversights will be patched by the community as they’re caught, so all we have to do is keep our frameworks up to date. This is one of the strengths of using community-powered tools.

When we use a given tool or framework to improve our DX, we’re at the whim of the developers who work on it. If they never prioritize accessibility, our users will suffer for the sake of our DX. This puts us in a difficult situation: we can give up the improved DX — and the productivity and job satisfaction it provides — in favor or improving the UX of our app, or we can let our users suffer so our jobs are easier.

If we find ourselves making choices about who must suffer — the developer or the user — it’s a strong signal that DX and UX got out of alignment somewhere.

From a reader's email:

As someone who has worked solo / remotely for nearly the past decade, for the past year I have had a gnawing sense of wanting to go back to a job for the communal benefits. My biggest fear is giving up the autonomy I currently enjoy. When I think about managers, bosses, having to be at a certain place at a certain time, I get scared.

I would love to hear a write up of your transition back into a "real job". Entrepreneurship seems to be all the rage these days, and it would be great to get a counter perspective that what you gain in freedom (autonomy), you MAY lose out on one of the most rewarding aspects of life: a community of in-person relationships.

From an email to Deen:

1. Take the time to plan up front. It saves hundreds of hours.
2. Make sure each task has a single owner.
3. If a task is too big for a single owner, break it into smaller tasks.
4. Create a Single Source of Truth (e.g. GitHub issues) and enforce a policy where only things in the SSoT list will be acknowledged and/or worked on.
5. Automate as much of the peripheral work as you can. Make boilerplates, create processes that are enforced by robots (e.g. postcommit hooks to run tests), and other things that are hard for humans to remember and easy for robots.
6. Only set meetings if there's an agenda and a concrete deliverable at the end. If a meeting ends without one or more action items (and a single owner for each one) it was a waste of time.
7. Limit meetings as much as possible — force people into the habit of thinking through what they need before the meeting, not afterward. Follow-up meetings with new questions that should have been caught in the first meeting are a waste of time.
8. Dedicate time to learning/teaching new ideas and best practices. A weekly half-day is ideal (and pays dividends), but at least once a month. Have someone from the team teach about a skill or technique they're good at to everyone else. This builds teamwork, helps build a team ethos, and gets everyone doing things in a uniform way.

Most of it comes down to productivity and following a set of standards as a group. If I know how a project will look no matter who did the work, I don't waste time figuring out where things are or nitpicking implementation details — it's done OUR way, not MY way (or STEVE'S way).

The occasional team lunch or non-work activity so everyone feels like they're part of a team instead of a set of employees is helpful if you can swing it.

Nate wrote a retrospective, and I thought that was a good idea, so I'm stealing it.

Folk knowledge says it takes 10,000 hours to become an expert. But how many of those hours have we already put in?

Right now it's defaulting to the -300... size, which is breaking on anything with a custom srcset in browsers that don't support srcset. Sanest thing to do would be to use the supplied size (no size suffix) as the fallback. This'll hopefully look better than the 300px version as well.

This is probably too nerdy for the blog, but I can write this up for someone like Smashing Mag or A List Apart or Hacker Noon.

This is a half-baked idea that I'd love to explore more deeply:

A good team process makes your team into a “pure function” because it means the same set of parameters will produce the same outcome at the same level of quality, regardless of who the team members are that actually work on it.

The top padding/margin trick to keep anchors visible below the nav bar prevents text selection on the line above a footnote.