DEV Community: Jen Chan

Who Moved My Cookies? Of Cookies On Subdomains

Jen Chan — Wed, 09 Jul 2025 14:32:53 +0000

Yes, it's 2025, we had the internet and the encyclopedic knowledge of LLMs at our fingertips, and we were still blocked for 45 minutes.

"Maze game for kids cute groovy cookie with pieces of chocolate looking for a way to the gift box" by Maria Kololeva.

The Problem

Imagine, it's possible for a gaming platform to have all of these namespaces:

addictinggames.com
fun.addictinggames.com
cool.addictinggames.com

And other mirror domains could also receive its traffic in the event some of them got blocked by parental controls or libraries, or some no-fun workplaces want to prevent people from playing fun games:

addictinggames.wtf
addictinggames.lol
evenmoreaddictinggames.com
playaddicting.fun

Such a system was set up so that if Johnny was logged in at addictinggames.com but his mom decided to block access to the site, he'd would be able to use addictinggamesmirror.com to redirect his session to addictinggames.wtf and continue playing there. ✌

So, we were going to launch a web 3 game at a subdomain, even.more.addictinggames.com... with the intention that sessions could be persisted to even.more.addictinggames.wtf, even.more.additinggames.lol, so on and so forth.

How hard could it be?

It was impossible.

We had previously used subdomains and mirror domains to persist user sessions for authenticating users.

The cookie was just proof that the user was still authenticated -amongst other things- after a redirect.

While all other areas of the platform showed that a user who had logged in and went back to the view was still authenticated, the proxied request returned nothing.

What we tried

We of course did the usual cookie clearing, logging out and logging in and checking the dev tools.

We checked that there wasn't anything on the client side that was setting or eliminating the cookie –an anti-pattern anyway.

Since the cookie was HTTP-Only, there wouldn't have been any way for the client to access it.

We checked that the cookie was being set on the server side.

We compared headers from the proxied request and the original request.

We tried desperately to specify the destination domain for Set-Cookie to be *.addictinggames.com or even.more.addictinggames.com.

Our manager pointed us to the MDN docs on cookies.

As it turns out:

If the Set-Cookie header does not specify a Domain attribute, the cookies are available on the server that sets it but not on its subdomains. Therefore, specifying Domain is less restrictive than omitting it. Note that a server can only set the Domain attribute to its own domain or a parent domain, not to a subdomain or some other domain.
So, for example, a server with domain foo.example.com could set the attribute to example.com or foo.example.com, but not bar.foo.example.com or elsewhere.com (the cookies would still be sent to subdomains such as bar.foo.example.com though).

See RFC 6265 Section 4.1.2.3 on "HTTP State Management Mechanism".

One does not simply set a cookie on a subdomain

✅ We could expect that a server that responds with the Set-Cookie header and no Domain specified, would only set the cookie to the host server of the document, but not at subdomains.

✅ We could expect that a server responding with the Set-Cookie header and Domain specified to addictinggames.com, would allow addictinggames.com and subdomains like fun.addictinggames.com to receive the cookie.

✅ We can also use the Set-Cookie header to set a Domain attribute to fun.addictinggames.com and expect the cookie to be set when visiting fun.addictinggames.com.

❌ We can't use the Set-Cookie header to set a Domain attribute to even.more.addictinggames.com or even.more.addictinggames.wtf.

So it follows that it would be another magnitude of problematic to expect such a cookie to persist on an external mirror subdomain like even.more.addictinggames.wtf.

The Solution

Sometimes web APIs defy logic.

Don't try to set cookies on a subdomain-of-a-subdomain. Just stick with one level or the parent domain.

Instead of dark-launching on even.more.addictinggames.com, we went with more.addictinggames.com.

Ta-da!

Block AI Crawlers, Save Tears: Ditching Vercel for Cloudflare Pages

Jen Chan — Fri, 04 Jul 2025 21:21:53 +0000

Have you tried self-hosting with Next.js? What was your experience like?

Cloudflare recently announced their decision to block AI crawlers for customers who host with them and offer pay-per-crawl in private beta, which is quite exciting given the declining usability and relevance of Google search.

As a small gesture of meaningless resistance under political and economic despair, I'm migrating my Next.js blog from Vercel to Cloudflare Pages.

I want my blog to be discovered and read by humans!

In principle, listing bots you want to disallow from crawling your site in a robots.txt is a first line of defense, but many crawlers don't adhere to it.¹ Last year, Perplexity was found to be using crawlers that spoof the user agent, such that their bots appear to be human browsing the site.²

Even on a free plan with workers or pages, Cloudflare has multiple features that make it easy to block and monitor AI crawlers:

the option to auto-generate a robots.txt file that covers the popular AI bots
a dashboard that allows you to monitor AI crawler requests, and block them

an AI audit feature (currently in beta) that allows you to manage and monitor AI crawlers, and register verified bots.

It's been 2 days. Interesting to see what hits.

Next.js is fun and sexy when you work with boring technologies

Next.js is intoxicating. I was hooked on it up to version 12. At the time, no other meta-framework provided the control it did for being able to alternate between static site generation, server-side rendering and client-side rendering all within the same application. It was (and still is), quite easy to keep up with. (...Until they started confusing the newcomers and experienced folks alike with the pages router and app router ... shakes fist)

Like Heroku, Vercel -previously now- was a gateway platform for getting into CI/CD. Both Next and Vercel built a wonderful reputation in the community for Scandinavian web design, comprehensive documentation and basically, the ability to go to market without worrying about infrastructure.

It also happens get more expensive as you scale, especially if you want your site highly available in different regions and have high traffic.³

Check out these Reddit threads 🍿

r/nextjs "Vercel pricing 20m requests/month"
r/devops "Why use Vercel when you can go direct AWS ? especially for small projects"
r/nextjs "Vercel pro pricing is fubar"
r/nextjs "When does Vercel become expensive?"

I heard about the proverbial hell with deploying Next.js outside Vercel. As a result, OpenNext was started as a vendor-backed community project to adapt Next.js to Cloudflare, AWS and Netlify. I had to try it for myself.

I wanted to see how easy it would be to deploy my mostly static Next.js blog off Vercel, and I wasn't entirely disappointed – if you're patient with getting past the phantom build errors, prerendering issues and remembering which Node.js APIs are supported by Cloudflare.⁴

Gotchas

I followed this guide for deploying an existing Next.js site to Cloudflare Pages, but also found certain oddities that made this take 6 hours to get to a manual deploy from CLI, and another 6 to automate on Github Actions. And yes, I was troubleshooting with AI.

Bring your own domain

For a while, I had set up my DNS to proxy requests to Vercel's IP addresses. (See Github Issue #7739) But if you intend to use Cloudflare for edge computing, analytics or monitoring, then you might get the most benefit out of transferring your DNS to Cloudflare.

I got mine for $15 CAD/year. Goodbye Dreamhost 😤!

Update your Content Security Policy

You'll need to update your Content Security Policy to allow Cloudflare to run analytics and track real user data.

Prevent linters from corrupting your `wrangler.jsonc` with a dangling comma

cough, prettier, cough

Something in my boilerplate repo was causing the linter to add a dangling comma before the closing bracket of my wrangler.jsonc config file.

Your build will fail when it reaches Cloudflare if you have a dangling comma.

Route-based rendering adjustments

If you have any server functions or SSR-ed pages, routes that use these functions must target the edge runtime with:

export const runtime = 'edge'

Build Time Noise

Every half year or so I have to maintain this Next.js blog and I'll find some new build error after pulling upstream from the template repo. I don't know if it's because I'm using a template repo with a lot of dependencies, or if modern front end frameworks are less stable than a Jekyll site might be.

Prerendering errors may happen on views containing server components or dynamic routes that are statically generated but rely on server functions to populate data that would appear on the page.

19:34:24.622    ⚡️ Invalid prerender config for /blog/[...slug]
19:34:24.622    ⚡️ Invalid prerender config for /blog/[...slug].rsc
19:34:24.690    ⚡️ Invalid prerender config for /tags/[tag]/page/[page]
19:34:24.691    ⚡️ Invalid prerender config for /tags/[tag]/page/[page].rsc
19:34:24.691    ⚡️ Invalid prerender config for /tags/[tag]
19:34:24.691    ⚡️ Invalid prerender config for /tags/[tag].rsc

This was ultimately benign but annoying.

ESM conversion

I had to update my eslint, tailwind, and prettier config and package.json type property to support ESM imports and default exports. Then I updated next.config.js to next.config.mjs and use ESM named imports instead of CommonJS' require.

If your Next plugins haven't been imported as ESModules, you'll have to convert them to ESM. Unlike the commonJS version of next.config.js, there is no module.exports.plugins property, and you have to use the plugin as if it's a higher-order function taking the config object as an argument.

Before

const withContentlayer = require('next-contentlayer2')

module.exports = withContentlayer({
  plugins: [withContentlayer, withBundleAnalyzer]
})

After

import { createContentlayerPlugin } from 'next-contentlayer2'

// Use createContentlayerPlugin instead of withContentlayer
const withContentlayer = createContentlayerPlugin({
  configPath: './contentlayer.config.ts',
})

const config = {...}
withContentlayer(config)

Add Cloudflare's Github App Integration

The Github app, ["Cloudflare Workers and Pages"]( can be installed (https://github.com/apps/cloudflare-workers-and-pages) to enable automatic builds after pushing to main.

I had initially set up Github Actions Workflow with the CLOUDFLARE_API_TOKEN environment variable to build the project, then deploy the static site on Cloudflare. I found that the automatic builds on Cloudflare's side was much faster, while server side calls were 429-ing on my Github Actions workflow.

Self-hosting Next.js full stack apps will require more legwork

If you're deploying a full stack app instead of a completely static site, DON'T use @cloudflare/next-on-pages. Use @opennextjs/cloudflare instead.

The Workers runtime supports a broad set of Node.js APIs — but the Next.js Edge Runtime code intentionally constrains this ↗. As a result, only the following Node.js APIs will work in your Next.js app:

buffer

events

assert

util

async_hooks

Maybe I'll try this Next (ha ha).

Conclusion

Moving from Vercel to Cloudflare Pages was a petty decision driven by the need to scratch a CI itch in the dead heat of nuclear AI summer.

It's not impossible to deploy Next.js off Vercel, but it does take longer than usual due to Cloudflare's and Vercel's limited support for Node.js APIs.

As the ecosystem of tools and platforms become increasingly subscription-driven and stack-based, developers and businesses alike will need to make deliberate choices to avoid vendor lock-in and bot-proof their intellectual property.

I could see challenges with applying this to a larger fullstack enterprise project where multiple services and edge-related features would need to be migrated or rewritten and re-configured on Cloudflare, but where you have an able developer, the cost savings could be substantial.

Virtue Signal 🎀

I wasn't paid by Vercel or Cloudflare to write this. I am however, looking for a new role where I can dabble with this kind of stuff (◕‿◕✿)

The Thankless Complexity of Custom Form Validations

Jen Chan — Thu, 03 Apr 2025 01:44:24 +0000

One of the least exhilarating but common development tasks are building forms, and form validations. While important, they're often over-designed and easy to over-engineer as a result.

I believe we've gone too far with trying to accomodate all kinds of form validation while building reusable input fields –– especially for component libraries and design systems.

The Browser Already Handles It

Default HTML5 on-submit validation in Chrome. This is what happens when the submit event is called on a form and the incorrect data or required fields are not filled as a result of the HTML constraint validation API calling checkValidity() on ElementInternals or form.validate() methods.

The most basic validation happens on submit, when the user hits a "submit" button associated with a form element.

It's not styled nicely. It doesn't look or feel consistent across browsers, but IT JUST WORKS.

Form input elements have built-in validation attributes for min, max,step, minlength, maxlength values, and regex matching on the pattern attribute for things like phone number format masking.

If you stick to validating on submit, could very well validate a form without using Javascript! ¹

The drawback: errors that show up from failed submission attempts won't disappear til the user retries submitting the form.

All the ways to validate

Each type requires invoking validation on the form field at different moments of the user journey.

Validation as the user interacts with a field (oninput, onchange, onkeypress). Also called "live validation".

Slack's implementation of live validation on a password field with a strength meter under the field provides instant feedback on whether the user's password fulfills password rules.

Validation that runs when the user pauses, or has finished typing in a field (onkeyup with debounce) is less common besides finding them on username and password fields. I don't think it's necessary to including such behaviour on regular input fields in component libraries.

Validation that runs on submission (onsubmit) - and should prevent any erroneous data being posted if there are errors in any form field.
Validation that shows on fields after form submission due to responses from the server

One would expect that post-submission, server-side errors are reflected on the form, under corresponding fields that had incorrect content.
Validation that runs right after the user has interacted with the field (onblur) - otherwise called "late validation"

Unpopular opinion: I recommend sticking to this when there is a need to build ultra-fast. You will dig your own grave otherwise.

Agreeing to implement live validation, if not scoped carefully, will result in hellfire from all directions since:

validation can run prematurely and aggressively, especially on fields that are required but incomplete.
you'll be playing whackamole to remove validation errors whenever they're corrected, which means detecting change oninput or onkeypress and removing the error message when the field is valid again, particularly on fields that are dependent on each other.
you end up tempted to add more feedback mechanisms like toasts to prove the form submitted

Treacherous Variants

Let's look at some well-intentioned UX patterns that explode the combinatories of visual and accessiblity testing since form layouts are so varied.

Andrew Coyle, "Forms need validation", Medium, Dec 16. 2016

The option to show validation messages above, below, or adjacent to a form field
Showing validation errors inside a tooltip or popover
Showing multiple validation messages above, below, adjacent to any form field 😱
The heavily debated best practice of indicating required inputs with an asterisk, OR appending "(required)" to the field label, OR only showing "(optional)" next to optional field labels.
Showing a summary of form errors at the top or bottom of the form on-submission

W3C, "Easy Checks - A First Review of Web Accessibility", 2023

"Form Validation", Siemens UI Design and Patterns, User Experience Toolkit

To Make a River Flow Backwards

Developers easily do more absurd work to make validation possible.

2 examples of how garden-variety form fields grow more complex than they should be:

Live validation, all the time.

Until a year ago, developers had to deliberately prevent live validation from running on page load if it was a requirement.

When the form is first rendered, the fields are empty, and immediate check on validation by browser APIs will show the :invalid styles on the fields with the required attribute set.

We'd have to tell the form not to display invalid styles, especially those with the required attribute set while validating empty fields on initial page load. Alternately, we might opt to prevent live validation from happening until the user interacts with a field after initial page load.

Luckily, the :user-valid and :user-invalid pseudo-class CSS selectors just reached baseline status in 2023, so we can style the form fields based on user interaction instead of :invalid, which reflects field element's validity.

Showing multiple messages above and below a form field

We'll just conditionally render more icon-message molecules as they arise 😛

Displaying multiple inline validations on columned form layouts with multiple fields in a row causes layout shifts and misalignment when space the element occupies dynamically changes whenever the validation message appears.

Avoid all-in-one solutions

Can you imagine a text input component that on top of its usual props, includes a littany of optional props or attributes like validationMessagePosition, isContentVisible, showValidationInTooltip, validationTooltipPosition? Yuck. (I recall this AirBnB talk about how a button component festered in attempt to support all variants.)

If you're working on a design system, developer adoption of form elements will require clear working examples of how inputs will interact with form elements to show validation - especially if you're supporting multiple frameworks.

Before you build, clarify base cases that you're supporting with and spend time solutioning for how users can extend form elements.

It may look smart to build the all-knowing form element that will alternate between displaying the correct visual features for numeric, text, currency types in a single field, and conditionally render the right input... right?

IT'S A TRAP – even if many attributes between number and text inputs are similar.

Be Skeptical of New Wheels

Sometimes people think they're being clever by designing or building the world's most usable datepicker.

Any efforts to reinvent this pattern is signing yourself up for 4 times the work and even more errors.

There's a reason why <input type="date"/> exists.

The value it gathers is an ISO 8601 "YYYY-MM-DD" string but it comes with inherent APIs, valueAsNumber and valueAsDate that returns an easily transformable Unix epoch timestamp and Date object respectively to make date and time calculations easier.

Creating multi-input datepickers from scratch sets you up for exponential efforts with testing and maintenance as you'll have to account for differences in leap years, locale, daylight savings time, and more. You'll acheive more reliable input and validation with an HTML5 native date input.

Custom validation: the developer's dilemma

Careful separation between the presentational and functional responsibilities of different input fields, building mechanisms to accept validation rules, and offering users mental models of how to achieve custom validation with abstractions is vital to developer adoption of form elements.

The best kind of validation you're going to offer is the kind that you won't have to write.

Most developers who have to cram-build forms have a stack-based favorite for runtime validation. And most libraries do this with a config object or wrapping the native ConstraintValidation properties.

Angular's forms has the dirty and touched flags to indicate if a field has been interacted with. Inputs can extended by Validators to manage validation rules, while FormControl tracks the validation state of the field.
For Vue or Nuxt, Formkit offers validation-config props for declaring validation type on the <form> and <input> level. It accepts an object of ids and errors which can be reactively updated to include any errors that are pertinent to the form state. The @formkit/zod plugin allows Zod to be used for runtime validation.
React Hook Form uses useForm and useField hooks to manage form state and validation.

For cases that require showing multiple validations, publishing examples of how users can customize and extend existing components to achieve their goals while integrating with their stack's ecosystem would be a path of lesser resistance than ensuring every field packs in all possible validation scenarios.

Web components: The special snowflake

Implementing Form Associated Custom Elements (aka. form element web components) can be frustrating when there are no dominant patterns established on writing web components for reuse, particularly when there is a need to expose the ValidityState API to enable the display of multiple, conditional errors.

Look at how much vanilla code you'd have to write to make an input field that shows a custom error message when a required field isn't populated!

Make it harder for users to screw up

Data entry is a means to an end: collecting data allows teams to improve the product or enable users to acheive their goals.

The sooner and more validation errors you show, the more punishing it is for the user, the higher the abandonment rate. ²

Next time you're approached to build custom form fields with validation or interactions, consider where your work fits within the org. If you're working on a design system for a product that deals with time, it might be a worthy effort to reinvent a better datepicking experience. But if you're at another run-of-the-mill startup where your work should have been done yesterday, then using tried and true component libraries will save you teeth-gnashing and heartbreak.

Gerardo Rodriguez. "Progressively Enhanced Form Validation, Part 1: HTML and CSS", CloudFour. August 7, 2023

Marco Campos. "Form validation with (almost) no JS". 2023 ↩
Edward Scott. "Usability Testing of Inline Form Validation: 31% Don’t Have It, 4% Get It Wrong", Baymard Institute, Jan 9, 2024. ↩

A Mid-career Retrospective of Stores for State Management

Jen Chan — Sat, 21 Dec 2024 14:20:36 +0000

Working on a living product after 2 years on design systems and component libraries has inspired reflections on technical choices of startups past.

In this post, I recount some learnings from using or refusing common, "boring", flux-informed stores for managing application state.

🍿 The following is a tale of 3 front end architectures spanning 2018-2024, each with a different stack and state management solution in a regulated domain. ¹

I. The fintech app with several thousand trial users

The Stack: React 14, React-Redux, Yup, Bootstrap, Express, MongoDB, Redis

My first encounter with sophisticated store usage was React-Redux at a B2B fintech company in 2019. We were using React 11 for dual-module application, its state all sewn together by several connect() functions.²

Redux solved the need for a view-level source of truth to organize feature-specific state, especially when different parts of the app needed to access information specific to a particular feature.

Below is a simplistic view of feature states to enable the user to add stocks to portfolios, and contact customer service.

Each feature has its own reducer, and the store combines them all.

// store.js
const configureStore = () => {
  const store = createStore(
    rootReducer: {
        account: accountReducer,
        stock: stockReducer,
        support: supportReducer,
    }
 ...
  );

  return store;
};

The plans reflect these business requirements:

the ability to find and add stocks to a portfolio
to view and compare the progress of purchased stocks
the ability to privately discuss portfolios with customer support agents

Just as you wouldn't make an API call to the server every time you need to display data, a store acts as an intermediary space for storing and manipulating presentational data. POST or DELETE requests to your server could then be made as needed and responses would also update the store.

With each app feature having its own store, operations around specific modules are easier to maintain ...as long as we plan carefully.

II. Modernizing a surgery prioritization system

The Stack: Angular 8, Dynamic forms, RxJS, and Angular Material, FHIR Server

In 2020, I landed at a health tech company whose forte was clinical data storage, but they were trying to make headway on health apps. On one of their projects, my team was tasked to rewrite a legacy .NET surgery prioritization system into an Angular 9 app for a provincial health organization. Their primary users would be hospital admin staff.

The app would take a combination of answers entered into an 8-part form with 120 fields to assess how soon a patient had to undergo surgery.

It's not as serious as a medical device, but impactful to patient health outcomes to the extent the app decides who gets a brain scan before whom.

Angular’s MVC structure meant service classes performed the passing of state between views.

Our form was doubly-dynamic:

fields that were displayed depended on a question-answer model, basically running through Formbuilder
subsequent fields that were displayed were dependent on combinations of inputted values of other fields

Oh yeah, stakeholders decided that each field had live, oninput validations that were dependent on the values of other fields.

Doesn't this sound like it's ripe for a state management solution?

Well, we didn't use one.

Instead, we used observables with RxJS to subscribe to streams of async event data, and used service classes to pass data between views.

What happens if when only use services to share state?

// question.service.ts
@Injectable({
  providedIn: 'root'
})
export class QuestionService {
  getPatientIntakeQuestions(): QuestionBase<string>[] {...}

  getPatientProcedureHistory(): QuestionBase<string>[] {...}

  getPatientEncounterHistory(): QuestionBase<string>[] {...}
}

Service classes get longer and longer with custom methods to check for specific conditions.
State was transient and could only be debugged through inline console logs
Where you had conditional adding of fields you'd have to loop through form groups to check whether an AbstractControl on a particular nested form group's form value had been interacted with.
Conditional rendering and live validations relied on runtime checks against a JSON file with 280 combinations of custom form validation rules.
Business logic starts creeping into controllers, and lines blur for where to put functions that load and update state or cause side-effects.
We abused post and fetch requests to store any state change in the absence of a sink to hold any change in state

At the time, Angular didn't have standalone components and we didn't know about Angular Universal's capabilities of SSR.³ We made multiple API calls sequentially to fetch and populate form questions and previous answers after login, instead of server-side rendering the form statically.

Due to the length of the form, there was a requirement to save any answers up to point it had been filled. LocalStorage wasn't an acceptable solution due to the sensitivity of patient health information. It's likely we posted the "auto-saved" versions at idle intervals to a different endpoint.

// dynamic-form.component.ts
export class DynamicFormComponent implements OnInit {
  form: FormGroup;
  constructor(private formBuilder: FormBuilder, private questionService: QuestionService) {}

  ngOnInit() {
    this.form = this.formBuilder.group({
      patientIntake: this.formBuilder.group({
        questions: this.questionService.getPatientIntakeQuestions()
      }),
      patientProcedureHistory: this.formBuilder.group({
        questions: this.questionService.getPatientProcedureHistory()
      }),
      patientEncounterHistory: this.formBuilder.group({
        questions: this.questionService.getPatientEncounterHistory()
      }),
      patientSurgeryHistory: this.formBuilder.group({
        questions: this.questionService.getPatientSurgeryHistory()
      }),
      ...// and on and on and on...
    });
  }
  ...
  onInputChange() {
    // check if a field has been dirtied
    // check if a field is part of a formgroup that should have an instance added
    // invoke live validation for form fields
    // show the errors above form fields
  }
  ngOnSubmit(){
    // loop through all forms 
    // show the form level validation errors above the form
  }
  onSubmit() {
    // the actual form submission post request
    this.formService.submitForm(this.form.value).then(...
    // notify user of any response errors
    )
  }
}

App architecture wise, we used some weird hybrid between modules separated by domain and angular's "shared" folder structure.

Dynamic forms and reactive forms fulfilled the need to render different form data models, but this got tacky as soon as we needed to:

conditionally render nested form groups or fields
display previously entered information or conditionnally disable previously filled fields
add another field instance to a form when it's edited or filled
validate form fields based on the values of other fields

The disaster that arose from not using a state management solution: longwinded, overly imperative ("if-abc, else if xyz, else if jkl..."), and much harder to maintain and debug code.

III. The 7 year old shopping app that was never refactored

The old stack: Nuxt 2, Vue 2, VueX, Tailwind, Vercel, MySQL, Laravel

The new stack: Nuxt 3, Vue 3, Pinia, Tailwind, Cloudflare pages, MySQL, Laravel

In the past year, I've been working on migrating Vue 2 and VueX to Vue3 and Pinia in Nuxt 3 for an e-commerce app.

Imagine an app for boutique knick-knacks starts by hydrating a user store with all the info related to a user whenever they login.

At the beginning, the business only runs in Canada. It's good enough to have everything in one single store.

Later, this app decides to expand in the US and also sell American goods, and offer specific coupons and promotional discounts to American users.

Developers decide they need to create an order store to handle the possibility a user may shop in different currencies and payment methods (A contrived example, but not far from what I've seen in the wild).

The specific project team hurtles to roll out a new store for American orders, but still keep the original one to handle Canadian orders.

What could go wrong?

The store is split into modules that pertain to domain features, but it has a couple oddities:

Similarly named state properties and actions. orderStore().confirmOrders() and accountStore.purchaseItems() perform the same function, but they're in different stores. The accountStore has an items property that tracks order.data.items in the cart pre-checkout, but so does the orderStore for orderStore.items in the cart, post-checkout!
Duplicated state: while the account store would be populated with user-adjacent info right after login, the order store is updated whenever it's instantiated in American users' sessions.
Missing knowledge loops: Many features of the app still rely on the legacy order.data.items property, but the orderStore's order.items inventory needs to be displayed in US currency. Without cataloging and updating areas that rely on the old store, the display of the correct cart continues to falter.
Getter abuse: The accountStore has getters that detail trivial pieces of user state that have been tacked on over time:
- isSubscribedToNewsletter() is already denoted by the property user.hasSubscribed returned from the API call.
- isVegetable() might be helpful for vegetarian users, just as ordersWithoutPeanuts() would for all cart items without peanuts, and might have been a feature request quickly implemented to serve those with allergies, but not needed by all users. These two would be better off as computed properties in a useDietaryRestrictions() composable.
neither store was fully migrated to Vue 3 composition API.

And so, the more features added, the busier the team gets with patching and reconciling state in both stores 😱

Poorly architected stores can act like daisychained info flows, but not in the way that you'd want!

Eventually, someone has to rip the bandaid off in order to move ahead:

retire the use of accountStore and relocate Canadian and American orders to show under OrderStore
If the separation is worth longterm sustainability, then 2 stores might co-exist independently with the same data:
- we can get the second store to subscribe to the first on load, then on state change, dispatch the actions in the second store.
- OR, we get rid of hydrating the first store and instead hydrate the second on load so we won't have to keep 2 stores' data in sync.

Why devs hate stores

Setup drudgery and boilerplate

The amount of code needed to set up a store, actions, reducers and dispatchers can be overwhelming for newcomers.

VueX itself is particularly verbose with introducing the need to commit mutations before dispatching actions.

To be effective with stores, developers needed profiency with a framework's rendering mechanisms consider the tradeoff of strenuous setup and boilerplate for the benefit of shared state between views.

Every action had to be created and dispatched via the reducer, and any container view using the store had to be connected to it. I don't recall how many times I wrote mapStateToProps and mapDispatchToProps.

Redux is rather overkill in today's front end ecosystem if you're building an MVP, and as of late more have been using redux-toolkit or useReducer to update slices of state.⁴

Premature optimization leads to higher maintenance efforts

Creating a store for every app feature can lead to unnecessary complexity and coupling. When multiple stores share the same data source, developers have to remember to keep states synchronized or remember which store depends on another. Premature code splitting can confuse teams and make maintenance harder.

The more stores you have, the more state you have to keep track of!

To store or not to store?

Using a store for state management is ideal when:

There is complex, domain-specific logic that needs to be diligently updated as part of a larger product or platform as a user navigates through different views.
It becomes unsustainable to manage state within one or two components and you find that you're passing the same data properties across multiple components. (aka. prop-drilling)
There's a need to present or update different types of data across different features of an app, or work with nested deep data structures to update the UI.

If there are multiple dimensions of state to track, a store may not offer enough granularity for defining exact state transitions. It may be worth looking at implementing a state machine (some libraries include XState or Immer)

For example, if you need interaction changes through multi-step forms, wizards or like the combinatories of form fields I previously described.

Caveat: I have not had to use above libs yet.

It's easy to get to a place where no single pattern is used, but someone somewhere, at some point is going to take issue with whether you use:

Container-component pattern
a provider that encapsulates state and actions for a component tree (the basis for Context API)
an observer-style event bus,
a singleton that can be updated from anywhere in the app (React Context and Vue composables might be lightweight ways to do this, but I have found that composables are not good replacements for behaviour you'd expect from singletons.)

Contemporary state management

Front end frameworks today offer lightweight options for state management.Leveraging out-of-the-box mechanisms will suffice for small to medium-sized apps.

React's hooks (useState, useEffect, useContext) allow for easy encapsulation of reactive business logic. The Context API reduces prop drilling by making state accessible at any component level.

Vue's computed(), ref(), and watch() functions, along with composables, achieve similar results to React hooks and context.

Newer options like signals in Svelte and Angular are also emerging.

Frameworks aim to:

Reactively update the UI when data changes
Subscribe/unsubscribe to data changes
Manage side effects
Distinguish between local, shared, and global state

Where you need it, it's probably wise to choose a strategy before entropy takes hold.

The contents of this post are based on my work experiences but I've changed exact details. ↩
React's fundamental principles promoted thinking about data moving through components in a unidirectional matter, and devs could easily control rendering and interactions with methods like componentDidMount and componentDidUpdate. ↩
Wassim Chegham. "Angular Universal for the Rest of Us" https://medium.com/google-developer-experts/angular-universal-for-the-rest-of-us-922ca8bac84 ↩
Dan Abramov. "You Might Not Need Redux", Medium, Sep 19, 2016. ↩

The Dual Nature of Seniority in Software Development

Jen Chan — Fri, 12 Jul 2024 16:27:58 +0000

Disclaimer: Like everything else coming from me, this thinkpiece is entirely my own opinion and doesn't reflect the views of my current or previous employers.

I think it's important to share nuanced perspectives on career and personal growth to combat the stigma of failure, survivorship bias, and other things that make moving up and staying in this industry seem more glamorous or effortless than it is.

For a mainstream take, check out Gergely Orosz's "The Seniority Rollercoaster".

Theory of the Senior Developer

Every company has different expectations for senior developer performance.¹ As long as your title has "developer" or "engineer" in it, you're hired to do one of the following:

implement features or fix bugs independently with minimal guidance or direction, mentor less experienced devs, review code
research and solution complex or ambiguous problems your superiors don't have time to tackle

2.5 –and by extension, scale your abilities to level up team(s) as part of executing a technical vision or strategy, which may also include offering hiring, training, cross-departmental collaboration, and other leadership functions to alleviate the burden on your superiors.

Which were you hired to do? What are you able to do?

If you're not successful, why the gap between what you're doing and what you're expected to do?

What Changed?

When I first started in industry it appeared that expectations of "senior" included all items listed. Senior was a common terminal rung. Over time the career paths for technical leadership seemed to expand to include principle, staff, lead, and architect roles.²

And so it follows, title inflation and varying specialization of roles in different sized companies make expectations and opportunities for growth rather wavy when one embarks on that first rung.

It's been 10 years Edmund Lau wrote Effective Engineer. During its time of writing, interest rates were lower, allowing tech companies and VCs to borrow money more, and companies spent much more on R&D and competed for talent. The myth of rags-to-riches bootcamp-grad talent and self-taught dropout-unicorns were alive and well.³ Founders lamented over the lack of "10x developers" hires and offered 20% time to encourage devs to brew features and improvements they didn't know they needed.

Today, the cost-consciouness fueled by delayed-onset pandemic-rebound cutbacks, and the premature outlook that AI automates dev work have re-prioritized basic efficiences and delivery as senior responsibilities.

The developer traits celebrated in books that made startups-turned-tech-giants successful, aren't the ones that will help you keep your job, maintain a situational workplace reputation, or get promoted.

Hiring managers want cross-functional employees that learn fast and execute – not plan, solution, challenge and lead right out of the gate!

tldr; I think we're seeing shift in preference for Type B "rockstar" archetypes that steadily deliver results without pushing for above-and-beyond, as opposed to Type A "superstars".⁴

We don't go to work to innovate, lead, or "do agile"

We go to work to ship code expediently to meet business goals.

Some leaders mind more than others how we achieve those results, and it's best to figure this out at the interview stage or things can get acrimonious.

Unless you work in big tech company or incubator, the margin and time provided for innovation is slim to none at most workplaces. This isn't a complaint; it's a natural consequence of choosing a career where you trade knowledge work to produce products for money under capitalism.

In all likelihood, your company already has specialists with specific ideas and priorities to deliver on. Innovation requires weathering trial and error and is the most efficient in small teams in the early market validation stage of a startup.

By the time they've hired for your position, you don't have time to mess around with wheel reinvention or delivery lubrication. You're there to provide immediate value or fill a gap in capability. People need you in exactly that position for that function to do that exact type of building and maintenance work well.

Most businesses simply need people who can build well and fast enough without crossing into recommendations of plans or decisions.

You're more likely to find innovation and technical growth in OSS, community initiatives, or personal projects you share with friends who have more experience.

Staring at an undulating plateau

Expecting work to feed your sense of purpose is a tall order. In this economy, it's like expecting a romantic partner to meet all your emotional and intellectual needs.

You can jump your salary by learning different stacks or frameworks at different kinds of companies, ship working results faster. But more or less, with a track record in doing the same things in different domains, more people, over and over... you receive more of the same challenges.⁵

Your time-to-onboard is reduced, but so is the time to dispassionate feature flipping. You become so good in certain areas people would trust you less to do other areas, or they otherwise aren't able to see you go beyond it. Factory-style ticket flipping takes hold.

High performance is what your boss considers high performance

Doing what you're asked to well and being a kind human without crossing into the lines of fire is what John Cutler calls a kind of employee that's a "skilled pragmatist". While Cutler is advocating that this type of employee is the most valuable to engage and under-activated, I consider these types to be living role models I need to learn from more.

The heightened need for professional mindreading

There's an underlying dimension of seniority that I've observed, sets those who are successful and effective beyond senior from those who aren't: professional mindreading. 🦄

This is an inordinately difficult skill to learn and master.

When you move up, anticipating what your boss and team needs without actually being told becomes important. They expect to use less time to spell things out for you. You'd hopefully develop a way of working together that complements and augments their approach. That includes keeping up with what changed before and after vacation, messages and non-updates shared in team channels.

You're expected to read between the lines of what's being said and not said in meetings to evaluate the success and buy-in around a strategy.

You're expected to read the room, know when to speak up, and when to stay quiet.

You're expected to know when to take charge, and when to let others take the lead.

Check-ins and syncs with upper management will provide leads on what matters to them, but how you perform to complement your bosses' strategies without threatening your peers in the day-to-day is the truly insane challenge.

A lot of success shells down to fit between skillset, mindset and team chemistry. There might be pushback or protest against technical strategy or changes.⁶ You'll be expected to back them.

If your manager never had a hire at your level or they're not ready to let someone with their skills take charge, then how you're used to functioning at a previous senior role might come off as overstepping. It can feel puzzling to have some of their skills out-of-the-box, yet not be trusted to do things you could be delivering with your skillset.

If you don't have the title and you're treated as senior in skill, they'll assess you on this element because promoting you and having you around stakeholders inflects on them.

People who are effective and impactful may appear popular but it's actually because they're good at mindreading, in addition to building and maintaining relationships around the org.

Your managers might throw you opportunities to take on staff-level things too, but if you're successful at influencing for desired outcomes, also be wary that your influence doesn't outshine your bosses' or veteran devs.

Proactivity on the wrong thing or misinterpreting priorities will be seen as a waste of time or inability to follow through on exec priorities.

I've been primed to defer to authority and distrust my gut through various failure-intolerant environments, but when you are situationally in authority, you experience the consequences of not acting when it's important to.

And so you're left wondering:
how do you know when to act, and when to step back?

I don't know, and I'm still learning.

That's the way work goes

Every new role comes with new challenges and expectations. Like dating, staying on track about whether a position and the current business goals would leverage your skills and experience is important.

It's become less personal over time to connect the dots that I'm a poor fit, and I'd much rather know of that sooner than go through the motions of a PIP or a textbook quiet firing.

You could on paper, be hitting every goal and OKR, yet hated by management.

You can be the wrong high-potential hire who has the right experience, yet doesn't fulfill the goals or realize the functions set out.

You could be set up to fail in landing a role where they give you the title but no actual resource or decision-making power to hire or build out a team.

Perhaps the way the org is designed doesn't actually require senior capabilities.

No two senior roles are going to function in the same way.

The longer I've been in industry, the more humble I have to be.

Check out Progression.fyi for examples of publically available career ladders from large tech companies. ↩
See Jorge Fioranelli's Engineering Ladders or Sarah Drasner's Career Ladders ↩
Gergely Orosz, "The software engineering industry in 2024: what changed in 2 years, why, and what is next", Craft Conference, May 2024. "How working for Big Tech lost its "dream job" status", CNBC, April 28, 2024. ↩
Kim Scott, "Balancing Growth and Stability: Why Your Team Needs People On Both Steep and Gradual Growth Trajectories", Radical Candor, Jan 01, 2023. ↩
As a front-end focused software dev who's worked with n JS frameworks, I've noticed I'm encountering the same kinds of problems in different scenarios, people, and constraints. In front end, this looks like migrating from one framework to another, highly available headless CMS e-commerce sites, integrating a third party lib or service that is not available in such-and-such flavor of JS, optimizing configurations to reduce build time, teaching people to unit test, rewriting more variations of the same component, finding new ways to architect state management, revamping or rebranding a website. The worst of it is pixel pushing. ↩
Ludic Mataroa. "Your organization probably doesn't want to improve things", October 8, 2023. ↩

🛑 Stop resizing your browser: improve testing for responsiveness

Jen Chan — Wed, 22 May 2024 17:42:24 +0000

This is an expanded thinkpiece around a lighning talk I did at TorontoJS on April 30, 2024. 👉🏻 Slides here

TLDR; use device mode on browser devtools to accurate emulate the experience on mobile and tablet devices.

A familiar story

You learn that you have one week to rewrite the frontend for an app and you're given incredibly high fidelity designs.

After confirming that the designs are mobile-first, you agonize over the breakpoints.

Then come time for business review or quality desk checks, and you notice your colleagues resizing the browser, then mentioning that things don't look right on tablet or mobile.

This behaviour is really problematic for testing complex UIs.

When you resize your browser, you're not testing for responsiveness. You're testing the side effect of how a layout looks when you resize a browser.

Browser resizing won’t account for 👇🏻

Viewport height

This won't match the visual viewport height of the actual devices you'd hope to test on. Chrome on Android and iOS is notorious for having a slippery viewport height that doesn't match the understanding of 100vh in CSS.

Zoom level

Depending on what the developer wrote into the meta viewport tag, the browser is not going to zoom reliably.
Zooming changes the width of the visible viewport according to device pixel ratio. For example, zooming in 150% from 1440px on a Macbook Pro with a device pixel ratio of 2 will give you a viewport width of 960px.

Touch event emulation

There's are no hover or click events on touch devices.

Orientation

The transition or initial load in portrait or landscape mode won't be captured.

User agent strings

These are the series of headers that a browser sends to the server with information about the particular device and operating system that the browser is running on.

So for example, if someone is using Safari on iOS 12 and iPhone 8 and the product specifically has a banner for iOS asking users to use Chrome, you might miss that.

Device pixel ratio

This is the relationship between the resolution and the way in software, pixels are drawn on a screen.

Between Hardware resolution pixels, Device pixels, and CSS pixels

We commonly think of a pixel as one point of light on a screen or a dot on print, but how it's drawn differs between media.¹

The W3 CSS3 spec defines a pixel as:

the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length.

So there's a physical basis to CSS pixels but it's unhelpful for our purposes since most top-of-line devices and screens today come in all kinds of resolutions, most of higher density than 96dpi.

The spec explains there's 2 ways a pixel can be made apparent for us developers:

For a CSS device, these dimensions are anchored either:

by relating the physical units to their physical measurements, or

by relating the pixel unit to the reference pixel.

Alternately, we can think of the CSS pixel as something developers use when developing software for browsers when it comes to defining breakpoints for our viewports.²

Lo and behold, the spec defines the device pixel to refer to the smallest physical unit of a screen". Such pixels are usually constituted by subpixels of red, green and blue. On screens with aspect ratios like 16:9, these pixels are even rectangular!

Higher density display screens have way more hardware pixels than the standard 96dpi, so through some magical downsampling or supersampling, the browser uses device pixel ratio to jam more pixels into 1 CSS pixel.

And that’s how a device with purportedly 750 x 1336px resolution with a device pixel ratio of 2 can still be targeted by a media query of 320px through 600px!

Pro tip: you can actually just type window.devicePixelRatio into your browser console to get the device pixel ratio of the screen you're on. Web APIs 💖

Unintended reflows and re-renders

Narrowing the browser in complex UI with listeners also invokes reflows and re-renders which don’t represent the initial page rendering on device browsers.

If you’re using components with observers like ResizeObservers in carousels, you trigger events and side effects that would otherwise not happen if a user initially loaded the page on a mobile device.

Example: Wayfair's Bed and Bath Category page

Here's an example with Wayfair's Bed and Bath category page –I have no affiliation or ref-links with them; it's just so I'm not using an example from my paid work where I first discovered this disrepancy.

In the gif, you'll see that resizing down will lead to the horizontal layout of categories being cut off. However, if you were to load the page in Chrome devtools, you'd see that the nav items are stacked.

System specs: Macbook M2 with a resolution of 3024 x 1964 using Chrome 124.0.6367.62 with a Device Pixel Ratio of 2

Wayfair's Bed and Bath category page in Chrome devtools on a Pixel 7

The viewport meta tag

You might recognize this piece of markup found in the document head of websites. It tells the content of the browser to render according to device-width with an initial zoom scale of 1.

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

You won’t leverage this native capability unless you load your page in the device width in your browser devtools.

Resizing in responsive mode: Inadequate for components with listeners

Improve Approaches to Testing Responsiveness

1. Free tools for dandy visual testing

If you're lazy (or more likely under tight timelines), you can use tools like Responsively or ResponsiveTestTool.com, or browser extensions like Responsive Viewer will enable quick visual previews across multiple devices at once.

I personally like Responsively for visual testing as I develop when I don't have any paid options as I'm able to also capture multiple snapshots across many devices at once.

Note that while these tools are great for quick visual checks, they won't simulate device CPU or network speeds.

2. Use device mode on browser devtools

This is a first-order approximation of device responsiveness. You can simulate different devices, orientations, touch events, and zoom levels, and to some extent, you can even throttle the connection and simulate the network and CPU speeds of older devices.

Things like this give you an idea of initial page load speeds and interaction to next paint (INP) (how scripting as a result of async events affect the ease of page interactivity).

As a rule of thumb, performance should be of concern if it affects user experience or has a negative impact on business cost.

3. Use a device emulation service like BrowserStack or SauceLabs

Nothing is really as good as testing on an actual device running a browser, but as developers we never have enough time to try every device.

Platforms like BrowserStack or SauceLabs offer virtual instances of real devices and browsers for manual and end-to-end testing. Caveat: subscriptions cost money and are on a per-seat basis.

With Android devices, you can test Chrome on different emulated Android devices with Android Studio's emulator.

You can also read about that time I trolled the internet for free device testing in order to test on IE11.

4. Automate visual regression testing as part of CI

If you’re working on a design system or component library, then automating your unit tests and having visual regression snapshot tests chained up in a pipeline gives you full confidence your front end is behaving as it should!

With this approach, you can catch visual bugs and update the baseline for tests before they hit production. Regardless of whether they're automated, you'll still need a human to write unit tests and to validate what is considered a regression and not just further implementation of design changes.

Next time you're testing for responsiveness, remember that resizing your browser is not the same as testing on a mobile device.

There's a history of thought on this topic due to the freakout around responsive design introduced by the iPhone 3. I really recommend reading "A pixel is not a pixel is not a pixel" and "A tale of two viewports" by Peter Paul Koch. ↩
This demo by Dan Rodney is one of the best I've seen on the impact of device pixel ratio on image rendering. In case you're worried, today it's possible to export at 1-3x density from Figma and to use the srcset attribute in HTML to serve the right image to the right device. ↩

Error monitoring and bug triage: Whose job is it?

Jen Chan — Sat, 02 Mar 2024 16:23:42 +0000

I first learned issue triage as a support drone working on a product that had 300 municipal customers. Several times a day, I'd hop on a call with a CPO to (hassle him to) make decisions on escalated customer issues and relay the handoff or feedback to and from developers. Later these skills translated to subsequent dev roles where discussing triage and related issues seemed a lightning rod depending on the environment. At that point, my role as not-real-dev and troubleshooter was to be a buffer between devs and PMs.

With the continued tightening of engineering budgets in 2024, most workplaces are likely expected to do more with less, so triage and prioritization is a great skill to have in your back pocket that AI won't get right yet.

Competing incentives

From a non-engineering perspective, any maintenance or tech debt can be thought of as nuisance, taking your most expensive resource from focusing on activities that generate revenue–building and shipping new features.

I'm also not surprised if developers don't eagerly volunteer to bug sweep on Sentry or resolve customer support fires.

Maintenance is unsexy; it doesn't directly support value delivery. You don't get the same payoff from working all night to ship a feature compared to shipping a hotfix for something found the day after release.

I haven't seen anyone celebrated or thanked for reducing error logs, patching a bug or backfilling a feature a customer might be losing their mind on.

And yet, both log monitoring and bug triage are crucial to maintaining the ability to ship fast and resolve errors quickly.

Someone's gotta do it

If someone is already doing triage on a somewhat-regular basis, it's probably a product manager, engineering manager, QA or lead dev, or a support person who's combing through like a lone wolf and making independent decisions or chasing down the information they need to make escalations.

If the manager isn't technical, often some unlucky dev gets assigned a ticket they have no idea how to fix or reproduce, and hopefully the originary implementing devs are around to advise why they wrote the code the way they did.

If there's an on-call or rotating support role on a team this might be handled periodically with no shared context or clear decision maker. This is still better than nothing, but the impact ends at delegation and the loop never gets completed on how certain bugs could be prioritized or delegated based on domain or sprint and quarterly goals.

Ideally a core group composed of product, dev, QA leaders meet frequently to prioritize bugs surfaced by support and dev. Unless a company is highly collaborative and mature in agile processes, this doesn't happen as often as it should.

The best triage experiences I had involve a max of 4 people, with SMEs who have done the bug reproduction or understand the backlog item to evaluate effort. The SME likely needs to be fairly confident with their craft or know who worked on a particular domain of the codebase to offer estimates and severity, in addition to considering the impact of taking on the fix to their current and upcoming work.

Triage is only productive if the group agrees on a decision maker. Engineers who waffle on details too long need to be reminded that ultimately all are there to understand the viability and effort of a fix. Decision makers also need to be unafraid of hear out contrasting opinions and make quick difficult decisions given tradeoffs and constrained time. Triage meetings that go overtime because managers won't commit to decisions out of fear. In that situation it might move things along to ask a question as if followed up with your "recommendation" to give them an easy choice, then move onto the next thing instead of keeping them around to hem and haw.

The cycle of neglect

Some version of the following happens when bugs and regressions aren't triaged with input from different SMEs:

Managers delegate bugs to fill capacity in sprints to the brim, assuming an ever-present "nice-to-have" train of bugs devs could grab from when all their sprint work is done.

👇🏻
Developers are assigned bugs with little-to-no context or severity, and no one is assigned to reproduce or investigate the bug.

👇🏻

Every bug from previous releases get indiscriminately spread out across current or upcoming sprints. Cosmetic, pixel-pushing changes are mislabelled "medium" priority while bugs that are actually feature requests get labelled as high deathmarch feature-backfills.

👇🏻

Developers get pulled off sprint work to debug and bandaid the latest production fire.

👇🏻

The team wastes time on low value fixes; the backlog keeps growing ends up frustrating much higher level execs who wonder why velocity and burndown never matches issue input since they have no visibility over the cause of a bloated backlog in the first place.

👇🏻

Everyone contently ignores error logs and focuses on next urgent fires until some other leader escalates it to an exec, who is inevitably going to wonder "Why didn't we catch this issue sooner?"

👇🏻

No attempt is made to plan for the future because you're already off course from pre-existing sprint goals that should have been done last quarter, and developers are already overwhelmed as is. All energy for improvement is exhausted by too many incoming tasks.

👇🏻

The cycle repeats (and some uptight dev blogs about it)

Process introduction as lightning rod

Bug triage can be a touchy process to introduce, especially if there are unclear roles and many titles. If meetings are more often used to re-announce already-made decisions and work culture isn't particularly collaborative, introducing triage isn't going to bode well.

If no one has been doing it, it's highly likely every party believes someone else should be responsible for triage.

If you start doing it but no one knows, then you cheat yourself out of the recognition of technical leadership for helping your team become more effective.

If you start asking managers to participate you might get panicked faces or refusal to be a part of a new process someone else came up with.

If you start (god forbid) showing people how to do it, the people who should be doing it might feel like they're being told how to do their job!

In all likelihood, people already recognize gaps in planning and prioritizing, but are too overwhelmed to fit just one more meeting in.

Summary

On large cross functional teams with no clear decision maker, triage is often skipped or delegated away in the interest of keeping the greatest number of people working on sprint goals. This seems like a missed opportunity for preventing future fires and improving incident response.

Any tools or systems set up for it is only helpful for firefighting or customer support in as much as the right errors are handled and captured.

Without rostered or routine patrols of logs we don't have a picture of what's not working well, and how it fits within org goals.

If you set up logging or process and never check it, it's not being leveraged fully as part of quality or incident management.

Weigh out the fights you're unintentionally starting just by exercising your knowledge on process efficiency. Process improvement is of less concern if a company is prone to behave reactively.

Dissecting the hell that is Jest setup with ESM and Typescript

Jen Chan — Sun, 31 Dec 2023 19:21:59 +0000

Jest: Not So Delightful Anymore

Several months ago, I had the hardest time setting up Jest with a React 18 Typescript project as part of a spike to help teams who wanted to use Jest to test web components that were built with ESM dependencies.

As I polled my peers working on React products, many mentioned they had moved over to Vitest.

The outlook for Jest leading up to this moment hasn't been great. In 2022, one of Jest's OSS maintainers mentioned "no one at Facebook... worked on Jest for years". The project was subsequently transferred to the OpenJS foundation for maintenance and development has slowly fizzled since.

As of December 2023, Jest support for esmodules is still experimental due to its unfortunate reliance on node's vm module for test isolation.

If you discover yourself at a large company where tech isn't a core competency, you might realize there's a world where many revenue-generating products are still chugging along, one-Jenga-move-from-collapse, on ancient versions of Angular and React. A significant amount of time working as a dev at such a company will be spent helping teams figure out how to integrate extremely outdated frameworks and tools with modern web things.

If I'm appropriately tactful, I might eventually persuade them to migrate and upgrade their already end-of-life-d framework if they realize the diminishing returns on clinging to legacy technical choices that only compounds in friction to new feature delivery...

More often, organizational politics make it such that you have to just make something irrelevantly old work with something rather new (and possibly immature) because upgrading or changing tools isn't an imaginable option for said team.

Investigating how last 2 versions of Create React App (deprecated) and Jest could seamlessly import and test ESM web component library was the laughable situation I found myself in.

Oh yeah here's the sample StackBlitz if you don't feel like reading.

Overcoming Configuration Hell

Rotating through some hell combinations of ts-jest, ts-node, and babel plugins as recommended by different official documentation sources, I rehashed the following to get it working:

Use the node --experimental-vm-modules when running the jest as part of your package.json test script due to Jest's API relying on a node vm API that's still in experimental stage for esm scripts.

// package.json
"scripts": {
  "test": "node --experimental-vm-modules node_modules/.bin/jest"
}

We have to tell Node our project uses ESM, so we add "type": "module" to package.json just to support ESM import statements.

This leads to a cascade of necessary changes to turn a CommonJS project to ESM:

changing all CommonJS files with requires("module-name") statements to import x from 'module-name'
changing module.exports to export default {}
change any .js file extensions to .cjs or ESM config files to .mts.

Should be fine right? ...Not if you already have a variety of components and views importing from CJS and ESM dependencies.

At this point you have to decide whether you will isolate the folders that use ESM from the rest of the project to create a different package which can be imported into your CJS project, or if you will just convert the entire project to ESM.

Surprise! Whenever you have package.json type set to module, you'll encounter many errors:

  ReferenceError: module is not defined in ES module scope
  This file is being treated as an ES module because it has a '.js' file extension and '/Users/username/projectname/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.

This next one is easy; just rename jest.config.js to jest.config.cjs.

Add Typescript support.

Install ts-node and ts-jest to help with the execution and transformation of .ts files to .js files before running tests.

npx npx ts-jest config:init creates a jest.config.js file which you can configure to your liking.

// jest.config.cjs
module.exports = {
  testEnvironment: 'node',
  transform: {
    '^.+\\.ts$': 'ts-jest',
  },
  transformIgnorePatterns: ['node_modules'],
  testMatch: ['**/*.test.ts'],
};

Using ts-jest and the transform property in jest.config.ts will help with recognizing .ts or .tsx test files.

But don't use the transform property if you're also using a ts-jest preset! (See the module writer's disclaimer on that)

But wait, there's more! Our test-runner complains about the import/export syntax:

  SyntaxError: Cannot use import statement outside a module

Jest (with some support from Babel) transforms all files to CommonJS before running tests; it doesn't support import/export statements from ES2015.

This is especially infuriating if you import a component or util function that has a direct dependency on an ESM export.
You literally will be blocked on running Jest tests on that particular component. (Even if you already configured your jest config to exclude node_modules).

If you by now, have decided to convert the entire project to ESM, you'll need to use babel to transform all .js files to .cjs files before running tests.

If you haven't already, you'll want to use a babel.config.js or babel.config.json to help with recognizing React .jsx files and transforming them to .js files before running tests.

Our friend is @babel/preset-env

// babel.config.js
module.exports = {
  presets: [
    [
      '@babel/preset-env',
      '@babel/preset-react'
    ]
  ]
};

I've personally found babel/preset-typescript to have no impact on Typescript transformation.

Side note: the maintenance-abandoned nature of CRA means installing @babel/plugin-proposal-private-property-in-object as a devDependency or plugin to be helpful for reducing console noise.

Summary

At the end of the day, you catch yourself needing to decide when linting, transforming need to happen before tests run. I settled on:

typechecking it first with tsc , OR using ts-jest to ensure the types are correct as tests run.
transpiling with babel to CJS before running tests

If all else fails, I also had some success downgrading to Jest 27.x or 28.x instead of bashing my head on bloated config and confusing doc on 29.x.

Crossing the senior chasm

Jen Chan — Thu, 26 Oct 2023 20:39:39 +0000

Until you're working well and closely with senior devs, you might not know you're ready to take on senior or staff level challenges!

For some, attaining the title has become a holy grail pre-occupation as they trudge through workplaces with uncharted growth paths and immature leadership. For others, that title is just a prefix in a long career of building things.[^1]

The skill range, compensation and responsibilities around seniority is wide across industry; it's normal to feel perplexed and never ready enough.

Since you're reading, I imagine you've been contemplating a move up. Here are some ideas after bashing my head since 2020.

What makes a senior dev?

There's many ways to be senior. Check out Neil "12 types of under-appreciated software developers" for traits you might not be aware of.

If we defer to Sara Drasner's Career Ladders, a senior engineer "[masters] how effective they can be as an individual contributor"

What about more specialized kinds of senior? Like an architect or staff engineer?
Will Larsen describes different archetypes of staff engineer.

Which path interests you? Why does it matter to you?

What kind of impact do you want to have on a team and by extension, your community and industry?

How do I get promoted?

To be promoted internally:

you need to demonstrate you get shit done (i.e. are able to complete features independently or guide a team towards delivery)
you've discussed a growth path with clear goals with your manager
you need advocates who will vouch for your promotion and already see your potential
your boss can justify paying you more to his boss

That's a lot of to line up. Wouldn't it make more sense to discover your own leadership style at a new job?

Most companies that need to scale or build product fast and will opt to hire people externally instead of internally promoting whomever has been taking on extra work. If you've been struggling to get a promotion, this is your chance.
Every new job is an opportunity to rebuild the perception of you at work.

There is no dream job. Which bowl of shit do you wanna eat?

What about seniority appeals to you as a next step?

Beyond the apparent credibility of the title, and setting yourself up for better paid opportunities, what are your inherent beliefs about the position?[^1]

Is it a step to another destination?

If you're interested for the paybump and influence, there's easier paths to do that without needing to juggle the sometimes-escalating fuckery of balancing business needs and personalities with learning everchanging technologies to build software.

Signs you're not ready to make the leap

[ ] you're bothered by peers' achievements.
[ ] you feel it's important be right instead of creating consensus in a situations of disagreement
[ ] you prefer to work alone on a project or worry that someone may steal your ideas.
[ ] you can't bear the possibility of being wrong publicly.
[ ] you don't like to spend time connecting with people to build software.
[ ] you don't think it's your job to improve things for your team or make their lives easier
[ ] you don't particularly enjoy learning about emerging technologies or practices
[ ] you're skilled at writing code or learning things fast, but don't like explaining how you do something more than once
[ ] you're not interested in helping less experienced developers grow.

There are too many rude, morale-draining, fear-inducing technical leaders, some of which aren't worth their weight in experience or competency based on how poorly they treat others.

Let's improve the world by not being like that.

Technical rigour is a given, but communication and working with people distinctly unlike you will be the most challenging to navigate.

With that out of the way, let's talk look at how to promote yourself, mentally and occupationally.

Build a track record of Getting Shit Done

Do what you say, and say what you do. Ankita Kulkarni mentions this in "The Leaders Playbook: First 90 Days".

Some ways to demonstrate accountability besides shipping features:

following up promptly and providing status updates to the right people
going to meetings prepared with agenda, acknowledge viewpoints and summarize takeaways
surface risks and tradeoffs while letting people make the final call
helping leaders make decisions when they're unsure
mention priority and provide nuanced but concise estimations given different scenarios
letting people know you broke main and you're fixing it

Take projects to the finish line

If you can write features independently but are looking to gain more responsibility, you might start getting involved in conversations that involve different decision makers across the business.

Or you might be onboarding the rest of a team to implement a solution from a senior developer, unblocking folks so they can deliver their features or fixes on time.

At some point, you'll develop opinions about how to build better, safer, stabler software.

Above: Kim Scott's "Getting Shit Done" circle

The key function of a senior is to force-multiply and support those with less experience while delivering value consistently. Some passion for craft helps, too.

When the business needs it, you'll be the firefighter or code janitor for anything that goes wrong on the codebase. Learning fast to find solutions, unblocking and coaching others, descoping features so folks know what to work on, reminding people to merge their features sooner than later, exploring solutions on shaky ground become common responsibilities in seniority.

It might have seemed heroic when you weren't senior to stay late to hotfix a broken release. After that, it's just part of your job.
Note: I don't believe it's a requirement to work overtime, but such tasks often fall onto senior devs due to mismanagement.

If you've done this, well there's a few more more lines on your resume! ✨

Adjust your signal to your audience

Being able to talk to contributors and leaders from other departments will be important in building trust and improving your visibility across your organization. Outside of talking to developers, you'll need to reframe technical subjects and concerns in laypersons terms with analogies and metaphors.

For example, a product manager doesn't need to know the exact mechanics of what is causing a critical error, but more likely, which error, how severe and feasible it is to be fixed, and who might be best to assign it to.

A tech executive might still code and know exactly what you're talking about if you describe all facets of a problem, but won't have time to read 3 paragraphs.

Build relationships with other senior folk

Assuming you have been doing this for a while (couple years, or even 10!) and you're genuine in your attempts to help others, along the way, you'll meet people above or below or adjacent to your levelling that will inspire, encourage and guide you, or simply be there to help in your darkest hour. Some might even sing your praises.

Or by engaging with online communities you might encounter regulars who you end up getting to know, and they may offer on-the-fly advice or perspective on situations at work.

When you meet develop such relationships, ensure you mutually agree on how they can help you, and your own goals.
The formality and structure may vary.

I've even found as of late, having conversations every six months or a year with someone I used to work with, or with more experience, has been helpful for my own growth.

Don't screw up with mentors, coaches or sponsors

In all likelihood you're a respectful human so this section is more for well, just in case.

Jobs and leads don't show up on a plate just, especially not just because you know someone, intern or volunteer for them.

The one who is your supporter may be sticking their neck out for you by recommending, referring or advocating for your promotion.

So, don't be late to a referral-offered interview, or drop the ball on practicing a presentation you agreed to give, etc.

Performing poorly or being unprofessional will lower the credibility of the sponsor recommending you, thus making it less likely they'd recommend you in the future as it inflects poorly on them.

Reflect and process feedback

Working closely with a team over time, you'll notice gaps between on-the-ground work and management vision. You're inevitably going to encounter disagreements on approach.

If you've gained the trust of your team and stakeholders, they'll be turning to you for help, clarification, for decisions, or just to vent. People all kinds of experience will also be approaching you with opportunities. You may also find yourself manipulated, pressured or gaslit to fulfill different expectations and agendas.

Higher communication overhead from increasing seniority requires increased self management: the ability to maintain professionalism and calm in the face of doom, to identify and reduce personal frustration, or perhaps to not let as many different opinions and reach-outs clog up your work time.

Journaling to document and understand thought patterns and sus out politics without letting stress become a venting chamber to those close to you.

Build a track record of going Above and Beyond

Improve delivery or business outcomes

Your ability to learn a business domain and translate that to an agreeable implementation for a team while ensuring they're productive will be your best asset. This might involve teaching a team how to performance test, a reading group on cleaner code, a multi-sprint or multi-quarter initiative to mitigate tech debt etc.

The tricky part is getting leaders to believe there is a problem and your time would be well spent by solving it for maximum impact. In the same way you have to forge relationships with seniors, regular check-ins with stakeholders up and across will become part of relationships to maintain such that you're able to get buy-in for your ideas. This larger the company, the longer it will take to build trust, and the more layered politics are.

Create welcoming environments

A team is just a group of people that trusts each other enough to work towards the same goal.

Culture ends up being the things people feel able to say and do day-to-day at work; relational "vibes" are almost immediately recognizable within 2 weeks. Consider:

Whose opinions are valued when they speak?
Do leaders ensure those who haven't said anything have their opinion invited?
How do leaders respond to genuine concerns, questions and improvements to the business?
Who ensures their work stays on track, and how do contributors respond to them?
Do people meet and talk outside of required meetings; are they excited to find ways to improve things?
Are people of different levels open to sharing work-in-progress?
Are your leaders mature enough to handle inconvenient truths? What would that mean for how you can do your job?

Signs that people feel empowered and valued for going above and beyond, should read as whether this is a place you can thrive with your expertise.

Creating a climate where people feel safe to surface glaring issues, troubleshoot and unblock each other, share solutions results in improved performance and delivery.

What kinds of experiences of collaborating with others did you feel safe and accepted?

It might be through pair-programming, group discussions, casual chit-chat on DM or getting to know someone's career path one-on-one.

Without psychological safety, people become fearful of surfacing risks and incidents, get competitive for solo recognition, or become disengaged. Departures might be common. Remaining members might shoulder an unfair amount of work, leading to burnout.

Elevate and Guide Others

Pick the most important fights and fires

While working on a single project team, you might have an easy time agreeing on linting rules and naming patterns. If you hop between firefighting or unblocking different products and projects, you may slow a team down by asking them to change too many practices at once.

No one is going to do everything the same way you would, and it's demoralizing for a more-or-less effective team to have someone point out every single flaw on their work. Your time and energy might be better spent solving ambiguous problems and turning stones others don't have the experience to look under.

It takes courage and self-confidence to say what's achievable in a certain time, and whether that time from you or your team is worth it. It takes courage to also identify who might be underperforming and taking more time from you than they should.

Recognize and reward initiative that is oriented to improving team performance and delivery. Acknowledging the effort people goes a long way.

Protect your energy

While managing a community and being a lead dev, I burned the candle at both ends by:

being too involved in everyday ops of all teams
being too hung up on details of how things are done
not pushing back on added priorities often enough

I spread myself too thin and was constantly underwater and completing the next most important task or making decisions to qualm whoever was complaining. Trying to make everyone happy isn't leadership, and people lose respect for you if you don't make hard decisions.

If you are conflict-aversive or have immense people-pleasing syndrome, learning to say no to requests for help and have difficult conversations to advocate for your team (and yourself) will be challenging but necessary.

The difference between now and after with that "Senior" title

Before

When you don't yet have the title people are more likely to treat you in the way that's "one of them" on the team. Your margin for error is relatively high. Reasonable workplaces will resource someone firefight if something goes south.

In the absence of leadership some might even start turning to you as defacto leader for having all the know-how on the project. (Or they're just glad someone is doing the glue work.) Regardless of whether you're promoted, know what you did made you able to move a team and lead them towards delivery and ensure the success of a project. ✅

After

After you land the title, all kinds of expectations and feedback come your way. Your margin for error lowers to a three-stamp punchcard, and recovery from them becomes crucial. (i.e. having a plan of action or finding workarounds, rolling out patches after discovering a solution you created is buggy throughout the software)

If you were a very competent performer, a lot of what you did will still be your job. Code reviews, writing features, unblocking others, etc. But now you'll be expected to that on top of architectural meetings, learning initiatives, firefighting and validating technical decisions or solving problems with no clear prior path.

Navigating ambiguity, full days of meetings to rectify and chunk down initiatives, reorder scope and providing the path forward for teams whether there is one, will become a regular part of the job.

But if you've done this before, you can and will do it again.

Making your way

Figure out what kind of senior you want to be, gather impact notches on your resume, and start applying!

The first 90 days and especially the first year, are a test of whether your idea of "senior" and a particular company's ideas of it aligns with your values and career goals.

If it doesn't work out; don't take it as a personal failure.

So:

[ ] You get shit done. ✅
[ ] You help others get shit done. ✅
[ ] You communicate considerately. ✅

That's all you need to start interviewing in senior roles.

Go forth!

Footnotes

[^1] This is not to deride anyone who believes a title matters. Having a title is helpful for setting expectations around experience to external parties more than it matters internally. Tanya Reilly discusses this in "Staff Engineers' Path" –how Black women are more likely mis-recognized as janitors at workplaces. I am frequently mistaken for a student.

Closing, Cloning, or Disabling the Shadow DOM

Jen Chan — Wed, 01 Mar 2023 14:05:00 +0000

If you have been furiously trying to figure out how to close, disable or extrapolate the contents of the shadow DOM for any following reasons...

to prevent encapsulated styles from being manipulated by developers or content folks using your web component
to secure sensitive code from being exposed to consumers
in order to support light DOM because for whatever reason, your stakeholder or client believes that the shadow DOM must be eradicated and through any means, you must turn the web component into a "normal" component.

TL;DR: DON'T DO IT.

For folks familiar with web components, this may seem like an arcane task that's doomed to fail, but I've been asked to do some version of the above twice in my short career.

The title was just search bait. This is the real article 👇

5 Reasons Why You Should NOT Close, Clone, Or Disable the Shadow DOM

1. Browser APIs prevent disabling attachment of a shadow root

The CustomElementRegistry.define() specification specifically prevents the use of static disabledFeature from being applied to disable the attachment of shadow root on a web component.

Your console will return a DOMException NotSupportedError.

2. Browser APIs don't support cloning

The instant developer sensibility when I heard the client desire to convert shadow DOM children to light DOM ones: well, you gotta parse and transform DOM slotted nodes into generic HTML elements, then move them into the light DOM, right?

With that we reach for Element.cloneNode()... and we'll find the error:
NotSupported ... "ShadowRoot nodes are not clonable."

Here are the exact Chrome and and Chromium tests preventing that.

At this point, I should have probably stopped, but I didn't.

Oh no, being unable to accept failure when presented with heroic feats of front end... I just have to see where this goes.

Even though I couldn't clone the shadow root node, I was able to grab its children, parse and transform them into HTML elements and reattach them to their rightful parent.

Note: I used Fast Design to try out the above while doing my research.

Easy win, right?
IT WORKED IN MY DOM.

But no. Utter failure. I get a "flash of light DOM component". As the shadow DOM remains open, styles continue to be scoped towards shadow DOM elements, looking to scope those styles towards flattened, projected content.

Cloning and moving shadow DOM children nodes, transforming slots to HTML elements and attaching them to their "light DOM" parent element also easily re-trigger lifecycle events via changing the position of items within the DOM. And I had to do all the above within the class constructor because that's where a shadow root is attached.

I had thrown in a setTimeout() to prevent race conditions between the constructor operations and the component registration in the DOM.

This led to multiple re-renders and attachments (go figure, moving the DOM order of children in a component is going to trigger connectedCallback() again and again!)

Well all the above required keeping the shadow DOM open, cloning the shadow tree, parsing it, then to close it all within runtime. As long as the shadow DOM remained open, styles continue to be scoped towards

This leads to my next epiphany... 👇

3. Opening or Closing Shadow DOM on Runtime: Impossible

In my previous example, I kept the shadow DOM open, cloned and transformed its children to light DOM nodes, and tried to close it as a final act to disable the shadow DOM so that my children could render with their new light DOM styles.

I made another attempt at using the shiny-new, experimental declarative shadowroot API that's only available in Chrome currently on a template.

Both were resounding failures. Why?

The shadow mode is set once on class instantiation

If open, the shadow DOM can't be closed during runtime as the constructor that instantiates the attachment of a shadow root determines the open or close mode it is attached to the web component on instantiation.

You're going to get this error:

Uncaught DOMException: Failed to execute 'createShadowRoot'
on 'Element': Shadow root cannot be created on a host which already hosts a shadow tree.

Once a shadow mode is attached and connected, it can't be closed or deleted, but you can attach new ones.

4. A Closed Shadow DOM doesn't secure sensitive code

If you want to hide your styles and prevent them from being altered by whoever's using the components, fiiinee. This is definitely a way to prevent folks from adding extraneous classes to the component in the light DOM.

Writing on shadow DOM V1, Eric Bidelman warns of how the functional and style encapsulation of shadow DOM can be misunderstood as a security measure.

Closed shadow roots are not very useful. Some developers will see closed mode as an artificial security feature. But let's be clear, it's not... Closed mode simply prevents outside JS from drilling into an element's internal DOM.

A black hatter could still inject malicious code into the component constructor.

5. Ditch Shadow DOM; Lose Thy Scoped Styles

As a result of disabling the shadow DOM or converting its children to light DOM elements, you lose the very benefit it offers in web components: scoped styles.

Hypothetically you could use adoptedStylesheets() to replace a pre-existing scoped styles with your new light DOM styles... but you'll have to figure out how to style your DOM to avoid conflicting styles in global CSS namespace. That's a lot of work to do for something you already did once.

Now you need 2 sets of styles to alternate between! One that supports scoped styles, and the other that supports light DOM styles! Why would you do double the work?!

Disable shadow DOM: lose slots, styles, all good things about web components

Finally, my peer @tebin tried disabling the shadow DOM by passing shadowOptions: null into the define() (custom element registry method provided by FAST). By parsing and reattaching slot-referencing children in a light DOM parent, he was trying to see if slots would continued to be supported. But no! In this case we lost all the style encapsulation and previously slotted content would render out of order.

Summary

Most components in web applications and on websites, are based in Javascript. While React and Angular use a series of functions to abstract the creation and rendering of components in client-side applications, web components leverage browser-based APIs and HTML standards.

Would you attempt to re-engineer how React handles children as "slots", or change the way React.createElement() works ...in the same way I tried to close the shadow DOM or make it's children work in the light DOM? (I hope not)

Customizing a technology to do the opposite of how it works-on command-usually ends in increasing friction with the mechanisms that make it behave the way it does.

If web components was already made as a choice for "build once, use everywhere" then your next spikes might be:

What can I do within the environment(s) I'm integrating this in to overcome perceived barriers of shadow DOM?
What can I do with the existing features and APIs of the framework I'm using? (with web components, it may be the framework you're using. If you're working in vanilla JS, it's most definitely browser APIs.)

Let me know what you've tried!

Thanks to Tebin Raouf @tebin, Simon Macdonald @macdonst for programmatic support and guidance along the way!

Maintaining a Healthy-Enough Mindset through Uncertainty

Jen Chan — Mon, 05 Dec 2022 17:41:22 +0000

Climate change, big tech layoffs, inflation, AI replacing work... Things have seemed grim for working in tech.

But this can't be farther from the truth.

I don't know of a job where I can work from anywhere, find help I need at any hour, participate in spirited debates, and wear t-shirts to work. The demand for talent and experience hasn't reduced even if large companies have been doing layoffs. Canadian talent continues to brain drain to the US.

This post isn't going to show you how to keep or find a job, but how you might reframe your thinking to manage anxiety around changing conditions at work.

Competency vs. Likability

The cultivation of competence at work (or on paper) is a strange performance. Women, non-binary, BIPOC and trans folks have the added challenge of nailing this the first 20 minutes of a job interview, and then nurturing it in the first months at a new role -or that perception is stuck to you til you switch jobs.

You need to show the right amount of ambition and political savvy–you can't be too thirsty, you have to be knowledgeable without being intimidating, friendly while clear with boundaries, assertive about expectations without appearing aggressive.

I don't have answers for this and I'm still figuring it out.
What I do know:

When you're new, asking as many questions about how things are done or restating that you're new helps people guide you.
If you've been overly approval-seeking then you're giving whoever you work for all the power to determine your worth.
If you act vulnerable or transparent, watch whether people use it as ammo against your performance-you may be working somewhere that punishes honesty and shoots messengers.
If you are reading this as one recently deemed "incompetent" or just-fired, take the time to process it. It happens more often than people talk about, and there are likely more factors at play that led up to that move, than how you're thinking of yourself now.

Create Virtuous Cycles

One thing I've learned about improving relationships at work is to recognize the roles others had in helping you get your work done. For example, your manager does long meetings with clients so you can spend more time coding. Clue into what others are working on day-to-day, and share openly with them what you're doing.

Appreciate the hidden labor that teammates shoulder to fill in gaps due to understaffing or someone else's incompetence. Is there someone who's setting up meetings and writing incredible doc? They're doing extra to make everyone's lives easier... and sometimes, there is simply no agenda other than to reach the goals your company paid you both to do more easily.

Focus on high leverage activities that are easy for you to do but helps others move ahead and grow disproportionately. When you notice others doing this, go to their manager to commend them.

Help others help you, and help others help others. ✌️✌️✌️

Find Purpose

I heard most people spend two thirds of their adult life doing this thing called "work".

While not everyone needs purpose to make a living, figuring out the following helps with career planning:

What do you enjoy about being a developer?
Which aspect of development do you most enjoy?
What are your strengths vs what you find easy to do and learn?
Where did you envision yourself when you started your programming journey, and what would you tell yourself now?

Write these down and begin making realistic micro-goals to get there.

When you know where you want to go next, you begin choosing more appropriate opportunities.

You begin defining success for yourself.

More about finding purpose by Simon Sinek.

Work on your Internal Locus of Control

You can't control the weather or the interest rates, but you can control how you respond to change, and how you talk about yourself.

Counteract chastising yourself for mistakes with thinking ahead on how you can prevent them going forward.

Recognize the Impact of Scarcity and Abundance Mentality

Have you worked for people who operated out of fear of repercussions? This usually happens in workplaces with authoritarian leadership styles. Fear of failure ends up stifling any experimentation or innovation.

Even without blatant abusive moves, it can manifest in the following ways:

totally quiet meetings where no one talks and everyone is disengaged
refusal to take responsibility or make decisions
deferring the completion of planned tasks even when help is offered
my-way-or-the-highway approaches to disagreement
micro-managing behaviours, including the nitpicking of spelling, grammar or wording
requests for many revisions that don't lead to any solid business outcomes
sudden changes in requirements as you are working on something

With a few experiences, you'll begin to notice that the same work could be done with personalities that possess abundance mindset--people who are open to learning, being wrong and trying again. It's also not your job to help them through this or be the emotional urinal for their concerns. If you're a consultant however, maybe you'll win points by just continuing to bill :D

It takes immense trust and confidence to admit fault, solution and mitigate errors effectively as a team. I've only learned the importance of this by working with people with more experience who had a steady and focused manner of dealing with problems on the eve of a delivery. So it's a net win for productivity and time-to-hotfix if you have a culture of openness.

Some of these qualities are expanded on in the Westrum Organizational Culture Model by devops research at Google.

Reduce contact with those who fan the flames of scarcity mentality, or try to find a way to work around them. Whether intentionally or not, their maneuvers slowly break down the people who work with them.

Anecdote time

Earlier in my career I went through some workplaces that expected immediate results, where unforgiving attitudes and long hours were the norm. I became extremely resourceful at getting things done, but internalized the belief anything I did wasn't "good enough yet". By my fifth job, I was shit-talking work I did that was filling in for a role above my level, while presenting to higher-ups.

Thankfully, some caring senior leaders took me aside and made me aware of the unhealthy self-judgment I carried with me from previous workplaces. I was hard on myself, and this sent a message that I was hard on others.

By not objectively taking stock of my own achievements and constantly comparing myself to others, I didn't have a clear sense of what the reality of demand for my skillset was on the market.

What I wrote here is pretty corny and probably took a decade of reflection across 2 industries, and I-don't-know-how-many-hours of therapy.

What have you recognized as fears about your own employability or longevity at work?

How did you cope with it?

What are ways you've helped others through a difficult period in their career?

Build Time, Runtime, Execution time... What "time" is it in Javascript?

Jen Chan — Wed, 23 Nov 2022 15:03:20 +0000

Last month, I was struggling to give good answers to questions like "Why can't I just plug a .scss file into a link element's href and have that work in development?", or "Why can't I reference a .css file from a neighbouring project's node_modules within a static file?"

A crucial reason for this is due to the way JS frameworks rely on multiple transpiling and bundling processes.

The rapid visual feedback of hot module reloading (HMR) in local development environments can make us forget that the outgoing application code doesn't treat files the same way!

Runtime vs. Build Time

We can't discuss what a "build" means in a Javascript application without mentioning:

runtime
build time
parsing and execution time

Note: I left out compile time since JS is an interpreted language

Runtime

Runtime happens when the software is executing. This can be when an application makes requests and the server responds–maybe after a server-side computed process.

Runtime also refers to the actual tool running the code: like Node, or Deno.*

The idea is further confused by the fact we use node or npm in our commands to run the runtime in local dev environments. 😂

TLDR: npm and yarn are package managers.

Node and Deno are runtimes that create an environment for the code you write to be executed, built, even deployed.

As you're developing, runtimes allow you to access backends, enter environment variables--all in the same place without the need for a browser.

*If you wanted to split hairs, the browser is arguably a runtime environment for Javascript files.

Build Time

Build time consists of the following processes:

Compiling/Transpiling

^{Jonas Bondi. Angular vs. React: Compilers, Medium, 2017.}

When you write modern Javascript apps, you usually need to outfit your project with a transpiler like Babel or Typescript to compile the Javascript to ES5 or CommonJS, a form of Javascript that Node was initially introduced in, and all browsers could parse.

In the case of CSS preprocessors like Sass, it is compiling to CSS. With PostCSS, unique classes might be generated and treeshaken.

Minifying

Merging all code into a single file and removing all excessive spacing such that it is compact, and bundling and runs faster.

Codesplitting

Chunking and separating code to relevant .js files -- such that you're able to import just the files pertinent to a button component, instead of a whole library.

When you run npm run build, all processes mentioned in above are started to prepare a production ready bundle of Javascript, CSS and HTML (often with source maps) that will be ready for production deployment.

Development mode

During development mode, the build tool Webpack's Hot Module Replacement (HMR) feature allows applications to conveniently rebuild at runtime.

In most cases a local cache folder of application code is built, with subsequent changes constantly rebuilt to give developers fast-feedback of end-users' experience as you're developing... but all those fresh buildz don't appear in your output (dist/) folder.

Today there are so many fancy features that optimize the dev experience of being able to preview the code you're writing in JS frameworks (cough Ahead-Of-Time compiling in Angular, incremental builds in Gatsby and for Next, Incremental Static Regeneration uses such caches both in dev and on the server to decrease the rebuild times for its statically generated views.)

With the rise of a newer generation of build tools and bundlers written in Rust and Go, build times are drastically lowering.

Execution Time

Execution happens in the browser. In single page applications, the minified files returned from the server go through what happens after you type the URL into the browser.

"V8 is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. It is used in Chrome and in Node.js..." v8.dev

Fig 2.1 The lifecycle of a client-side web application starts with the user specifying a website address (or clicking a link) and ends when the user leaves the web page. It’s composed of two steps: page building and event handling.
"Secrets of the Javascript Ninja, Second Edition" by John Resig, Bear Bibault, Josip Maras, August 2016.

In the web 1.0 times, a DOM tree would be created by parsing of html files. These days, JS functions (like React.createElement()) create and append those nodes.

On initial load, JS is read (parsed) top to bottom once, and the relevant execution contexts are set for every single function invocation in a first-on-first-off manner. As the session continues, functions are invoked asynchronously in a last-in-first-out manner.

Sukhjinder Arora,"Understanding Execution Context and Execution Stack in Javascript", Medium, 2018.

Aside from the load time, scripting time constitutes the registering of event listeners and dynamic content during the session.

A lot of foundational resources cover Javascript execution, but rarely do we connect all types of "time" to see where they fit together!

Which build tools are you excited for in 2023?

What are concepts that you found hard to place in your programming career?

Let me know in the comments.

Thanks to @naismith Shreya Dahal, Chang, Jimmy Jansen, Matt Mackay for helping me clarify my mental models!

DEV Community: Jen Chan

Who Moved My Cookies? Of Cookies On Subdomains

The Problem

What we tried

One does not simply set a cookie on a subdomain

The Solution

Block AI Crawlers, Save Tears: Ditching Vercel for Cloudflare Pages

Next.js is fun and sexy when you work with boring technologies

Gotchas

Bring your own domain

Update your Content Security Policy

Prevent linters from corrupting your wrangler.jsonc with a dangling comma

Route-based rendering adjustments

Build Time Noise

ESM conversion

Add Cloudflare's Github App Integration

Self-hosting Next.js full stack apps will require more legwork

Conclusion

Virtue Signal 🎀

Related Reading

The Thankless Complexity of Custom Form Validations

The Browser Already Handles It

All the ways to validate

Treacherous Variants

To Make a River Flow Backwards

Live validation, all the time.

Showing multiple messages above and below a form field

Avoid all-in-one solutions

Be Skeptical of New Wheels

Custom validation: the developer's dilemma

The best kind of validation you're going to offer is the kind that you won't have to write.

Web components: The special snowflake

Make it harder for users to screw up

A Mid-career Retrospective of Stores for State Management

I. The fintech app with several thousand trial users

II. Modernizing a surgery prioritization system

III. The 7 year old shopping app that was never refactored

What could go wrong?

Why devs hate stores

Setup drudgery and boilerplate

Premature optimization leads to higher maintenance efforts

To store or not to store?

Contemporary state management

The Dual Nature of Seniority in Software Development

Theory of the Senior Developer

What Changed?

We don't go to work to innovate, lead, or "do agile"

Staring at an undulating plateau

High performance is what your boss considers high performance

The heightened need for professional mindreading

That's the way work goes

🛑 Stop resizing your browser: improve testing for responsiveness

A familiar story

Browser resizing won’t account for 👇🏻

Between Hardware resolution pixels, Device pixels, and CSS pixels

Unintended reflows and re-renders

Example: Wayfair's Bed and Bath Category page

The viewport meta tag

Improve Approaches to Testing Responsiveness

1. Free tools for dandy visual testing

2. Use device mode on browser devtools

3. Use a device emulation service like BrowserStack or SauceLabs

4. Automate visual regression testing as part of CI

Error monitoring and bug triage: Whose job is it?

Competing incentives

Someone's gotta do it

The cycle of neglect

Process introduction as lightning rod

Summary

Dissecting the hell that is Jest setup with ESM and Typescript

Jest: Not So Delightful Anymore

Overcoming Configuration Hell

Summary

Related Reading

Crossing the senior chasm

What makes a senior dev?

How do I get promoted?

What about seniority appeals to you as a next step?

Signs you're not ready to make the leap

Let's improve the world by not being like that.

Prevent linters from corrupting your `wrangler.jsonc` with a dangling comma