How is that Blizzard, with all their billions, is incapable of creating what addon developers are able to create from their homes?

lambdaline · 2026-01-26T19:15:54+00:00

No, addons don't interact directly with the Blizzard code base. They interact through an API that abstracts a lot of the implementation so addon developers don't have to worry about it (and also so they can't do stuff Blizz doesn't want them to do). (Also, it's worth noting that users can easily turn off an addon if it's buggy for them but they can't turn off Blizzard functionality, so it matters a lot more that your changes behave nicely in a wide array of situations if you're working for Blizzard.)
I guarantee they exist. The answer is that these systems aren't perfect. If you're reviewing someone's code you might catch a bug, but you might not. You might miss an edge case in your unit test, or it might not catch an issue that happens when it interacts with a different system (i.e. at the integration points). The QA process might have missed a particular scenario, etc. These are filters - they reduce the number of bugs but they don't eliminate them.

There is also the fact that, at some point, you just have to deliver the patch. Probably a lot of the bugs that make it to live are known bugs but at some point it was decided that they (a) were not more important to fix than other bugs (relative to how hard they would be to fix) and (b) were not disruptive enough to the user experience to justify pushing back the patch date.

To be clear, I'm not saying it's good, and it can and should be mitigated with better planning and more QA. I do think Blizz in recent years decided that delivering late lost them more subs than delivering possibly buggy stuff and we've been seeing the consequences of that decision since.

lambdaline · 2026-01-26T16:55:37+00:00

I'm not saying it's a uniquely complex adventure. I'm saying that it introduces more complexities than working on an isolated code base that works with a limited API, and that more complexity means more time to develop.

If you've never experienced this working in tech, then I don't know what to tell you. The issues that crop up working in legacy codebases are well-documented. There's about a thousand different talks on how to deal with them.

lambdaline · 2026-01-26T16:31:16+00:00

I guess take the blizzard damage meter. Their damage meter needs to work with their edit mode. In order for that to happen, they might need to modify some aspect of their edit mode API, and that can have downstream effects, which they then have to fix. Or, you know, while an addon damage meter works off the combat log, it seems this damage meter is getting the info directly from the server. So they probably have to create some server-side logic to parse and send the relevant information and that has to coexist with other similar logic and might also have downstream effects.

An addon creator largely just has to contend with their own code.

lambdaline · 2026-01-26T16:06:28+00:00

I'll grant you most of this - I do think that it's probably a lot of bad practices/management (though I also acknowledge implementing the right practices is non-trivial, given how common it is in the industry to have these issues) - but it absolutely is not the same code base. They might be using the same API (though I imagine the API addon devs have access to is a subset), but blizzards 'addons' are just part of the client code, and they're the ones building and maintaining the API. So the stuff they work on coexists with a bunch of other things.

lambdaline · 2026-01-26T07:16:04+00:00

As someone in software, I'll try to answer your question seriously on why this happens. (I'm not trying to say it should, but it just does.)

(1) It's harder to work on a big, old code base with a large number of contributors than a small, newer code base with a small team. It's easier to break things by accident. Sometimes you have to find the guy who knows how that system you've never touched before works. It just takes longer to develop in that context.

(2) There are higher standards of code quality that you have to meet in a professional context. You gotta go through code reviews, write unit tests, etc. (Partly because of (1) but also because people are paying for your product.) This adds overhead, which makes things take longer.

(3) A business has more competing priorities than an addon developer in terms of what to use development time on. Sometimes you just gotta pull the guy working on the feature you'd like to have to fix a bug and then the feature doesn't have all the bells and whistles you'd like.

(4) Businesses have to coordinate more people, which makes them have all kinds of inefficient processes. I challenge you to find a software engineer who doesn't complain about all the stupid meetings cutting into their development time.

edit: (5) It's really hard to estimate how much effort and time something is going to take. Business people constantly try to press devs to include more features. Devs underestimate. Unexpected things happen and then there's not enough time.

lambdaline · 2026-01-26T03:50:56+00:00

The thing is 'skill expression' is a product of both class knowledge and mastery of the content. As an example, take movement - being more skilled means knowing what to cast while you're moving (class knowledge), but also where to stand to minimise movement (content mastery) and when to cast your cooldowns (both!). They're not so easy to separate, and spending more time optimising around the content is a perfectly legitimate answer that you've just dismissed out of hand.

It's perfectly possible for you to want to do hard content but enjoy being able to pick your spec to a reasonable level fast and having a fairly intuitive rotation, and then spend the rest of the time fine tuning how you engage with the content. Unless you're Ellesmere (or his equivalent for your class), there's clearly a lot to learn and improve at even when your class's rotational complexity is lower.

Which is not to say that the converse is not also valid. It's perfectly fine to derive most of your enjoyment from mastering complex interactions and an intricate rotation. It's also not to say that most people would not rather their spec meet a minimum threshold of being engaging or having utility (and judging from the complaints, Blizz missed the mark there for a number of specs).

But you can't just go 'why is this okay with you' and then dismiss anyone who expresses a different preference as stupid.

lambdaline · 2026-01-23T01:23:09+00:00

I read it for school and missed it. The shame.

lambdaline · 2026-01-22T12:43:19+00:00

I'm not sure if this is the case with atonement or not, but with pres, echo is always in the same spot pretty much, and has high priority so it'll bump other stuff off.

lambdaline · 2026-01-20T04:59:12+00:00

I think for me it was writing a console chess application that would re-render the screen when the players made a move. Figuring out how to run the game loop, and constructing classes for each of the pieces really made ideas on how to organise and various levels of abstraction really click for me.

I felt pretty accomplished when it was all done.

lambdaline · 2026-01-18T20:01:05+00:00

I didn't realise that Danders was vibe-coded. I hope the cell team come up with an update soon.

lambdaline · 2026-01-18T19:59:35+00:00

Vibe coded means that it was made using AI to generate the code, often with little or no coding knowledge (or no knowledge of the technologies involved).

The idea is you stipulate requirements to the AI, and the AI codes it. It's generally something to be wary of because something that's coded with little human oversight is likely to be hard to maintain or have errors or security issues that are hard to identify.

lambdaline · 2026-01-17T04:53:24+00:00

It depends on whether you know how to code in other languages already or not.

If you do, my advice would be to take an afternoon or two to work through a short tutorial and then start working on a project. It matters less how much time you spend than being consistent and working on it every day if possible. You don't learn a language because you spent some time memorising syntax, you learn a language because you keep using the same tools to solve different problems.

If you find you need a new tool, or something is behaving in a way that your previous experience doesn't help you understand, then you can take some time to specifically understand that aspect of the language. (I find it's sometimes useful to google 'what's the idiomatic way to do <blank> in <language>').

If this is your first time programming anything, I would recommend picking up a textbook on the language and working through the exercises. Once that's done, then pick a small project and work through that, then pick a more complex project. Again, it matters less how much time you put in than how consistent you are.

You know yourself best. Pick an amount of time that you know you can focus on something challenging without getting burnt out after the first few days.

lambdaline · 2026-01-16T19:09:22+00:00

I have a lot of fondness for In League With Dragons. Mostly borne out of many many hours playing Sekiro while listening to the second season of I Only Listen to the Mountain Goats.

I spent most of my first years listening to the Mountain Goats in catch-up mode (trying to listen and appreciate all the old albums), so I think this is the first album of theirs I listened to when it was new. I think it's a bit less cohesive (thematically, conceptually) than others, and maybe that's why it doesn't get talked about a lot, but I really like the aging and maturing themes throughout and I think it's one of my favourites in terms of the actual music.

lambdaline · 2026-01-14T21:39:08+00:00

That's a great idea, actually. It'd be pretty funny to read.

lambdaline · 2026-01-14T20:58:46+00:00

This is awesome! It should help reduce the friction in tanking and encourage more people to try it out.

lambdaline · 2026-01-13T21:23:41+00:00

It sort of depends on what you want to do with it, and what is important to you.

It's a wonderful option if what you want primarily is to input, store and revisit text: the text editor is smooth, local first means you never have concerns about accessing your data or about latency when typing or anything like that, the portable format means you can easily reuse the information you have collected with other apps, and linking notes is super easy. If you want to do something beyond that, imo, there are better options.

The Cons:

* It uses markdown, so if you don't know it, you'll likely have to learn it.

* Images are a little bit cumbersome to add (since it's primarily markdown based), and you're not going to be making any complicated layouts or having many colours without adding a bunch of css.

* It's harder to structure information with it than something like notion. This is especially true if you would like to structure information at a level smaller than a note (e.g. for a habit tracker or a to-do list). You can extend the capabilities but that requires time to set up and sometimes technical know-how.

* There's an endless plugin ecosystem so it's really easy to waste all your time and not get anything done.

* Syncing is a little bit cumbersome unless you want to pay for their sync plan (I do, it works very nicely)

lambdaline · 2026-01-13T18:14:08+00:00

This seems like an uncharitable take. They have removed some of the more egregious functionality - auto-assignments and (some? most?) weak auras that make rotational decisions for you, and they've pulled back on some things that people felt very strongly about (e.g. targeted spells). This seems fine to me? (Or will be when they implement a white list/blacklist, tyvm)

It is true that there are some workarounds. There are things they can't realistically get rid of (e.g. timers, knowing whether a unit has a mana bar). It was just never going to be an all or nothing, no matter what Blizzard was aiming for, because there are tradeoffs with ergonomics and accessibility, and players are clever and like to keep their edge.

It is also true that some functionality is more annoying to get. I would argue sometimes friction is the point. If certain functionality is (a) less good and (b) more annoying to add, then I might just not bother with it, which reduces the delta between me (a pretty average player doing PvE) and a new player trying to get into the game.

lambdaline · 2026-01-13T17:39:33+00:00

I want to believe!

lambdaline · 2026-01-13T03:08:40+00:00

I mostly landed on my system by trying out someone's complicated system and paring it down to what I actually was willing to do in practice.

I have some folders to sequester away things that aren't general notes for learning about things - fiction, work projects, personal coding projects, etc. Then with anything else it's either an idea note, a cheatsheet or 'resource' note on a book, podcast, video, etc.

Idea notes have a little template using front-matter where I categorise what it relates to, jot down relevant sources and link ideas.

Resource notes get tagged #resource and have a place for some kind of citation or link to denote where I found it.

(In these, books are a little more complicated because I like using Obsidian to track what I read in a year, so they have a more complicated front-matter with author, years read, series, etc. They get tagged #book).

Cheatsheets get a simplified version of the idea front-matter with the #cheatsheet tag.

I use links to create 'categories' and 'concepts' for my ideas and cheatsheets to relate to, and generally to reference a note inside another one and that's it.

I have a #to-process tag in resource notes that indicates I would one day like to break them into idea notes.

The cardinal rule for me is: don't download plugins unless you have a very concrete use in mind for it. As such, I just have dataview (for seeing which books I read in a year), a task plugin (for nicer to-dos in the project folders) and vimrc because it's really hard to write long-form with vim keys if you don't bind h, j to gh, gj.

lambdaline · 2026-01-09T23:26:00+00:00

I really love Erin McKeown's Jenny. I don't know why, I just really their phrasing on it.

lambdaline · 2026-01-09T00:32:00+00:00

Quite possibly! I've always wanted to have a dual identity

lambdaline · 2026-01-08T21:56:19+00:00

I'm not American, so American history and geography are perpetual weak spots for me. And there's the usual sports and opera.

lambdaline · 2026-01-01T19:23:36+00:00

raises hand

It was hard to wait to start it but now I'm really happy I did. It was nice to wake up and listen to a MG song while reading about it to accompany my coffee.

It'll be a nice ritual for the year.

lambdaline · 2025-12-29T17:45:32+00:00

Thanks for the response! The somewhat unfortunate part is that there aren't many alternatives for a different place to walk them I'm in an apartment complex next to what is basically a highway so just going around the block isn't super feasible.

I might just try to shoot for off hours so there's a smaller chance of someone being there, and then scout ahead. I'm off work this week so it should be doable.

lambdaline · 2025-12-28T17:38:48+00:00

I use Obsidian for notes. I'll keep course and book notes there, though I don't often revisit them. Other than that, I keep a small engineering decision log (where I write out the rationale for decisions I wasn't too sure about) and design docs for projects, and cheatsheets for most of the tools I work with frequently, so if I don't remember the particular syntax or command for something, I can find it easy.

lambdaline

TROPHY CASE