I don't disagree outright, but every time I read something like this it's obvious that it doesnt come from experiential success in the relevant area, just kind of a vibe about how things should be done, without tangible proof. IE the legendary Dropbox analysis on here. Never in my professional career have I cared about anything you listed here
Except for the last one, the other two are from my experiences needing to write those docs.
For decision doc, do you prefer tracking stakeholders comments scattered in multiple places (and also track down the closed comments), or have a single places to read their concerns and address them explicitly as part of the decision making process?
For investigation doc, have you not had the need to hand off to someone else, maybe because you need to go on vacation, or you need to hand off to a colleague in a different time zone? How does the one who took over know what was done for a line "we investigated this hypothesis and it didn't work"? What if the action taken to validate the hypothesis is not comprehensive or the conclusion from the actions is not correct?
Wait have you never had a work experience where people make decision without properly asking around then someone on another team chimes in to say actually you missed X. Or you tried to fix something or an incident but have to read through a slack thread to figure out what's been tried? These seem like common work scenarios at most places
I think he meant examples where "Managing and updating the DOM is stupid simple." The consensus here seems to be that updating the DOM is a difficult problem. It would be nice to have counter-examples.
I am sure it is hard if you have never written an application without React, jQuery, whatever before. That doesn't make it hard though. It just means its something, only at present, uncomfortable.
Here is how I do it. This is all the front end code for a large personal project.
My observation is that no matter how complicated and large the application gets anything that ultimately runs in the browser scales in size disproportionately slower in the browser code than elsewhere. This remains true no matter how much of the instruction set you intentionally try to put into the browser. That said, why even bother with this framework bullshit in the first place if the code it abstracts is never the primary problem in any given application? The larger the application gets the less significant the browser portion of that code becomes as a percentage of total application size.
Obtuse maybe, but I'm not missing the point. Their point is nonsensical, given that LLM generated code isn't "as good as fast food compared to home made meals" or even comparable to "food".
The point is, for most projects there is nothing wrong with writing McDonald's level code. It's not as healthy or tasty as a homemade meal, but it will perform its main function (i.e. prevent you from starving).
reply