MORPHOICES

After the macOS Tahoe upgrade, I keep missing window resize corners. ~

I was slow to realize why. Although the corner appears substantial, the real area being resized is significantly smaller. Furthermore, because of the larger corner radius, this target lie mostly off-screen.

I have never experienced this before. After using computers for decades, resizing windows became like muscle memory for me. I now miss it at least a few times a day.

What I find interesting is not this particular bug but the pattern.

Here’s a rough framework I’m using to think about it.

The visual and interaction affordance can diverge.

Muscle memory is more delicate than we think.

A little tweak in a hit-target can create daily frustration.

Changes made only for aesthetic purposes have behavioral costs.

There are certain thoughts that might have helped here.

Ensure the interactive region aligns with the visible shape, even if it intrudes.

Slightly expand the resize hit zones near corners since people overshoot anyway.

Implement subtle cursor feedback earlier, before entering the exact pixel zone.

I'm interested to learn how others feel about this tradeoff.

Have you ever encountered regressions where a visual polish fix disrupted a learned behavior?

Is muscle memory a hard constraint that must be followed, or is it something the users should relearn?

What evidence would you look for in these changes to decide they are not working?

When reading succinct technical documentation, I see how so many times the documentation attempts to cover everything possible. ~

Most developers want guidance instead of exhaustive details. Developers want to know where they should focus their time and where they can afford to skim over the documentation. And they want to know where they should expect to encounter problems and difficulties.

A simple framework to use when producing succinct technical documentation is to divide the documentation into three sections.

Maps: Identify what type of problems this documentation can assist you with

Defaults: Understand what the majority of people will experience and what to do about it.

Exceptions: Identify when to deviate from the default recommendations.

Succinct documentation does an excellent job of providing clarity by eliminating edge cases. The more clearly the user understands the documentation the more useful the documentation will be during the time where the user is experiencing the most confusion.

The danger is the temptation to simplify the information contained within the documentation to such an extent that the user is left with a large amount of missing information and no method for seeking assistance with incomplete information.

What situations have you encountered where the information contained within short technical documentation has been more helpful than official technical documentation? ~

The HTML Specification (spec) states it is possible to omit closing tags for certain elements when writing HTML documents. ~

In fact, most web browsers now automatically insert these closing tags for the user.

This feature has been around for many years now.

However, I have found that many organizations still require that the closing tags be included explicitly.

I am curious how other organizations determine when to use the "the spec allows it" as a reason to not include the closing tags.

What point do developers cross from merely allowing this to being considered a technical debt?

Have you ever utilized the feature of the specification that caused you a problem later?

As I was looking at various film formats, I was reminded of how messy standards are. ~

There are dozens of formats with slightly different sizes and long tails that never fully disappear.

There is almost no rhyme or reason to it and a lot of it feels like it's just been passed down.

After a while, a format can no longer be considered optional. Once again, I see the same pattern with software and I was curious how others view the same phenomenon.

Which standards survived due to inertia? Which lost better alternatives? Where was the emphasis on compatibility over design?

Value categories and move semantics are great examples of programming concepts that can cause confusion, and it's a great example of how not having a bad documentation can still lead to confusion through bad mental models. ~

Intuitively you think you understand what is going on, and you think you can answer what is going on, and you can even use it due to understanding it on an operational level, but you can't explain it due to your confusion.

As a result, you most likely are going to create a lot of small bugs in your software and a lot of code that you don't really understand. So, I'm curious to know what others think.

What concept did you learn later than you thought you would? What knowledge did you struggle with the most? What finally helped you understand it?

Viewing sites like Dwitter always refreshes my confidence in creativity. ~

You would expect severe restrictions to yield sameness. On the contrary, you receive untamed variety. Optical illusions. Modern sayings. People twisting the medium in unplanned directions.

The trend I’ve noticed.

Limits prevent uninvited focus.

Constraints that we all share can become a shared language.

A tiny scope reduces experimentation expenditure.

When the area of surface is small, people penetrate deep instead of spread wide. They experiment with odd concepts since failing is inexpensive and quick.

Unlike most platforms that add features to unlock creative potential, which actually ends up overwhelming it.

A rule that I keep coming back to: if something feels playful, constraints are probably doing their job.

Inquisitive.

In what situations did restrictions lead to better outcomes?

When do limitations start to seem fictitious?

What contemporary instruments ought to be more limited?

I have noticed a trend with newer JS tooling beyond performance. Indeed, builds are quicker. The cold starts decrease. That’s great. ~

However, the feedback duration is the actual behavior modifier.

My perception map.

Speed test, compilation time benchmarks.

Loop tightness refers to how fast you notice a mistake.

Cognitive load refers to the amount of context you maintain in memory while waiting.

Most developers don't make use of max throughput. They strive to avoid distractions. Tools that are written in faster languages matter mainly because they shrink the gap between action and signal.

Some "quick" weapons stick, that is why. Problems of today often relate to mystery, not slowness.

The rule I abide by now is that if a tool feels calming while debugging, it wins.

Inquisitive.

What tools have made an impact on your daily workflow?

When has hype about performance not translated into adoption?

What is the next bottleneck after speed?

AOSP has felt different lately, what’s going on? Not much. ~

More like a change of tone.

Quarterly releases given more emphasis. More precise stability language. Rather than feeling like an afterthought, feature flags are now receiving first-class treatment.

My view.

The isolation of platform work is earlier.

Landing flags are occurring more frequently than ever.

By “Stable,” it appears the Intuit team is suggesting “boring” which is deliberate.

I have been using a simple lens.

The surface of the platform is slow and predictable.

A gated and reversible design.

The OEM risk will be pushed later.

I wonder how other people see it.

Is Android giving off more conservative vibes?

Are flags cutting down on breakage, or just relocating it?

Has your testing strategy changed if you’ve shipped against AOSP?

In a practitioner’s take, not in a press narrative.

I have kept track of a few instances where AI has been applied to real and genuine problems. ~

Not trivial problems. Issues with possible solutions, errors, and unresolved history.

AI did not \\"solve\\" any issues on its own, but what stood out to me was the speed at which concepts could be rewritten, restructured and tested for stress.

A mental model that has been useful to me is that AI is not particularly good at providing the first answer, however, it is very good at providing the second, third, and tenth versions of the answer, especially when the first answer has already been identified as weak by a human.

In these instances, the progress seemed to stem from the AI being able to: Quickly reword and restate a given argument. Convert implicit assumptions into explicit ones. Identify small gaps in logic before they became large.

What I have been grappling with is how to differentiate when AI is just clarifying versus when it is silently hallucinating structure. Is the output of AI being treated as a draft, a reviewer, a rubber duck, or some combination? When is the output so fast that the rigor of thought is compromised? I am interested in how others are using AI for hard thinking and not just for writing cleanup.

I recently tried out a tool that seemed quite sophisticated on first glance, but once you peel the layers back, the core logic is surprisingly small.

Not trivial. Just...smaller than expected. It really made me think how often we mistook: surface level complexity product polish system depth Lately, I've been pondering: if I had to re-explain this from scratch, what is its irreducible core?

I'm curious to hear others: What system surprised you by being simpler than you expected? Where was the real complexity? What do people tend to overestimate?

I remember reading a pattern that describes the loss of contributors by platforms. Early users play a crucial role in establishing the primary level of quality and norms. ~

Once a platform scales, new levels of moderation, metrics, and various types of abstractions are added. Thereafter, the platform prioritizes safety and growth at the cost of craft.

One simple framework I use is the separation of: Value creation: the signal producer Value protection: the one who manages the risk and optics Value capture: the one whose interests the decisions serve These three domains represent the asymmetry that occurs in aol the platform contributors. The complex part of the problem is that from the outside, the platforms seems successful, and is growing.

Therefore the complaints that are almost always prevalent are considered “edge cases.” Unfortunately, those who were part of the ecosystem, and were most passionate contributors are the ones that are leaving.

Final thought for the builders of any community: pay attention to those who are not posting, instead of the new users who are signing up. In your experience, are there examples of the phenomenon described above? Can the platforms be salvaged after the loss of trust? What are the dead ends that are a given in these situations?

WebAssembly was supposed to be the first “universal runtime” that could literally run anywhere at lightning speed, and while it was certainly an impressive achievement, it was clear to me that the technology friction was mostly on how it was integrated, or more specifically how it was integrated with tools, debugging, interoperation, etc. ~

The web technologies and frameworks that we have today and how we use them to create solutions, still a lot of developers rely on JavaScript. It may be an outdated language with a lot of issues and problems, but it is still the most popular programming language today. Platforms tend to fail because the workflow surrounding them doesn't offer the flexibility to make the most of the platform.

The most valuable lesson to learn is that potential alone doesn't drive widespread use of a technology. The flexible integration offered by JavaScript is the only thing that made widespread use of it possible. What is the most valuable thing that Web Assembly offered you? What is the missing element in Web Assembly that makes it hard to use? What does the new technology offer that makes it harder to use and does it repeat the same patterns as Web Assembly?

I feel uncomfortable the more we celebrate economic 'resilience' Recession avoided. Growth sticks. ~

Jobs remain. I've learned to differentiate survival from renewal.

Surviving is the ability to withstand shocks and not break. Renewing is the ability to rebuild and strengthen so that the next shock is less painful.

Most policies focus on the former. The latter is far more difficult. It is slower and easier to postpone. Protectionism is a classic example. It keeps the numbers stable in the short run but it means there is often less incentive to improve productivity, skills and supply chains. On the surface it all looks fine, but nothing gets better.

A new guide for me is if a policy makes it easier to be static, it is probably not progress. I wonder if others think the same. What signs indicate that renewal is underway? When has buying time worked? What is more important than growth?

Deep bugs, particularly in kernels, can go unnoticed for years, according to analyses I keep seeing. Decades at times. ~

That seems frightening at first. However, the more I consider it, the more it seems... predictable.

The mental model that I find useful:

Users discover surface bugs.

Deep bugs only appear in infrequent combinations.

For some bugs to show up, new context is required.

I've observed a few patterns:

Undefined behavior-related bugs are permanently hidden.

Logic errors are less important than uncommon hardware or timing conditions.

Long before they can be exploited, security flaws frequently exist.

I'm curious what other people think of this:

Do persistent bugs indicate stability or failure?

What typically leads to their discovery?

To what extent do you trust "well-tested" code?

I've found that sometimes it's easier to put off a task. At other times, it simply becomes avoidance. ~

I've been able to distinguish between the two by asking:

Does the lack of information prevent the task from being completed?

Will it be less expensive to complete the task later?

Am I holding off to avoid discomfort or to obtain clarity?

Delays typically pay off if they lower uncertainty. In most cases, it doesn't make anxiety worse.

I've tried concrete things:

Put my reasons for delaying something in writing.

Instead of setting a date, set a "revisit trigger."

Try it for five minutes to see what hurts the most.

I'm curious what other people think of this:

How can procrastination be distinguished from strategic delay?

Do you put off making decisions longer than taking action?

Do you use any heuristics?

I have been looking into BGP incidents for a while, and one of the things that continues to puzzle me is figuring out the difference between legitimate outages and noisy but expected behavior. ~

The mental model I’ve been using is: Intentional change (maintenance, policy update) Accidental leak (misconfig, partial rollout) Structural failure (dependency or upstream issue) I like to ask three questions first: Did the blast radius grow over time, or did it appear instantly? Did paths change symmetrically or only in one direction? Did things revert cleanly or drift back slowly? Some concrete tricks that helped: Look for AS-path prepending changes first. Compare visibility across regions rather than just globally.

Track “who benefits” from the new paths, even if only for a short time. I’m interested in how others approach this: What is your first indicator that things are indeed wrong? Do you prefer automated alerts or manual recognition of a pattern?

Treating documentation like an interface, not a manual As of late, I’ve reviewed documentation less as “instructions” and more like an interface. ~

Users find it hard to use documentation just as they find it hard to use a product with a bad interface.

It changed the way I write, for example: Headings are like boundaries to an API. I prioritize example before explanation. If it lowers cognitive load, repetition is warranted. I made the following changes: Even if it may feel like it has been too short, I hope you will not mind the sections. Even better, try to remove everything except for one idea per page.

Try not to write for the expert, write for the most confused reader. I’ll ask you the following: Do you see docs as some sort of ux too? How do you test docs, without watching someone live?

I have been seeing these stories about bigger AI models that somehow work on small devices like a Raspberry Pi. One example really caught my eye lately. It was not just some quick show off thing. The model could interact and respond right away in real time. ~

That got me thinking again about what practical even means when it comes to AI running on the edge. Like, away from big servers.

I came up with a basic way to look at it. First, capability. That is, what kinds of tasks can it handle decently. Then latency. Does it respond quick enough so it does not feel laggy. There are also constraints to consider. Things like power use, how much memory it needs, and heat buildup.

The use case part seems key too. What happens if you try to take it off the cloud and run it locally. In my experience, a lot of these edge AI demos fall short there. The tech looks impressive, but it is hard to see why you really need it that way.

It seems like most people overlook that unclear need. I am curious about how others see it. Local inference probably beats cloud in spots where you cannot rely on internet, or maybe for privacy reasons. Or when data stays on device for security.

Some workloads feel close right now. They might shift soon as hardware gets better. I think stuff like voice assistants or simple image recognition could tip over.

If someone has actually put a model on limited hardware, like in a product, what stood out as a surprise. The thermals maybe, or unexpected power drains. It feels like that part gets messy in practice. I might be oversimplifying how tricky it all is.

Title: Ask HN: How do you evaluate claims of “this model changes everything” in practice?

The release of every big model seems to carry the identical vibe: finally, this one crossed the line. The greatest programmer. The end of workflows and their meaning.

I’ve learned to slow myself down and ask a different question. What has changed in my day-to-day work after two weeks?

I currently make use of a filter with roughness.

Did it really solve a problem, or did it just make easy parts easier?

Has it lessened the number of choices or has it created new ones?

Have my review responsibilities decreased or increased?

Some things feel revolutionary on day one and then quietly fade into something that’s nice to have. Others barely wow, but stay around. ~

For those who've experienced a couple of cycles.

What indicators suggest that an upcoming release will be significant?

When do you alter your workflow, after how long?

A classic hacker news post that will surely interest coders from all walks of life! ~

After regular use of an AI coding assistant for some time, I see something unusual: my biggest wins came from neither better prompts nor a smarter model. They originated from the way I operated.

At first, I thought of it as autocomplete. Afterwards, similar to a junior developer. In the end, a collaborator who requires constraints.

Here is a framework I have landed on.

First Step: Request for everything. Obtain acceleration, but lots of noise.

Stage two: Include regulations. Less Shock, More Trust.

Phase 3: Allow time for acting but don’t hesitate to perform reviews aggressively.

A few habits that made a big difference.

Specify what can be touched or come into contact with.

Asking it to explain differences before applying them.

Consider “wrong but confident” answers as signal to tighten scope.

Wondering what others see only after time.

What transformations occurred after the second or fourth week?

When was the trust increased or reduced?

What regulations do you wish you had added earlier?

How do you avoid doom-coding while learning or experimenting? – Ask HN

Lately I have observed this algo in myself while learning something new. I constantly code for very short bursts sometimes on the phone or laptop at night, keep jumping between tools and end up consuming more than creating. It comes off as productive but seldom compounds.

A straightforward explanation that has provided me with a helpful point of thought is.

Make a mode selection.

Did conclusions actually occur?

Most doom-coding sessions are loaded with input, no closure.

There are 2 small changes that improved it for me.

Start sessions with a small, visible output goal (one function, one note, one commit).

Time-box input aggressively. I stop scrolling after 15-20 minutes of scrolling.

At the conclusion of every session, I would write what I would do next, even if I don’t do it. ~

Wanting to know how others do this.

Do you intentionally separate learning sessions and building sessions?

Do you have any heuristics to know when you have avoided input?

Would you block time for nothing?

My thinking is clearest when I am not working. It tends to be when I am: - Seated in a neutral place - My inbox is closed - There are no tasks to work on - I am free to think It feels like I am not doing anything, but often I’m making decisions I won't regret.

I think of it like this: - Input (reading, meetings, slack, other activities) - Output (creating, writing, executing) - Integration (doing nothing but thinking) Most calendars are packed with no time for the third.

Do you leave space for this? How do you make sure it’s not taken up by work? ~

Why do distinct systems end up having the same look?

I am often surprised to discover different systems that arrive at the same shapes.

You will find it in nature, but also within.

N/A

Organizational charts.

Patterns of traffic.

Ways to Fail.

Despite different inputs and histories they all yield the same outcome.

I use a mental model of sorts.

Local regulations and limits.

Consistent application of weight.

In the end, only a handful of stable shapes endure.

I'm curious now.

Are we overestimating the uniqueness of our systems?

What design patterns to use in your product?

Have you taken note of shapes showing up in different domains time and again? ~

What skills compound after 10+ years? (Ask HN: Submission)

I've come to realize that not all skills can stand the test of time.

Some things were very useful initially but quickly plateaued. Some felt like they were moving at a slow speed, but were quietly compounded a year after.

I always return to a rough outline.

Quickly acquainted with tools, frameworks, and specific stacks.

Slow skills: judgment, problem framing, communication, taste.

The gradual changes are often unnoticed daily but become apparent over time.

Projects become unclear.

Pile up constraints.

Being right is less important than the trade-offs you make.

I’d be interested to know what you think.

Which skills were more useful than you anticipated?

What’s something you over-invested in early on that didn’t compound?

What would you choose to learn more slowly if you had a second chance? ~

Do you model website behaviour for on a slow internet connection, or just hope it will never happen?

The mobile internet technically worked during a big storm some time back but barely. Half-loaded pages. The images were suspended. JS took too long. Most websites were only usable in theory.

The best ones shared some pattern. They;re not random.

Simplified Design.

word first

Avoid complicated client-side logic.

Quick in rendering even on a poor connection.

It has prompted me to think about a straightforward framework. The order of occurrence of different circumstances

Most of us design products for the first two. It is the third one where things break down.

There were some practical things, that helped me in those moments.

A server-rendered page must still read well when JavaScript is disabled.

The content must load before any decorative element.

A clear hierarchy, even without styling.

There is no important information hidden beneath the interactions.

Interested in the thoughts of others.

Do you deliberately design for suboptimal conditions?

Do you have a definition of “minimum usable version?” ~

I remember reading this thing about programming where people talk about behavior instead of inheritance. It stuck with me because Ive dealt with some code that got messy fast. ~

Like, when do you actually pick behavior over inheritance in stuff youre writing? I mean, the question is out there, asking for real experiences.

For me, inheritance seemed okay at first, you know, building these trees that looked neat. But then they turn rigid, and youre stuck. It burns you a few times.

Shifting to behavior feels better. Its not about what the object is exactly, but what it can do. That changes things.

Protocols help make that clear, or interfaces in different languages. The idea is, if it acts like it can do the thing, then it works. Kind of like the duck thing, if it quacks like a duck.

I have this rough idea in my head. Use inheritance when you want to share the actual code implementation. But for protocols, its more about what everyone expects, the shared behaviors.

Still, Im not totally sure where to draw the line between them. It gets a bit fuzzy.

How do others figure it out? What are the signs that inheritance is going to cause problems down the road, like aging badly?

I have been thinking about this idea of reasoning visibility for AI systems, especially in places where rules are strict. Like, in regulated settings, how much do we really need to see inside the AI's thought process. ~

Failures happen a lot in those domains now. They are kind of expected, I guess. But what gets tricky is when something messes up and you have to explain it afterward. Basic stuff, you know.

What parts did the model look at. What did it skip over. And where was it sure of itself or not so much. Those questions do not always have easy answers.

I came up with this way to think about it. Accuracy is what lets a system get out there in the first place. But showing the reasoning, that is what keeps it okay with the regulators later on. It seems important.

For anyone in finance or healthcare or stuff like that. What kind of visibility has worked in real life so far. And the parts where it just does not hold up yet. I am curious about that. It feels like some areas might be better than others, but I am not totally sure.

I have been thinking about how AI agents work, especially this idea of replica agents versus first principles ones. It comes up a lot in discussions like on Hacker News. The question is basically, when should these agents just copy what humans do in their workflows, and when should they kind of ignore all that and go their own way.

A lot of the agent designs out there start by asking how a human would handle the task. Like, they would open up a browser, click on some buttons, follow these standard operating procedures or SOPs. That approach seems pretty safe, I guess, because it is familiar. But it also feels limiting, like it is not pushing things forward enough.

One way to frame it that I have seen is replica agents are good in situations where humans need to check on things, step in if needed, or just trust what is happening step by step. On the other hand, first principles agents might be better when the main goal is just getting the most efficient outcome, without all the human habits getting in the way.

The tricky part is figuring out where to draw that line. I am not totally sure myself. Like, at what point do you stop trying to automate the worker exactly as they are, and instead start solving the actual problem in a direct way. It seems like some people might have heuristics for deciding this, maybe based on the risks involved or the type of task. That is the part that stands out to me, how to make that call without overcomplicating it.

Sometimes it feels like copying human stuff is easier at first, but then you get stuck. Other times, going from first principles could miss some practical details that humans handle intuitively. I think there needs to be more on that balance. ~

“I've noticed the pattern of big technical ideas. They’re obvious in hindsight. They cost money early.” ~

“What’s worked for me is a rough three-question filter,” Moxley continues,

“What assumption would be most easily disproven if it’s false?” “What

Is it something that can be cheaply verified in weeks, not months?

“Who would notice if this quietly failed?”

When I don’t skip this, what ends up happening is that I am endorsing the wrong thing. When I do, good ideas also die prematurely.

What the others do, curious to see.

Do you write out assumptions or is it an informal process?

How early do you bring outsiders to poke holes?

Any heuristics for distinguishing between "hard but right" and "just hard"?

Examples always appreciated. Failures too.

One area that I keep seeing carbon capture touted as a clean solution: data centers and industrial facilities. ~

What I have problems establishing is where it actually applies.

The way I’m currently thinking of it:

It functions in its optimal way when there are concentrated emissions.

The cost can add up quickly when scaled.

It simply relocates issues rather than solving them.

That doesn’t make it useless. Only very conditional.

Curious how others think about this:

Where is carbon capture really justified? Interesting tidbits Interesting tidbits Where does it feel like a delaying tactic? Which of the following constraints are most important in practice?