I agree that the word “just” carries that connotation but I disagree that it’s a bad thing. When I ask if we can just do something my intent is exactly to communicate that I think the thing is simple, that the details are unimportant (to me, to us) and that it ought to be easy to do (and if it’s not, that’s a problem in and of itself).
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.”
Back when I was building an IDE with a custom text editor, I initially used embedded Neovim thinking I would get the entire vim feature set out of the box for free. Unfortunately this became a never ending source of bugs. I think the fundamental problem was that my application was structured like a game with a main loop in a single thread, and Neovim turned text editing into an async operation, where I would have a separate thread reading events from Neovim and then trying to safely update the global buffer.
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.
I dunno. On the one hand I hate “web dev” more than anyone. I think it has led to such an astronomical decline in software quality that if you described it to someone from the days when computers were 1000x slower, they straight up wouldn’t believe you.
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.
Why are financial crimes morally exempt in a way that, say, violent crime is not, even if the aggregate damage from the financial crime is greater? Unless you’re arguing that this isn’t possible?
Politicians know the electoral vote is what matters, so they adjust their campaign strategy to optimize for it.
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.
Having an existing example showing that something difficult is possible causes everyone else to replicate it much faster, like how a bunch of people started running sub-4-minute miles after the first guy did it.
Thought experiment: what if you copied and restored the backup into two bodies, and both bodies were a state continuation of the original? Would the two existences be simultaneously the smae person? I think it would make more sense to say that at the moment of cloning the two bodies are separate consciousnesses with the same state.
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.
The biggest difference I’ve seen in how people learn is whether they learn things top down or bottom up. I generally prefer to just have the main idea or concept explained directly to me so that’s how I try to teach people things as well. Came as a shock to me when I realized lots of people want to go the other direction, seeing lots of examples and then later arriving at the general concept themselves.
> Splitting a system into subsystems allows each team to focus on their piece of the puzzle while minimizing the amount of peer-to-peer coordination.
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.
The flaw in this point is, there are really only a handful of measures that actually matter: writing performant code, shipping quickly, delivering business requirements (really this is an official sounding way of saying "doing the actual thing the program needs to do"), and eliminating bugs.
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.
I don't think the structure of the "business requirements" argument is correct, and I will try to explain why.
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.
That feels like a bit of an edge case. I mean, I take your point that you can definitely have no social skills and run around interrupting people's conversations and going "hey, did you know that animals are tortured every day?" and that would be you being a jerk. But I'm not talking about that.
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.
I don't think I disagree with point #1. What you're describing is just not stating the truth. I'm sure "you can't handle the truth" is wheeled out in all kinds of situations where the person saying it is the one who's wrong.
I'm refuting the narrower argument that is sometimes made that just because something is true, it doesn't give you the right to say it.
In regards to point #2, I agree that if I deliver the truth and include a side payload of being-a-jerk, certainly, I'd be responsible for that payload. But many people in many cases think that just stating the truth simply, plainly, no extra malice or attacks, just stating a disagreeable truth bluntly, is being a jerk. In those cases I think the upset really is just about the underlying unpleasant truth itself.
I'd argue that telling someone the truth does absolve you of responsibility, because if the truth upsets someone, what they're actually upset about is the reality of the universe. Or if it's a truth about them, then the reality about themselves. The truth-teller is just the messenger. Each person is responsible for how they deal with reality, including the parts they don't like.
I get what the article is saying. Given the reality of how people are, when you state the truth it has x effect on others, and the author is arguing that you are responsible for that effect. But I'd argue that when a truth upsets someone, even if you hadn't told it to them, eventually it would've upset them anyway, because the underlying reality that upsets them is still there. You aren't ultimately the cause of their upset.
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.”