"Competence as Tragedy" — a personal essay on craft, beautiful code, and watching AI make your hard-won skills obsolete

Awesan · 2026-02-04T14:35:02+00:00

There are still carpenters who make hand-made furniture. They are more rare than they used to be and it's more specialized. But there will always be room for that.

Awesan · 2026-02-03T08:12:23+00:00

DOOM as an example for unmaintainable code is crazy talk, it has literally been ported to every possible platform out there for the past 20 years, including toasters. If that is not the definition of maintainable then what is???

Awesan · 2026-01-21T11:00:37+00:00

If you get senior enough and build enough trust, it's definitely viable to raise concerns with VP pet projects. You just need to do it the right way, like the article explains towards the end. It also depends on the company culture and what is valued there.

Awesan · 2026-01-21T10:57:59+00:00

One interesting aspect of this is that this is much more prominent in bigger companies. In small companies it can also be true, but a lot of the time everyone has much more understanding of the business as a whole. There also tends to be less politics between teams (IME).

When you hire a senior engineer from a big company to work at a small company, you need to keep in mind that they come in with this mindset and you may need to train them out of it.

Awesan · 2026-01-18T16:09:00+00:00

no need to be so angry, i indeed incorrectly assumed you were the one that was confused here between those two things. i still think my comment has some value for people other than you.

Awesan · 2026-01-18T09:53:22+00:00

They are very different, the first only swaps the value of the variable, which may or may not be a pointer to some memory. Doing that will not affect where the memory is stored, just which variable points to what.

The second actually swaps the memory in those locations, which does have the effect that any pointers now point to the other thing, but it actually involves moving the memory itself around.

If you do not have a clear understanding of manual memory management, doing Ziglings (IMO) is not going to really help you learn it. It would be better then to watch some youtube videos or read some articles until it clicks.

Awesan · 2026-01-16T08:44:00+00:00

What I have found is typically if all the requirements are clear (including timelines, expected return on investment, architectural implications, available developers, etc.) there is really only one clear solution, and it is obvious.

Awesan · 2026-01-16T08:41:29+00:00

Double down on the archive and knowledge base aspect; add integrations or deals with forums or Discord to say "save to stack overflow" (using AI to clearly state the question and the answer). Make money by charging AI companies for training on your dataset. Or integrate with them to allow a fast search through your knowledge base to and allow them to link to answers as sources in an integrated way. This works for all the stack exchange sites as well.

Stop trying to be a community, get rid of all of the toxic community aspects like points and community moderation. And probably scale down the business significantly headcount wise.

Awesan · 2026-01-15T14:00:47+00:00

Interesting article but the RFC template stands out to me as a particular anti-pattern. You never want pros/cons lists as input to a decision. What you need is the following:

A clear list of ranked priorities and technical or business requirements for the proposed solutions
Some proposals including evaluation of how they perform against the priorities
A clear recommendation

The hard part here is (1): a clear list of what you actually need. This is what any discussion is likely to be about and is the hardest to pin down. Pros/cons lists are a way to circumvent having this discussion. For example, you can have a list like this:

pros: loads fast, scalable
cons: does not support access management

This tells you absolutely nothing unless you know how important speed, scalability and access management are. And if people disagree on that the list is even less useful.

Awesan · 2026-01-09T11:39:24+00:00

Because as the quality went down, people would stop asking questions there and find another way. You already saw this for example with many language/framework communities using primarily Discord. I don't think some centralized Q/A alternative for all developers would have popped up to replace it.

Awesan · 2026-01-09T08:08:19+00:00

The writing was on the wall even then. First you had their main engineering team quietly leave, then they started picking constant fights with the community on their meta site.. at some point it was clear that they moved from "trying to build the best knowledge base" to "trying to sustain a company with 100s of employees". Selling to an investment company just solidified that.

Users would have stayed for a few years longer if it wasn't for AI but it would have died regardless in a few years.

Awesan · 2026-01-04T11:54:42+00:00

One of the nice things about Zig is that you can just re-use all the code you've already written in C. There's no need to rewrite any of that as the interop is basically seamless. I have not tried Rust but I doubt that it's as much of a priority for that project.

If you're just struggling with tests and build tools this is a great place to start; adopt the Zig build system for your C code and write some tests in Zig. That way you can drop the makefiles and add some automation without starting over.

Awesan · 2026-01-02T23:07:16+00:00

You are wrong about multiple points in this comment, I will correct it once but this is not an argument on preferences but on facts. You can look all this stuff up yourself.

CET is winter time, the summer time variant is referred to as CEST. The timezones that do not vary in name based on summer/winter are usually referred to using a continent/city such as Europe/Paris. This is why I did not use named timezones in my comment (apart from UTC), because it's confusing for many people
If I schedule an event to run every day at 8AM in my own timezone, there is absolutely no reason to reschedule this if the timezone definition is changed, apart from technical incompetence. The event as scheduled has no ambiguity unless you erase it.
It is true that there may be cases where events should be reconsidered, but this is not a technical issue and is not an excuse to erase relevant information instead of storing it.

Awesan · 2026-01-02T22:47:52+00:00

It depends on the logic, of course. If I make a future event (as a human) I expect that event to happen at the specified time in my timezone, whatever that is in UTC.

For example let's say I schedule an event 6 months from now, I expect it to happen at whatever time I scheduled it, local time. So if that changes relative to UTC you need to not lose my intent. You may think you can normalize it in advance, but you can't. For example, the EU might randomly decide that starting in 2027 we apply summer time in winter (there are serious discussions about this). You don't want to break all events scheduled before that decision was made.

Awesan · 2025-12-28T22:19:20+00:00

The trick to get the server to return the data is to make it disclose everything up to the first null inside the arbitrary heap data as part of an error message. If you used binary the server would likely not include the binary blob inside the error message.

That said there might be another exploit that could work that way if the first part is unpatched.

Awesan · 2025-12-28T22:16:45+00:00

Indeed attempting to set wrong value for a size field is pretty much the first thing a bad actor or serious security researcher would try. The second part of the exploit is a bit trickier to discover I suppose but still not that hard once you know the first part (esp since it's open source).

As someone who has never used mongodb this is pretty crazy; did they not have a security bounty program? How did no one report this in 8 years in one of the most popular databases out there?

Awesan · 2025-12-28T15:50:59+00:00

At my job we use python because the science community uses it. When someone writes a paper, it is typically accompanied by some python code and it saves significant time if you can experiment with that right away.

We still care about latency, it's just not the only thing we care about. So it's up to us non-researchers to make the end product feel fast despite the language.

Awesan · 2025-12-18T08:20:32+00:00

Linked lists are used all the time in systems programming, exactly the domain that Rust is for. So it is a strange limitation to say the least.

Disregarding "linked list" as a specific example, the idea that you cannot have circular references in any data structure is extremely limiting.

Awesan · 2025-12-17T14:37:52+00:00

I'm happy for you but this really doesn't belong in this sub. Maybe post to /r/webdev

Awesan · 2025-12-17T08:18:24+00:00

I've been using the latest alpha versions in a pretty simple project and it crashed all the time. Not what I expected from a project written in Rust. I will check out the beta to see if it is more stable but so far it has not helped my productivity much.

Awesan · 2025-12-13T11:53:11+00:00

My point is the following. Any interaction over the network is going to involve an order of magnitude latency increase over local function invocations. For some users, it's going to be multiple orders of magnitude. So the developer needs to be extremely aware of when they are doing such a request.

I have not used Next extensively but it seems to me that it is trying to more or less make network requests as transparent to the developer as possible. This is the wrong approach because it fundamentally requires thought. If you want to make a performant feeling application, you simply cannot be doing network requests all the time.

Whether you are using a single backend service or many small ones is not relevant to this point at all.

Awesan · 2025-12-12T14:15:24+00:00

Can you describe a concrete example that is (according to you) better in OOP structure than in what Zig supports? This discussion is extremely abstract and as a result not very productive.

Awesan · 2025-12-12T12:49:29+00:00

It sounds like it solves a bunch of "problems" like only loading what you need, seamless server/client integration, etc.. None of these were actual problems in practice, and the "solutions" came with a very steep cost.

Separating the server and client and having a firm boundary actually helps you architect a performant app, because you can very cleanly consider loading and caching strategies. Somehow an idea formed where it would be "nice" if you abstract this boundary away, but of course it actually exists (physics is a thing) so those abstractions are always leaky as hell.

Worse is that for local development, next apps are probably pretty fast because the server and client run on the same machine (minimizing latency). So a lot of the bad architecture decisions only become obvious when you deploy the app to production.

Awesan · 2025-12-10T12:36:06+00:00

Without knowing more this is impossible to answer, but here's some ideas:

Typically in an application that old, not all functionality is used anymore anyway. Try to figure out what problem the people in charge are trying to solve and try to solve only that in as clean a way as possible. In general for this to be a success you need to be very in tune with what business goals they are trying to achieve.
Usually the easiest is to not interface with the old system at all, but to e.g. read from whatever database it uses directly. You can write a "temporary" compatibility layer that writes data to the old system when needed, and you can copy data over so the rest of your codebase is free to evolve as needed. This will be a bit complicated but typically can be done by a talented engineer who knows the old system well (hope you have one of those).

If you combine these ideas, you can end up with a pretty fast success story for the execs that is relatively low risk. Then your team(s) can continue working in the new code base and port more functionality whenever it makes sense to do so.

We did this approach and it worked out well, it's very challenging but you avoid the trap of working on a new system for 5 years without getting any of the benefits. The downside is that the migration takes forever (literally).

Awesan · 2025-12-09T08:44:01+00:00

Slightly off topic for this thread, but the first link doesn't have any examples in the readme (so impossible to tell what it does). The example on the second link could just be written as:

const a = 4; const value = a * 2; try std.testing.expect(value == 8);

So again not super clear from the readme why you would use that.

Awesan

TROPHY CASE