Gpx

Interested in how to build maintainable software. My work is mysterious and important.

[Gpx @Gpx]

Companies that in 2024 have in their email signatures, "Please don't print this email. Think of the environment." Yeah, I wasn't planning to.

[Gpx @Gpx]

The conversation around AI in software engineering focuses a lot on lines of code generated. But sustainable speed isn't just about typing faster—it's about flow state, managing cognitive load, and keeping the whole system moving.

I wrote a new post for the Perk Builders blog exploring the impact of AI coding through the lens of queueing theory. It breaks down the math of why things slow down and how we can structure our work to actually absorb these new efficiencies.

If you appreciate a technical deep dive that starts with an equation, passes through two graphs, and ends with highly actionable advice for your team, give it a read.

https://t.co/EctEF6bcGc

[Gpx @Gpx]

"I feel like NoSQL is better than Postgres for this architecture."

As an interviewer, this exact sentence is one of my biggest red flags during a System Design round.

As engineers, we are not paid to make architectural decisions based on "feelings," hearsay, or something we read on HackerNews once. We are paid to analyze, verify, and commit based on data.

I frequently interview candidates who choose a technology (like NoSQL, or WebSockets, or Microservices) simply because they "heard it scales well." They have no actual experience with it, and no data to back up why it's the right choice for the specific problem we are solving.
When you use phrases like "I feel" or "I heard," you signal to the interviewer that you are willing to make critical engineering decisions based purely on rumors.

It is 100% okay not to know the answer. In fact, admitting a knowledge gap is a sign of seniority. Instead of guessing, trade "I feel" for "Here is how I would find out."

Try this:
"I'm actually not very familiar with Server-Sent Events. I've mostly used WebSockets. In a real scenario, I wouldn't guess—I would validate this by doing a quick technical spike or researching the protocol's memory trade-offs. How would you suggest we handle this for our exercise?"

This approach turns a gap in your knowledge into a live demonstration of your mature, data-driven problem-solving process.

[Gpx @Gpx]

Most candidates treat the "Do you have any questions for me?" part of an interview as a simple info-gathering formality.

As an interviewer, I use it as a massive signaling tool.

When the interview flips and you start asking questions, you aren't just learning about the company—you are actively telling the interviewer what you value, where your focus lies, and how senior you really are.

Every question sends a signal:
"What does your tech stack look like?"
Signal: You are highly focused on the technical implementation and the tools. (Great for junior/mid-level, but shouldn't be your only focus if you are applying for a Staff role).

"How is the decision-making organized between Product and Engineering?"
Signal: You care about collaboration, organizational structure, and building the right thing, not just writing code. This is a massive green flag for senior+ roles.

"How does the team handle on-call and vacation days?"
Signal: You care about work-life balance and boundaries. (This is a completely valid question, but remember that it is a signal you are sending).

Pro-tip: It is completely fine to ask the exact same question to different interviewers at every stage of the loop. In fact, it is highly recommended. It is incredibly interesting to see how an Engineering Manager, a Product Manager, and a Staff Engineer answer the exact same question. It tells you everything you need to know about the company's internal alignment.

Don't waste the last 10 minutes of your interview. Be strategic. Ask questions that align with the professional narrative you want to present to the hiring team.

[Gpx @Gpx]

It really is difficult to balance the need to push a team to innovate and adopt new technologies and practices with the need to avoid micromanaging.

I see this a lot lately with AI adoption. Some companies are looking at how much AI is used, how often it is used, and whether people are using it enough. But this is not new. It happened in the past with other innovation cycles too. TDD and automated testing are examples that come to mind.

The trick is to convince before you mandate.

If the change really is valuable, there should be ways to show it. Show that it improves quality, reduces risk, shortens feedback loops, or helps teams move faster without creating more chaos. If the evidence is there, people are more likely to pick it up and want to learn.
A mandate may still be needed at some point, but it should not be the first tool. Otherwise, what could have been a meaningful improvement easily becomes just another process imposed from above.

[Gpx @Gpx]

This is something I’ve been thinking about a lot lately: the psychological impact of innovation on different people.

According to Wardley and Cringely, there are three distinct behavioral archetypes within a company: Pioneers, Settlers, and Town Planners.

Pioneers thrive in chaos. They like operating on the bleeding edge, where things are unclear, unstable, and full of unknowns. They are usually the first to experiment with a new technology, not because the business case is already obvious, but because they are comfortable exploring the unknown.

Settlers take what Pioneers discover and turn it into something useful. They look for patterns, remove some of the chaos, and make the technology reliable enough to generate business value. They are not necessarily late adopters, but they usually need more than hype. They need to see that something can actually work.

Town Planners scale what Settlers built. They care about standards, governance, repeatability, and operational stability. Their job is not to chase novelty, but to make sure the organization can depend on something at scale without everything falling apart.

This made me think about AI adoption. But this post is not really about AI. AI is just the current example.

The real question is: how does each archetype deal with the introduction of a major technological shift?

My suspicion is that most of the people who feel burned out by AI are not Pioneers. Pioneers are probably enjoying the chaos, the experimentation, and the lack of clear rules.

Settlers, I think, are slowly getting more interested as the technology matures. Once there are more proven patterns, better tools, and clearer ways to turn AI into actual business value, it becomes much more interesting to them.

Town Planners might be the most cautious, and maybe for good reasons. Their job is to scale, standardize, and reduce operational risk. A technology that changes every few weeks is not exactly comfortable territory.

Since this will not be the last technological shift we’ll see in our careers, I’d be curious to hear how other people are dealing with it.

Which archetype do you relate to the most?
And how are you experiencing AI adoption right now?

Feel free to DM me if you prefer to keep it confidential.

[Gpx @Gpx]

A small piece of advice for engineers interviewing right now. Prepare an answer to this question:

How do you use AI agents or AI tools in your work?

More and more companies are asking this.

As usual, there is no single correct answer. What matters most is that you can justify your answer.

For example:

“I use ChatGPT to reason through prototypes before jumping into code.

I apply spec-driven development, so I first prepare a plan with the help of AI. Then I convert that plan into a task list and execute it with a swarm of agents.

Each task is limited in scope and validated by tests I have written beforehand.”

This kind of answer tells me much more than “yes, I use AI.” It shows that you think about the problem, understand the trade-offs, and know where AI fits in your workflow.

In an interview, that matters more than saying you know how to use a particular tool.

[Gpx @Gpx]

"I need to find a way to burn some AI tokens."

I heard this directly from someone working at a tech company.

Their leadership team had created a mandate to increase AI usage. The logic is simple (and wrong): if people use more AI, the company is more productive.

So people started finding ways to burn tokens.
Some generate memes, some build personal projects, some help their children with homework... nobody does anything related to the company's goal. After all, the mandate is to use AI, not to use it properly.

This is what worries me about the current AI adoption wave: there's a growing disconnect between leadership and the people they are supposed to lead. In many companies—not all of them, of course—leaders seem to have already decided that AI must deliver a certain level of productivity improvement. Not because they have strong data. Not because they understand where the improvement will come from. But because the market expects it, the hype promises it, and everyone else is doing it.

Then, when the expected gain does not materialize, the conclusion is not: "Maybe we misunderstood the problem." The conclusion becomes: "People are not using AI enough."

So they create mandates. They measure how many tokens are consumed. The metric becomes the goal.

This is dangerous because a company does not hire engineers, designers, product people, and the like just to execute leadership's assumptions. You hire them because they understand aspects of reality that leadership cannot see on a dashboard. You hire them because they can tell when something does not make sense. You hire them because, sometimes, you need them to tell you that you are wrong.

But if people stop pushing back for fear of losing their jobs or because they have learned that nobody is listening, the company has a much bigger problem than AI adoption. AI will not fix that; it will make it worse.

Treating AI adoption as a proxy for progress is lazy.
Usage is not impact.
Token consumption is not productivity.
Mandates are not strategy.

And if your employees are inventing nonsense ways to use AI just to satisfy a leadership target, the problem is not that they are resisting the future.

The problem is that your organization has stopped learning from the people closest to the work.

[Gpx @Gpx]

It might be because English is not my native language, but what does "AI native" mean? Isn't the fact that we're adopting it at odds with the very definition of native?

[Gpx @Gpx]

I think this is a good take, but it does not fully match my experience.
For me, the dominant feeling around AI in software development has not been grief. It has been fear.

From the moment ChatGPT was released, the discourse centered on whether AI was going to replace developers. Companies were built around that promise. We got endless demos showing LLMs replacing engineers, benchmarks claiming models performed better than developers, and a constant stream of messaging pushing the idea that our work was about to be automated away.

And we still do.

What helped me was trying to look at the technology as objectively as possible. Once I did that, the picture became much less extreme. LLMs are not as amazing as they are often sold, and they are not as bad as the detractors claim, either.

They do have a place in software development, and they have changed the way many of us work. But not as radically as some people claim.

Could they evolve to replace us one day? Maybe. But if the current trend continues, I think that is unlikely.

That is why I suspect that, in many cases, denial and anger are not really a consequence of grief.They look more like a fight or flight reaction to fear.

https://t.co/TIsan31r1H

[Web Engineering Summit @WESummit2026]

⚙️What does it take to build web systems for the AI era? Join 50+ deep engineering sessions at Web Engineering Summit on June 11 & 15 in Amsterdam & online.

Topics include: AI development, system design, scalability, performance, full-stack architecture, & more.

Don’t miss out!

[Gpx @Gpx]

In many cases, software developers are not seen as professionals in the same way as doctors, plumbers, or lawyers.

A big part of it is our own fault: too often, we are not seen as professionals because we do not act like them.

Often, the way we are perceived and perceive ourselves is as people who write code based on someone else’s idea. We can clearly see this now, with many people trying to replace software developers with LLMs.

If your job is framed as just turning instructions into code, then of course, people will assume a machine can replace you. The problem is that this was never the real job.

The real job is understanding trade-offs.
Understanding risk.
Understanding how systems fail.
Knowing when a request is reasonable and when it is dangerous.
Knowing when speed today creates a bigger problem tomorrow.

That is what professionals do.

And yet, too often, we accept deadlines we do not believe in.
We skip tests because delivery pressure is high.
We keep building on top of systems that are already unstable.
We stay quiet when we should push back.
We act like our responsibility starts and ends with producing code.

It does not.

A professional does not just execute.
A professional uses judgment.
A professional protects the integrity of the work.
A professional is expected to say no when no is the right answer.

If we want this field to be treated as a profession, we need to stop behaving like typists for product ideas and start behaving like people accountable for the quality, safety, and durability of the systems we build.

Because if we keep presenting our work as “just coding”, we should not be surprised when others start asking why they need us at all.

[Gpx @Gpx]

I regularly interview candidates for software engineering positions and conduct many system design interviews, so let me give you some advice based on the most common error I have seen.

If your solution relies on a cron job or on polling a service, it is often wrong. If you find yourself relying on it, stop and think if there is a better way.

If you are polling many times, it is usually because you are not sending an event or you do not understand how to get the data in a more straightforward way.

[Gpx @Gpx]

Call for Speakers for JSHeroes 2026 is open on Sessionize, and I've just submitted a session! https://t.co/iGTRE2hVv6

[Gpx @Gpx]

@adamstern_ @charliedeets @diabrowser Bring back the sidebar!

[Gpx @Gpx]

This. AI is another tool. If you replace expertise with tools, you don't understand what programming is

[Michael Arnaldi @MichaelArnaldi]

"X% amount of code written by AI" has the same importance of "X% amount of code written by keyboard". If you give it any more importance you're confusing the scalpel with the surgeon.

[Gpx @Gpx]

I've been doing a bunch of TypeScript and I found out I don't know how to spell "unknown"

[Gpx @Gpx]

@mattcarrollcode I did not. None of my projects have noticeable performance issues so I don't feel I need it. Memoization is something I very rarely reach for

[Una 🇺🇦 @Una]

Automatic repositioning logic! 🏗️

One really cool built-in feature of native customizable select:

[Gpx @Gpx]

Hey, @krisvelkov, I read your article about using a flat structure for logic. What do you think of this alternative implementation?

https://t.co/Nx2qvCwA8z

[Gpx @Gpx]

@elmlang @reasonml https://t.co/VvF19rLC63

[Gpx @Gpx]

Around ten years ago, it seemed JavaScript was going the functional programming route with libraries like Ramda becoming popular.

It unfortunately ended up in a few unmaintainable codebases full of tiny undecipherable functions and some good projects like @elmlang and @reasonml that remained niche.

JavaScript wasn't a good fit back then because it didn't have types. But now we have @typescript.

I think projects like @EffectTS_ and the excellent ts-pattern (by @GabrielVergnaud) have the chance to change how we write JS applications.

[Gpx @Gpx]

@elmlang @reasonml https://t.co/V2CrwiFDOK