James Sinclair
@jrsinclair.bsky.social
I type for a living. Sometimes code, sometimes not.
A maze that exists only as a data structure in memory is a bit useless. We need some way to make it legible to human beings. So I’ve written an article that addresses how we do that.
https://jrsinclair.com/articles/2025/rendering-mazes-on-the-web/
https://jrsinclair.com/articles/2025/rendering-mazes-on-the-web/
August 25, 2025 at 8:18 AM
A maze that exists only as a data structure in memory is a bit useless. We need some way to make it legible to human beings. So I’ve written an article that addresses how we do that.
https://jrsinclair.com/articles/2025/rendering-mazes-on-the-web/
https://jrsinclair.com/articles/2025/rendering-mazes-on-the-web/
I felt like writing about something fun. So I wrote an article about creating mazes with JavaScript. Things got out of hand and it grew to two articles. Second one will be published soon.
jrsinclair.com/articles/202...
jrsinclair.com/articles/202...
The joy of recursion, immutable data, and pure functions: Generating mazes with JavaScript
Generating mazes might not be something you do a lot in your typical front-end job. Some might call it a waste of time. Why bother if you’re not a game developer? Who needs that kind of thing? Sure, i...
jrsinclair.com
August 18, 2025 at 7:54 AM
I felt like writing about something fun. So I wrote an article about creating mazes with JavaScript. Things got out of hand and it grew to two articles. Second one will be published soon.
jrsinclair.com/articles/202...
jrsinclair.com/articles/202...
I can't believe I haven't come across this talk by @kentbeck.com before. It has so much explanatory power.
www.youtube.com/watch?v=Wazq...
www.youtube.com/watch?v=Wazq...
3X Explore, Expand, Extract • Kent Beck • YOW! 2018
YouTube video by GOTO Conferences
www.youtube.com
July 23, 2025 at 10:22 PM
I can't believe I haven't come across this talk by @kentbeck.com before. It has so much explanatory power.
www.youtube.com/watch?v=Wazq...
www.youtube.com/watch?v=Wazq...
@charity.wtf talks a lot of sense, as usual:
> [10x Engineers exist] So what? It doesn’t matter. […] What matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.
charity.wtf/2025/06/19/i...
> [10x Engineers exist] So what? It doesn’t matter. […] What matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.
charity.wtf/2025/06/19/i...
In Praise of “Normal” Engineers
This article was originally commissioned by Luca Rossi (paywalled) for refactoring.fm, on February 11th, 2025. Luca edited a version of it that emphasized the importance of building “10x engi…
charity.wtf
July 9, 2025 at 6:40 AM
@charity.wtf talks a lot of sense, as usual:
> [10x Engineers exist] So what? It doesn’t matter. […] What matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.
charity.wtf/2025/06/19/i...
> [10x Engineers exist] So what? It doesn’t matter. […] What matters is how fast the team can collectively write, test, review, ship, maintain, refactor, extend, architect, and revise the software that they own.
charity.wtf/2025/06/19/i...
I wrote a thing about all the ways you can summon a function in Javascript. It even includes a flow-chart to help check if you're picking a suitable incantation.
jrsinclair.com/articles/202...
jrsinclair.com/articles/202...
What’s the difference between named functions and arrow functions in JavaScript?
Arrow functions (also known as ‘rocket’ functions) are concise and convenient. However, they have subtle differences compared to function declarations and function expressions. So how do you know whic...
jrsinclair.com
June 30, 2025 at 8:44 AM
I wrote a thing about all the ways you can summon a function in Javascript. It even includes a flow-chart to help check if you're picking a suitable incantation.
jrsinclair.com/articles/202...
jrsinclair.com/articles/202...
I have a theory. People struggle with TDD because it feels like hard work. This is because many of us code to think. We're assigned a task, and we start hacking away in the IDE. The solution languidly emerges as we learn more by writing code.
But TDD won’t let you do that.
But TDD won’t let you do that.
April 2, 2025 at 9:37 AM
I have a theory. People struggle with TDD because it feels like hard work. This is because many of us code to think. We're assigned a task, and we start hacking away in the IDE. The solution languidly emerges as we learn more by writing code.
But TDD won’t let you do that.
But TDD won’t let you do that.
A couple of array utilities you won't find in Array.prototype 🧵
April 1, 2025 at 3:24 AM
A couple of array utilities you won't find in Array.prototype 🧵
In some ways, this is so obvious it shouldn't need stating. But it does. And the tension is real. We want our code to be elegant, simple, concise. Yet, we rarely trade that off against the complexity that elegance creates in the interfaces (user interfaces and APIs) we develop.
March 30, 2025 at 9:34 PM
In some ways, this is so obvious it shouldn't need stating. But it does. And the tension is real. We want our code to be elegant, simple, concise. Yet, we rarely trade that off against the complexity that elegance creates in the interfaces (user interfaces and APIs) we develop.
From the archives: jrsinclair.com/articles/201...
Functional programmers are obsessed with purity. “Pure functions let you reason about your code”. “They give you referential transparency!” And they have a point. Purity is good. But what do you do with the impure bits of your code?
Functional programmers are obsessed with purity. “Pure functions let you reason about your code”. “They give you referential transparency!” And they have a point. Purity is good. But what do you do with the impure bits of your code?
How to deal with dirty side effects in your pure functional JavaScript
If you start learning about functional programming, it won’t be long before you come across the idea of pure functions. And as you go on, you will discover functional programmers appear to be obsessed...
jrsinclair.com
March 27, 2025 at 9:22 PM
From the archives: jrsinclair.com/articles/201...
Functional programmers are obsessed with purity. “Pure functions let you reason about your code”. “They give you referential transparency!” And they have a point. Purity is good. But what do you do with the impure bits of your code?
Functional programmers are obsessed with purity. “Pure functions let you reason about your code”. “They give you referential transparency!” And they have a point. Purity is good. But what do you do with the impure bits of your code?
Four ways to remove duplicates from an array in JavaScript. 🧵
P.S. Use the last one.
P.S. Use the last one.
March 26, 2025 at 10:39 PM
Four ways to remove duplicates from an array in JavaScript. 🧵
P.S. Use the last one.
P.S. Use the last one.
Did you know that you can use an array tuple in place of a Maybe structure? It elegantly handles empty values using familiar `.map()`, `.flatMap()`, and `.reduce()` methods. I think it's rather neat. Credit goes to @[email protected] for introducing me to the idea.
![Screenshot of a code snippet showing the use of an array tuple as a Maybe construct. Code reads as follows:
// Suppose we want to retreive the weather conditions
// for a given location. Perhaps we've retreived some
// data from a weather API and we need to process it.
const sensors = {
['Dartmoor']: { value: 10, unit: 'C' },
['Baker Street']: { value: 18, unit: 'C' },
['Scotland Yard']: { value: 68, unit: 'F' },
}
const conditions = {
['Dartmoor']: 'Foggy',
['Baker Street']: 'Sunny',
['Scotland Yard']: 'Rainy',
}
const toCelsius = (fahrenheit) => (fahrenheit - 32) * (5 / 9);
// Here we define a function that wraps our value in an
// array if it's not nullish. We can then use .map(),
// .flatMap(), .reduce() etc. to safely handle the
// nullish case.
const maybe = (value) => value == null ? [] : [value];
const getWeather = (location) => maybe(sensors[location])
.map(({unit, value}) => unit === 'F' ? toCelsius(value) : value)
.flatMap(
(temperature) => maybe(conditions[location])
.map((condition) => ({temperature, condition}))
)
.map(({temperature, condition}) => `${location}: ${temperature}°C, ${condition}`)
.reduce((_, x) => x, 'Weather conditions not available');
console.log(getWeather('Dartmoor')); // 🪵 'Dartmoor: 10°C, Foggy'
console.log(getWeather('Scotland Yard')); // 🪵 'Scotland Yard: 20°C, Rainy'
console.log(getWeather('Diogenes Club')); // 🪵 'Weather conditions not available'](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:lndfplsnmjbsidk3blenqgkb/bafkreidkwlaoi5rzohmvstbzf55ngxdd7ar7nebajplb27smkifooqyxhq@jpeg)
March 25, 2025 at 9:48 PM
Did you know that you can use an array tuple in place of a Maybe structure? It elegantly handles empty values using familiar `.map()`, `.flatMap()`, and `.reduce()` methods. I think it's rather neat. Credit goes to @[email protected] for introducing me to the idea.
I love this quote from John Ousterhout:
> I have found over and over that specialization leads to complexity; I now think that over-specialization may be the single greatest cause of complexity in software.
On the surface, it appears to contradict YAGNI, but not necessarily.
> I have found over and over that specialization leads to complexity; I now think that over-specialization may be the single greatest cause of complexity in software.
On the surface, it appears to contradict YAGNI, but not necessarily.
March 24, 2025 at 10:07 PM
I love this quote from John Ousterhout:
> I have found over and over that specialization leads to complexity; I now think that over-specialization may be the single greatest cause of complexity in software.
On the surface, it appears to contradict YAGNI, but not necessarily.
> I have found over and over that specialization leads to complexity; I now think that over-specialization may be the single greatest cause of complexity in software.
On the surface, it appears to contradict YAGNI, but not necessarily.
It's old news now, but swapping variables with destructuring still blows my mind every time I see it.
![Screenshot of some JavaScript code showing two variables being swapped using array destructuring. The code reads as follows:
let a = 'left';
let b = 'right';
console.log([a, b]);
// 🪵 ["left", "right"]
// Swap two variables with array destructuring.
[b, a] = [a, b]
console.log([a, b]);
// 🪵 ["right", "left"]](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:lndfplsnmjbsidk3blenqgkb/bafkreiewv4l6r2q6x53nf4y4kexsvsr7tuc7l32rcczkvsos5xvc7mmloy@jpeg)
March 23, 2025 at 9:21 PM
It's old news now, but swapping variables with destructuring still blows my mind every time I see it.
I still see lots of people setting default values in JS using the || operator. This is fine if the values you're dealing with are always objects. But if you deal with numbers, booleans or strings, this can be problematic. In most cases, the ?? operator is a better choice.
March 20, 2025 at 10:26 PM
I still see lots of people setting default values in JS using the || operator. This is fine if the values you're dealing with are always objects. But if you deal with numbers, booleans or strings, this can be problematic. In most cases, the ?? operator is a better choice.
Guilty.
“Rules for Writing Software Tutorials”
by Michael Lynch @mtlynch.io
refactoringenglish.com/chapters/rul...
“Rules for Writing Software Tutorials”
by Michael Lynch @mtlynch.io
refactoringenglish.com/chapters/rul...
Rules for Writing Software Tutorials
It's easier than you think to write an exceptional software tutorial. You can stand out in a sea of mediocre guides by following a few simple rules.
refactoringenglish.com
January 3, 2025 at 10:18 PM
Guilty.
“Rules for Writing Software Tutorials”
by Michael Lynch @mtlynch.io
refactoringenglish.com/chapters/rul...
“Rules for Writing Software Tutorials”
by Michael Lynch @mtlynch.io
refactoringenglish.com/chapters/rul...