rmtech's comments

What's the problem? Which Google products are holding you back?

Email should be easy.

Android?

Docs?

Situations like this are what money-printing was made for.

> can do this too.

Yes, it CAN but whether it actually does depends on the details. If you are a cleaner or an uber driver, you might generate some surplus but you might see the other parties take all or almost all of that surplus.

> They do so, because they are competing with other employers for talent.

Yes, but the RESULT of the two-way competition where both employees and employers are competing is undefined in a simple model of the market.

If you work as a cleaner or an uber driver, you may find that even though you generate some surplus, you don't actually get any of it (or you get almost none of it)

> That's thanks to competition between companies. That's market forces at play. You want it there? Accept it on salary negotiation too.

This is itself a bit naive. In a basic market with voluntary transactions the distribution of the gains from trade is undefined.

If your labor sells for $100/hour and costs you $10/hour to produce (basic food, water and shelter) then it is a perfectly legitimate equilibrium for the company to pay you $10.01/hour and take the other %89.99 as profit.

It's only through politics that we can make sure that the gains from trade are evenly split. The math of markets doesn't define it.

A theme that comes out again and again in the comments here is that in a technical community, complaining that a tool could be better is a reliable signal of a dumb/lazy worker.

At the same time, many tools could actually be a lot better and if we all magically traveled 50 years into the future we would find all these better tools and see that it wasn't only the dumb/lazy people who used them - it would be everyone. For example, how many people write applications in low-level languages like assembler today? Not many - but at one point that was the only option and anyone who complained about it would be labelled as a lazy worker.

The signalling aspect of this certainly distorts the discussion, but bear this in mind:

It is simultaneously true that git is a tool with a poor interface and a bunch of warts AND every aspiring developer should do the work and learn it in detail so they can use that knowledge to signal to people that they're not lazy and/or dumb (and the lazy/dumb people - even knowing this - will not do it, so the signal works).

I'm sorry, but if you don't know everything about everything then you're lazy and useless and you need to get good.

When I was a lad, we used to walk 10 miles every day to school in the snow - AND ENJOY IT!

etc.

Yeah I think this is actually pretty important. I wonder whether associativity of unrelated changes generalizes to other git problems?

> With git, it's something you _directly_ interact with so I would expect you to understand it in great detail.

Yes, you are describing what is broken about git: its abstractions are leaking too much so people who touch it have to know all its internals.

I touch x86 assembler every time I run high-level code, it's just that other kind folks have gone to a lot of effort to make it so that I don't have know how the internals of that low-level stuff work.

Abstractions allow people to be productive without knowing in great detail how absolutely everything in the universe works. A good tool has simple, non-leaky abstractions with a simple interface. Git is not a good tool.

Any system will get dragged down by the need to support all sorts of legacy use-cases. I think there's an xkcd cartoon about this?

The core task of a VCS is versioning and collaborating on text of some kind. Git doesn't do this in an optimal way, so eventually it will get replaced by something better. In the meantime we'll all get on with learning its ins and outs, just like previous generations learned how to use punchcards.

A good data management system (with hashes of datasets etc) is great. Data mess is not fun.

Merkle trees are also fun and have applications elsewhere like cryptocurrency/blockchain.

I don't have a problem with computer science in general, it's a fascinating subject.

I take the view that developers shouldn't be spending their time fixing their VCS.

I use PyCharm. I don't know how PyCharm works internally. I don't even know what language it is written in. I know that it provides syntax highlighting, smart replace, code completion, etc.

Similarly, my car mechanic has a bunch of tools that he doesn't understand in detail; they have interfaces (like a gauge on a pressure sensor).

Progress requires these interfaces, it requires these abstractions, and over time I'm pretty confident that we'll get a better VCS than git that has better, more user-friendly abstractions and it will take over the market.

> With that attitude, I would never, ever, ever, hire you.

There are two separate issue here though.

(A) How much work does a given person want to put in

(B) How much work does a given tool require.

It can simultaneously be the case that git is bad/overcomplicated AND that you should only hire people who bother to learn it really well.

Why?

Well, learning hard things is a reliable signal of diligence and hard work, which are generally useful traits.

But at the same time, forcing everyone to learn something annoying and time-consuming just as a test of grit isn't maximally efficient. The same effort could be put into more productive tasks.

> Why did you go into software engineering?

Well, I'm not a software engineer - in the Data/ML area so I am much more interested in the properties of data than the properties of code. But having said that I certainly like clean, efficient code and I care about languages (maybe just spoiled by python?!).

I can't see myself as a software engineer so I think your instinct is right. My passion is data and ML.

> A tool you use every day definitely falls into the category of Stuff You Ought to Know, in a way that understanding how quantum tunneling is used in an SSD is in the category of Stuff You Don't Need to Know.

I use an SSD every day though, as well as an LCD display and a laser in my mouse. So by this reasoning, I need to study quantum mechanics; it would only take a few weekends of focused study to understand the Schrodinger Equation etc.

These things fall into the "Don't need to know" category because we as a species have made very effective user interfaces to them whereby you really need to know almost nothing about their internals to use them.

The ideal version control system would work like a mouse or a monitor. Completely intuitive, just works™.

That doesn't matter, the way people actually use git is that almost all repositories have someone or some small group who rule them, so nothing is really lost by having an easy option to purge things from history. And an inconvenient option (possibly more than one!) does exist.

But for each one of these, the less I have to know about its internals, the better.

The ideal option for each of these things is that it "just works". When you have to think about the internals of your package manager or your CI or your virtual environment, that's a flaw in it, not a reason to celebrate.

Yes but filter-branch is horrendous and could very easily result in unintended side-effects, as well as potentially being very slow. I think this command is a great example of the problem; what a user really wants is an undo button but what git gives them is this thing.

I use an x86 CPU every day for work and I have no idea how it works in detail, and thanks to the magic of separation of concerns I don't have to (perhaps apart from a few specific things like vecorizing instead of loops that I really do need to know about).

Git demanding a large chuck of user mindspace isn't an advantage for git, it's a signal that git is bad and needs replacing.

Github already has centralised protections to do with who can and cannot do various things, and so do other similar systems like gitlab.

So nothing is really gained but not allowing this, but it makes git very user-hostile because mistakes cannot easily be undone.

That only works in some circumstances.

For example, suppose I init a new repo and accidentally commit my entire virtual environment, then push, then do some real work, push a few times more and then a colleague notices (after they have pulled, worked on and pushed) that the venv stuff is there.

In an ideal VCS, you would have a simple command like git purge /badfolder that would make it as if it never existed.

But AFAIK that doesn't exist, or at least the ways to accomplish that are pretty gnarly and dangerous.