Black Sheep Code

Increasingly, I'm finding it hard to hard to get a sense of human consensus on a topic from the internet

All this talk about how AI can build a whole whatever with $120 of credits and a day is beside the point - the bottleneck is how fast we can understand things

New people to the organisation have fresh eyes and can spot issues that old hats might well be used to.

All the talk in the world about certain prompting techniques, models, or workflow strategies isn't very useful unless you can actually measure it

Humans are just as finicky as AI

It helps not gaslight anyone reading the code

Clear code ownership = developers proud of their work, high quality code

AI can provide a lot of content very quickly, and we can feel the need to match its pace.

A dynamic I frequently observe is that the project manager becomes a cudgel against their team members, rather than serving to protect them from the rest of the organisation.

There's a big difference between a job that takes one hour, vs a job that takes one minute vs a job that takes less than a second

There is a school of thought that says 'Just throw money at the problem' - here's why you should be constantly optimising your token usage.

The prospect of having agentic AI do all the real work means that we now focus on tuning the AI, not delivering the work.

This is advice I have for someone who is either pivoting career or has finished high school and is looking at university options.

A common pattern I see is passing every bit of a component's state in as a prop.

Components that are passed as props.children and components that are directly declared by a component have different rendering behaviour - yet they are both just called 'children'.

@inquirer/prompts is a JavaScript library for creating interactive CLI prompt menus

I'm worried that the blog will look samey and like more-ai-slop-everywhere.

GraphQL is one of the cool kids in modern web development - but I generally recommend against using it.

The --onto option of a git rebase can be used to delete a range of commits

If some idea or decision needs to be socialised amongst many people, it may be tempting to get everyone into one meeting and sort it out in one go.

Links to documentation and open issues.

You might have a really good idea, but its not practical to get it commited to version control.

A lot of people are under the impression that context shouldn't be used to store state, because it'll cause the entire application tree to re-render.

The mark of some well designed code is that the act of replacing it is some what straight forward.

I like standardised formats like markdown.

The value of writing one test isn't in testing the code's correctness - it's in testing its consumability.

Sometimes you want to prevent accidentally modifying sets of test fixtures etc.

I liberally throw errors defensively, often not expecting the error scenario to ever actually occur - it would be nice if I could see some real metrics about how often a thing is occurring, without having to leave the IDE.

Mocking API calls, particularly multiple interlinked calls can be cumbersome.

The easiest time to include something in your application is at the start.

A common pain point in testing React applications is when we make a change to a component that exists down the component tree, and this change causes breaks in multiple components that directly or indirectly consume this component.

Video games commonly show helpful hints and tips on loading screens.

Browsers now support ESM modules natively - meaning that we no longer need to bundle our modular code.

Avoid a bunch of state hooks and handlers in your code for things like confirmation modals by encapsulating that kind of logic away in a hook.

There are generally two strategies for caching, 'cache, but require validation' and 'trust what you've already got without caching'.

EcmaScript Modules (ESM) are well established - leading some to argue that we no longer need to provide CJS packages.

It's not a criticism of developers to suggest that they'll copy paste what they already see in a codebase.

JavaScript scripts cannot be evaluated until they have been completely loaded.

Browsers do not need to wait for an entire HTML document to be loaded before it can display it.

TypeScript's type inference is powerful, but it does have constraints.

Indexing into a mapped type a powerful TypeScript technique to allow a collection of all different types, while retaining the type information.

We make use of NextJS's `cookies` function to access the cookies on the server side.

Your React components may wish to listen for changes to made to cookies, whether they were made by other React code, or HTTP requests or non-React JavaScript.

The perfect codebase is a myth.

NextJS appears to well and truely established.

You may wish to proxy node requests via service like mitmproxy for the purpose of analysing the requests its making or generating test data.

Although your component library may not be making use of React Server Components and the like, it can be helpful to see how the component behaves in a NextJS context.

We may wish to proxy the requests NextJS makes, for example through a tool like mitmproxy in order to analyse traffic or generate test data.

It seems like there are no perfect solutions for testing in React.

gci is an interactive CLI utility to select a git branch with arrow keys.