A lot of things are like this, and so to excise the word “just” would be to stop using a word that often concisely and accurately conveys what I’m trying to say.

It would be better if the article just said “this is rude.”

Also, I was constantly fighting/reverse engineering Neovim to get the granular level of control over behavior that I needed for a seamless integration. It’s just a type of programming that’s extremely frustrating and not fun.

In the end I implemented custom vim emulation from scratch and surprisingly it wasn’t that hard to get the “20% of features that people actually use 80% of the time,” except it’s more like 5% and 95%, and in exchange I could own the whole stack instead of depending on a third party black box. Never been happier to delete a whole subsystem of code in my life.

That said… the article doesn’t really ring true to me. What he is saying about the complexity of each part of the stack (http, html/dom, css) is technically true, but that’s not really how it washes out in practice. This whole “CSS is a complex graphics engine!” “HTTP is a protocol you could write a whole dissertation about!” sounds like an argument being made by someone trying to make a rhetorical point about web. In practice for most of web dev you don’t need to understand the deep nuances of CSS or HTTP or whatever. Yes, there is a large breadth of material you have to learn but the depth you actually need in any one area is much less than the author is trying to imply.

And yes, web is trash, but for different reasons. In fact some of those reasons are the opposite of what the author is saying. He says that each part of the stack is so complex it should be a separate specialty. But the real problem is the very fact that things are so complex. Rather than accept that complexity and subdivide the field into different disciplines, we should get rid of all this unneeded complexity to begin with.

Theoretically, after everything washes, the electoral vote is what the people want, because it reflects which of the two candidates, both of whom are optimizing intensely for the electoral vote, is able to get it.

In your analogy, if you copied the VM state onto two different host systems, I would think each host system would be a separate conscious experience. It's whatever being a host system is that generates consciousness, not the state itself.

This does not happen at all. When you break a system into subsystems, all the previous connections that get remapped to new connections between subsystems still need to happen, in order to solve the fundamental problem that the system solves — except now instead of just making the connection directly, there has to be a "cross-functional" meeting between teams and a complicated communication layer between the systems. And if somehow you find a breakdown that requires minimal connections between subsystems, then those connections wouldn't have existed in the original system either, and the N² problem doesn't exist.

Comments URL: https://news.ycombinator.com/item?id=37131445

Points: 4

# Comments: 7

Comments URL: https://news.ycombinator.com/item?id=36595152

Points: 48

# Comments: 63

The other things are just proxies for the real measures, that people made up, and in fact are often harmful to the main goal. Like "documenting code" and "writing tests" a lot of the time are just cargo culting to make people feel like they're being responsible and following "best practices" without actually improving the measures that matter. I think that the other unlisted metrics in your "every measure someone dreams up..." are likely to fall under this category.

There isn't an infinite number of possible measures like you're suggesting, there's a finite number and a rather small number at that. You can definitely be really good or really bad at quickly shipping performant bug-free code that does its job. The problem in this debate is that one side is completely ignoring one of these measures, and trying to claim that it's because they have to prioritize the other ones, and that this is just an inevitable tradeoff, rather than that we lack the skill as an industry to do all of these things at an acceptable level. Being a good programmer may involve more axes than being a good chess player, but I think the claim that there are so many axes that it negates the existence of programming competence reductios to absurdum pretty quickly.

To a first approximation, the reason modern software is slow isn't due to failure to optimize this algorithm or that code path, but rather the entire pancake stack of slow defaults — frameworks, runtimes, architectures, design patterns, etc. — where, before you even sit down and write a line of "business logic" code, or code that does something, you're already living inside a slow framework written in a slow language on top of a slow runtime inside a container with a server-client architecture where every RPC call is a JSON blob POSTed over HTTP or something. This is considered industry standard.

The "business requirements" guy is basically saying, I have to ship this thing by friday, I'm just going to pick the industry standard tools that let me write a few lines of code to do the thing I need to do. Ok, but that's the tradeoff he's making. He's deciding to pick up extremely slow tools for the sake of meeting his immediate deadline. That decision is producing unacceptable results.

It's not enough just to say people have different priorities. Selecting an appropriate point on multivariate system of tradeoffs is part of the skill of being a programmer. And if there's no point on the curve that delivers acceptable results in all categories — if, given a certain set of tools, it's not possible to ship quickly and deliver acceptable performance — then it should be an impetus for the programmer, the craftsman, to find better tools, improve his skills, push the "production curve" outward, until he can meet all the requirements.

For instance, a large percentage of modern programmers don't really know how to program from first principles, and tell the computer to do precisely and only the thing it needs to do. Essentially they only know how to glue tools together. Then in their head they're like, well gee, given that skillset, I could either (1) spend a bunch of time optimizing "hot spots," writing crazy algorithms, heroically trying to fight through all that slowness... or I could just (2) deliver the business logic and call it a day. Then they call this "prioritizing business requirements." No, there's a third, alternative, better option, which is to use better tools, which might initially be harder and more time consuming and less ergonomic to use, and then learning to get good with those tools, putting in the practice, recognizing patterns, thinking faster over time, coding faster... all of this is part of what mastering the trade of programming is about.

At the end of the day, there is just an ethic of self improvement and craftsmanship that is totally missing from programming today, and it surfaces whenever this debate comes up.

Comments URL: https://news.ycombinator.com/item?id=35718912

Points: 141

# Comments: 125

Am I crazy? I feel like what I'm describing is a near universal phenomenon and everyone knows what I'm referring to/has experienced this. I'm talking about how in general, people just don't like people who are "right all the time." People don't like criticism delivered bluntly even when it's correct, relevant and actionable. People don't want to hear things with implications that go against their moral values, or suggest that something they spent lots of time on was wasted, or reflect badly on themselves. There's that famous quote about how people don't want to hear things when their paycheck depends on them not hearing it. They don't like hearing those things even when they are true and directly related to them. I don't like hearing those things. I'm talking about those cases.