Georg Unterholzner
@georg.dev
👨🏻💻 Software engineer @Dynatrace
🌐 Web dev and trained data scientist
🍜 Foodie | gym-goer | tech & gaming nerd
🇦🇹 Based in Vienna
https://georg.dev
🌐 Web dev and trained data scientist
🍜 Foodie | gym-goer | tech & gaming nerd
🇦🇹 Based in Vienna
https://georg.dev
Think you're safe because you're in a metro station? Think again! Little Berta up there is watching you. Luckily, she’s nice enough to leave hints on the floor to spare those who paid attention in Stats 101.
November 17, 2025 at 6:58 PM
Think you're safe because you're in a metro station? Think again! Little Berta up there is watching you. Luckily, she’s nice enough to leave hints on the floor to spare those who paid attention in Stats 101.
You'd be mistaken if you thought pigeon droppings on the floor were just a random annoyance. Quite the opposite! They're a real-time heatmap showing you the probability of being hit by pigeon poop at any given spot.
And you thought all that statistics knowledge was useless!
And you thought all that statistics knowledge was useless!
November 17, 2025 at 6:58 PM
You'd be mistaken if you thought pigeon droppings on the floor were just a random annoyance. Quite the opposite! They're a real-time heatmap showing you the probability of being hit by pigeon poop at any given spot.
And you thought all that statistics knowledge was useless!
And you thought all that statistics knowledge was useless!
Sometimes programming just feels too much like Hänsel and Gretel.
August 18, 2025 at 3:20 PM
Sometimes programming just feels too much like Hänsel and Gretel.
Basic question but I can't figure it out. How are these two design patterns called?
In the first, the component structure is fixed, and behavior is controlled *only* through props serving as config.
In the second, an extension point via the children prop allows for more flexibility.
In the first, the component structure is fixed, and behavior is controlled *only* through props serving as config.
In the second, an extension point via the children prop allows for more flexibility.
August 13, 2025 at 1:58 PM
Basic question but I can't figure it out. How are these two design patterns called?
In the first, the component structure is fixed, and behavior is controlled *only* through props serving as config.
In the second, an extension point via the children prop allows for more flexibility.
In the first, the component structure is fixed, and behavior is controlled *only* through props serving as config.
In the second, an extension point via the children prop allows for more flexibility.
Don't be like me.
Don't sleep on @playwright.dev's test steps.
It took me 4 years to realize how much cleaner, readable, and debuggable my tests could be.
Named steps = better readability, clearer reporting, faster debugging.
Check out the before/after!
Don't sleep on @playwright.dev's test steps.
It took me 4 years to realize how much cleaner, readable, and debuggable my tests could be.
Named steps = better readability, clearer reporting, faster debugging.
Check out the before/after!
August 1, 2025 at 10:07 AM
Don't be like me.
Don't sleep on @playwright.dev's test steps.
It took me 4 years to realize how much cleaner, readable, and debuggable my tests could be.
Named steps = better readability, clearer reporting, faster debugging.
Check out the before/after!
Don't sleep on @playwright.dev's test steps.
It took me 4 years to realize how much cleaner, readable, and debuggable my tests could be.
Named steps = better readability, clearer reporting, faster debugging.
Check out the before/after!
Agent mode tip: Add clear instructions for automating checks like "npm run lint" or "npm run test". With these in your file, Copilot Agent can run the commands, fix errors, and iterate until all checks pass without constant back-and-forth.
July 22, 2025 at 12:35 PM
Agent mode tip: Add clear instructions for automating checks like "npm run lint" or "npm run test". With these in your file, Copilot Agent can run the commands, fix errors, and iterate until all checks pass without constant back-and-forth.
Stack Overflow, are you alright?
July 17, 2025 at 9:35 AM
Stack Overflow, are you alright?
Finally!!
Grok 4 in GitHub Copilot.
Grok 4 in GitHub Copilot.
July 14, 2025 at 3:03 PM
Finally!!
Grok 4 in GitHub Copilot.
Grok 4 in GitHub Copilot.
Gen Alpha successfully rotted my brain. grid-template-columns: 1fr 2fr; now reads “one for real, two for realz.”
My grid is aggressively verified. ✅
My grid is aggressively verified. ✅
June 28, 2025 at 5:36 PM
Gen Alpha successfully rotted my brain. grid-template-columns: 1fr 2fr; now reads “one for real, two for realz.”
My grid is aggressively verified. ✅
My grid is aggressively verified. ✅
This year's Stack Overflow Developer Survey in a nutshell
June 12, 2025 at 11:28 AM
This year's Stack Overflow Developer Survey in a nutshell
Researchers even handed models step-by-step algorithms (e.g., for Tower of Hanoi). The result: identical failure points. LRMs couldn’t reliably execute prescribed logic—suggesting their "reasoning" is often pattern-matching, not general intelligence.
June 11, 2025 at 12:50 PM
Researchers even handed models step-by-step algorithms (e.g., for Tower of Hanoi). The result: identical failure points. LRMs couldn’t reliably execute prescribed logic—suggesting their "reasoning" is often pattern-matching, not general intelligence.
Worst of all, LRMs reduce their reasoning effort as problems get harder. Despite having spare token budgets, they underthink when complexity peaks, like a student giving up on an exam’s toughest question—even with extra time left 😅
June 11, 2025 at 12:50 PM
Worst of all, LRMs reduce their reasoning effort as problems get harder. Despite having spare token budgets, they underthink when complexity peaks, like a student giving up on an exam’s toughest question—even with extra time left 😅
Large Language Models (LLMs) with "reasoning" capabilities are super hyped, but new research from Apple shows their "thinking" is often an illusion. Beyond a certain complexity, they fail completely. Key points in the 🧵.
June 11, 2025 at 12:50 PM
Large Language Models (LLMs) with "reasoning" capabilities are super hyped, but new research from Apple shows their "thinking" is often an illusion. Beyond a certain complexity, they fail completely. Key points in the 🧵.
Austria is outrageously beautiful.
May 27, 2025 at 4:50 PM
Austria is outrageously beautiful.
my experience with firebase studio so far 😐
April 18, 2025 at 9:59 AM
my experience with firebase studio so far 😐
My learning for that day: the final solution was to use the render props pattern.
Kudos to @bhuynh.dev and @taranetz.com for pointing that out.
We can even take a step further by leveraging React's `isValidElement` function to support both render props and a standard child component.
Kudos to @bhuynh.dev and @taranetz.com for pointing that out.
We can even take a step further by leveraging React's `isValidElement` function to support both render props and a standard child component.
March 19, 2025 at 2:40 PM
My learning for that day: the final solution was to use the render props pattern.
Kudos to @bhuynh.dev and @taranetz.com for pointing that out.
We can even take a step further by leveraging React's `isValidElement` function to support both render props and a standard child component.
Kudos to @bhuynh.dev and @taranetz.com for pointing that out.
We can even take a step further by leveraging React's `isValidElement` function to support both render props and a standard child component.
Life hack: you don't have to worry that someone could replace you with AI, if you replace yourself with AI.
March 8, 2025 at 4:20 PM
Life hack: you don't have to worry that someone could replace you with AI, if you replace yourself with AI.
Alternatively, I could think of restricting the child components' type (it’s a TypeScript library anyway).
Then, I could inject the property into the child, and it would just automagically work.
I’ve done this countless times in Angular libs. I'm not sure if this is a thing in React, though. 🤷
Then, I could inject the property into the child, and it would just automagically work.
I’ve done this countless times in Angular libs. I'm not sure if this is a thing in React, though. 🤷
![Code snippet with the following code:
// my lib:
type InitData = { prop1: string, prop2: number };
const MyWrapper = ({ children }: ReactElement<InitData>) => {
const [initData] = fetchInitData();
// inject the prop into the children
const slots = React.cloneElement(children, { initData });
return (
<>
{/* ... */}
{slots}
</>
);
};
// user repo:
const UserDefinedChildComponent = (props: InitData) => {
const { prop1, prop2 } = props; // use injected props
return (
<ul>
<li>{prop1}</li>
<li>{prop2}</li>
</ul>
);
};
const UserDefinedParentComponent = () => (
<MyWrapper>
<UserDefinedChildComponent />
</MyWrapper>
);](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:rxz3y4wyodom6g6n3zsp7r4g/bafkreiczznugxaeg5s3meoai7ld25ojwngxhowteeyi5cqd44ypecjrabu@jpeg)
March 5, 2025 at 4:28 PM
Alternatively, I could think of restricting the child components' type (it’s a TypeScript library anyway).
Then, I could inject the property into the child, and it would just automagically work.
I’ve done this countless times in Angular libs. I'm not sure if this is a thing in React, though. 🤷
Then, I could inject the property into the child, and it would just automagically work.
I’ve done this countless times in Angular libs. I'm not sure if this is a thing in React, though. 🤷
Using a React context, maybe?
It feels very idiomatic to React to do it that way, and it leads to a very smooth API. However, I don’t like that now my library suddenly also has to export a context instead of just the component.
It feels very idiomatic to React to do it that way, and it leads to a very smooth API. However, I don’t like that now my library suddenly also has to export a context instead of just the component.
![Code snippet with the following code:
// my lib:
const MyWrapper = ({ children }) => {
const [initData] = fetchInitData();
return (
<MyWrapperContext.Provider value={initData}>
{children}
</MyWrapperContext.Provider>
);
};
// user repo:
const UserDefinedChildComponent = () => {
const initData = useContext(MyWrapperContext); // data from context
return <>{/* ... */}</>;
};
const UserDefinedParentComponent = () => (
<MyWrapper>
<UserDefinedChildComponent />
</MyWrapper>
);](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:rxz3y4wyodom6g6n3zsp7r4g/bafkreidlxmgsw5hfvw6u5pevdaqvtmtsqgumkgfgazqumtr77sjv47l75y@jpeg)
March 5, 2025 at 4:28 PM
Using a React context, maybe?
It feels very idiomatic to React to do it that way, and it leads to a very smooth API. However, I don’t like that now my library suddenly also has to export a context instead of just the component.
It feels very idiomatic to React to do it that way, and it leads to a very smooth API. However, I don’t like that now my library suddenly also has to export a context instead of just the component.
The first thing that comes to mind is adding a callback to the wrapper, allowing the user to retrieve the state.
However, this feels a bit boilerplate-y. Every user would now have to manually wire the two components together. I’m not a fan of that.
However, this feels a bit boilerplate-y. Every user would now have to manually wire the two components together. I’m not a fan of that.
![Code snippet with the following code:
const UserDefinedParentComponent = () => {
const [initData, setInitData] = useState();
return (
<MyWrapper onInit={setInitData}> {/* use a callback */}
<UserDefinedChildComponent initData={initData} />
</MyWrapper>
);
};](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:rxz3y4wyodom6g6n3zsp7r4g/bafkreicybcv3g4ifqjyezcodhwq5jxdvjdqwferi66feylncf7hhnygzle@jpeg)
March 5, 2025 at 4:28 PM
The first thing that comes to mind is adding a callback to the wrapper, allowing the user to retrieve the state.
However, this feels a bit boilerplate-y. Every user would now have to manually wire the two components together. I’m not a fan of that.
However, this feels a bit boilerplate-y. Every user would now have to manually wire the two components together. I’m not a fan of that.
React: passing state from a wrapper component to a child. How?
I'm building a library that exposes a single wrapper component. Users of this library add the wrapper to their TSX and nest their child component inside it.
The wrapper fetches some data that's relevant to the child component.
I'm building a library that exposes a single wrapper component. Users of this library add the wrapper to their TSX and nest their child component inside it.
The wrapper fetches some data that's relevant to the child component.
March 5, 2025 at 4:28 PM
React: passing state from a wrapper component to a child. How?
I'm building a library that exposes a single wrapper component. Users of this library add the wrapper to their TSX and nest their child component inside it.
The wrapper fetches some data that's relevant to the child component.
I'm building a library that exposes a single wrapper component. Users of this library add the wrapper to their TSX and nest their child component inside it.
The wrapper fetches some data that's relevant to the child component.
Good question! For me, it depends on the scope and complexity of the project:
- If it's only a few DB calls and low complexity, I'd go with just throwing the error.
- If it's a large and complex project, I'd use TypeScript with Effect (see screenshot).
- If it's only a few DB calls and low complexity, I'd go with just throwing the error.
- If it's a large and complex project, I'd use TypeScript with Effect (see screenshot).
![Code snippet with the following code:
```
import { Effect } from "effect";
export function deletePostWithEffect(id: Post["id"]): Effect<never, Error | unknown, void> {
return Effect.gen(function* (_) {
const { user } = yield* _(Effect.promise(() => getCurrentSession()));
if (!user) {
yield* _(Effect.fail(new Error("You are not authorized to delete this post")));
}
yield* _(
Effect.promise(() =>
db.delete(postTable).where(eq(postTable.id, id))
)
);
});
}
```](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:rxz3y4wyodom6g6n3zsp7r4g/bafkreih2l5h7pafctohjvhccid22eukagvl57ius2m5og7vkofvgzhicnu@jpeg)
March 3, 2025 at 2:28 PM
Good question! For me, it depends on the scope and complexity of the project:
- If it's only a few DB calls and low complexity, I'd go with just throwing the error.
- If it's a large and complex project, I'd use TypeScript with Effect (see screenshot).
- If it's only a few DB calls and low complexity, I'd go with just throwing the error.
- If it's a large and complex project, I'd use TypeScript with Effect (see screenshot).
Similar story with Chart.js: from not being included in last year's questionnaire to becoming the top choice for data visualization libraries in 2024.
February 13, 2025 at 3:31 PM
Similar story with Chart.js: from not being included in last year's questionnaire to becoming the top choice for data visualization libraries in 2024.