I find this excuse depressing. We live in the age of computers. If you don't know how to use one you shouldn't be employed where they're necessary. Rather than making a dumbed down workforce we should be building people's skills up.

Git for normies already exists even MS Word has document versioning. If they cannot be bothered to use the software and technology they need to then they should be unemployed.

Current 3rd-year vet student here.

I think there are two principles at play here. First, I suspect that veterinarians that go into practice as a whole prefer physical manifestations of their intelligence rather than abstract intangible prizes. This is similar to my story of starting vet school after doing bioinformatics.

Second, computer tinkering is similar to shade-tree mechanicing. I drive a car. I even know how to change my oil and can look up how to replace the alternator if I need to. I don't get much satisfaction out of working on my car, though, so I outsource (when I can afford it) to allow me to focus my time on things that drive my professional life forward or are pleasurable.

Add to these that current vet medical records software sucks, and it leads to extreme impatience, and even an expectation that computers don't work, and the cycle continues.

I wouldn't necessarily agree with this. For example, I have seen consultants recommend using Git for document versioning in medical device development.

A lot comes down to timing. More and more law firm partners these days are digital natives who grew up using computers. They're accustomed to using really good software, and they expect the same in their workplace.

> By saving the versions of the files we sent for revision (think of the main branch), I could receive the version from other parties (kind of like feature branches), turn on Word changes, paste the complete content of the original, and we could visualize the difference.

IANAL, but this was a key step for me as well. If you maintain copies of the versions sent out (and modified copies sent back), you can always get a clean diff of the copy sent out versus the copy sent back, or of an earlier version versus a subsequent revision.

The compare/combine tools in Word aren't great, but they are functional. Kind of like a local maximum, I suppose.

> 60 year old partner who still makes hand edits and has the Secretary scan the pages and send them out of order to the associate

We've designed our product to be backwards compatible with existing workflows. It does not require every team member to use the product to add value. Partners who prefer their way of doing things can continue to do so allowing associates to add their drafts to Version Story to create redlines and consolidate changes.

>specialists edits get rejected because they don’t know the deal points and are just swooping in

The possibility of incorrectly rejecting specialists edits exists with or without Version Story. Our product makes it easier to understand what's changed so lawyers can exercise their judgement about these decisions.

> Third big flaw in the product: big law firms are the least innovative organizations on earth

I think this assumption is worth challenging. Millennials are becoming partners at law firms and are spearheading initiatives to update their tech stacks. This is reflected in legal tech budget growth trends (https://www.legalcurrent.com/tech-spending-remains-especiall...).

> Fourth big flaw in the product: having junior associates do menial tasks at $800-950/hr is a feature, not a bug, of law firm business model. So you are solving for something that the target customer doesn’t necessarily want solved.

Making mistakes is not a feature (https://newsletterhunt.com/emails/40489). In the example I outline in the essay, the lawyer made three separate mistakes when manually merging documents.

Regarding point 4 --

Sometimes you automate something because you want to do it faster / cheaper. Sometimes you automate something because you need it to be done _correctly_.

I would much rather my critical but menial $900/hr task be done by someone double-checking automated work than the same amount of time being spent doing the menial work.

You could even introduce flaws (in the review step) to catch if you're concerned about the human getting bored and just automatically mashing the "merge" button...

There was a freakonomics[1] podcast about mechanical support of human activities...

[1] https://freakonomics.com/podcast/new-technologies-always-sca...

I assume the fourth point is for billing clients for a high fee while paying a quarter to the associates. But some law firms will use the more efficient tools to take on more cases for the partners to bill on their higher rates. Competition will force the firms to use more efficient tools.

More "endless pains" then "endless gains" in all honesty. The point of software is to abstract complexity, not present it to users (or worse, create it).

LaTex is just ugly and surprising. People want to write and see what they've written, not type and then render. It's a backwards development workflow from the instant feedback of wysiwyg (which is why wysiwyg was so revolutionary, and became the de facto standard for the task).

The issue is "people who view themselves as good with computers" self-select into jobs in the technology industry. This means we don't have any ambassadors for technological process improvements in the average business.

How many developers use git? I'd bet there's a huge number of developers out there at non-tech companies who get by with numbered folders and emailing zip archives around.

To be fair, looking at a word doc with tracked changes enabled that has gone through a few rounds with more than a couple people in my Legal dept makes me feel like my brain is melting.

More specifically it’s built around the needs of Linux software developers.

In HTML, they should be using <del> instead, which denotes a portion of the text that was removed. If something is inserted, then <ins> should be used.

<strike> is deprecated.

This kind of notation is similar but not the same as redlining. Whoever reads the law actually wants `git history` in this case. The diff is not a means to an end (a fully edited document), having the diff explicit is the end goal.

I was tech editor on a book that used MS Word versioning. (One chapter per .docx because Word couldn't scale to anything longer). As you say, it was absolutely miserable.

it’s ridiculous that a document formatting app/format is used for creation and storage of documents. especially for official ones that follow strict formatting protocol. all data that satisfies the protocol is just a record! just pop a json into a template-engine and you’re go.

i’m so sad about the shithead influence of microsoft on our society.

Attorney here. Word tracking works just fine for my work and the work of pretty much every attorney I've ever interacted with.

Meanwhile, as another comment in this thread noted:

>Git is a tool built around the needs of software developers. Because git is too complicated and branching, though in principle, would make sense in some situations, is actually pretty difficult to manage (especially for binary documents).

Every alternative I've seen proposed, especially by non-lawyers, has been far too complicated for our needs and attempts to tackle problems that really aren't actual problems in real everyday practice.

It often seems like developers in this space speculate on theoretical problems they feel lawyers must face and create solutions a programmer would appreciate for those.

I really think Git should just add builtin support for binaries, and diffing for SQLite and .zip. it's not like it would be all that much code.

It doesn't really solve the problem of these formats not working well with collaboration and sync tools, but it would probably be good enough for some use cases.

you can also just have whatever tool extract docx or doc from its archive and then do the diff on that directory as it's just xml files.

If using git as the backend were an option, this problem would be hundreds of times easier to solve. Legal documents have a lot of complex formatting and include elements like tables, images, and footnotes. The diff function needs to handle all this, so it needs to be custom built from the ground up.

> Lawyers want this all to work in Word.docx

You've got some bleeding edge lawyers if they're using Microsoft Word. The legal industry is one of the main reasons that WordPerfect continues to exist.

> the abstraction of multiple branches where multiple people independently worked on things then merged them back together wasn't quite how most lawyers worked

This depends a lot on the practice. Transactional lawyers working in M&A and real estate encounter the issue of parallel drafts all the time. Personal injury lawyers tend to work in isolation and don't need all of git's functionality. Pretty much every lawyer redlines in some capacity, however, and benefit from visualizing a linear version history.

>And the other big thing was a network problem: a lawyer has to us microsoft office's version control because the opposing team is going to use it, so even if you use some better editor software it still has to be sent as a word file showing the tracked changes to the other side.

Yes, this is absolutely correct. This is one of the main things that keeps docx entrenched as the standard in legal collaboration. It would be an enormous faux-pas to send another lawyer a contract in an application that they're unfamiliar with. Backwards compatibility with their existing workflows is essential.

Also

https://decoded.legal/blog/2023/06/but-lawyers-know-nothing-...

https://news.ycombinator.com/item?id=36510439

https://news.ycombinator.com/item?id=13446275

(https://jduclos.com/notes/github-for-lawyers is dead but several versions can be found on Internet Archive)

https://news.ycombinator.com/item?id=24304399

I'm skeptic about testimonials like this. Users often don't know how to communicate what they need.

For example, "they always wanted to be using the latest version". Was that said _before_ or _after_ git was vaguely explained to them?

Maybe showing a working prototype has a different effect than explaining branches and commits.

> still has to be sent as a word file showing the tracked changes to the other side.

Dude spent a lot of time understanding docx. This sounds like a feature he could implement if he wanted to (Export changes to classic word...).

The complexity and risk of doing this would be astronomical and beyond the scope of anyone other than a highly-funded international working group with expertise in law and symbolic logic. It would take them decades to complete this, and in the meantime, the legal world would've left them behind.

Inherent in contracts are so many assumptions based on historical precedent, hacks to work around vagueness, etc. that to achieve this would require a rewrite of global legal systems, including centuries of case law.

Even getting a lawyer to change one word of a contract clause that's been in use for decades is a challenge (because to change anything would be to erase all known jurisprudence about that clause's interpretation, creating risk where formerly there was none).

But to upend the entire legal system to make contracts verifiable (which they could never be anyway thanks to the imprecision of human language) would be herculean.

EDIT: For example, consider the phrase "best effort." If you had to express that logically in order to make it verifiable, you'd have so much expensive negotiation about what "best effort" actually means. Presently, it's determined by a jury if there's a lawsuit in the future, where the jury relies on their own personal experience and expert testimony about the standard practices in that specific field.

This is not how common law (and likely other) legal systems work. You'd likely have better results with some kind of AI that has ingested all of case law.

Then why not write the contracts in prolog?

In case anyone was wondering: https://github.com/martinvonz/jj

jj has become my new favorite

Let me know if you'd like to try Version Story! I'm happy to add you to our whitelist.

The main reason people think that is because most of the MS Office suite's document formats are things that no programmer wants to touch if they can help it and usually when you're parsing them to something else, you can drop all the weirdness. Nobody loses sleep because the xlsx file you're using as an input for a script doesn't parse the excel graph that someone else put into it properly.

They're all incredibly capable formats (from a user perspective anyway), with the caveat that they're utter hell to work with in terms of a programming perspective. It's easier to just toss it into a black box parser/serializer and hope that all the text you need in/out comes out properly on the other side.

Actually generating docx or xlsx files (that aren't trivial) that look exactly like another input file (so you have to account for every notable difference in formatting) is a ton of work; most people who have touched webdev will probably at some point have had to format their emails for Outlooks half-assed ancient HTML parser and even there, you at least control what it's going to look like.

I think a lot of people unfamiliar with docx think of it as effectively the same thing as any other rich text format. Because of that, they assume converting it to other formats is trivial, not realizing that other formats support a small subset of the functionality docx does.

Definitely. Finance professionals, academic researchers, legislators, among many other professionals, encounter similar version control issues. We are currently focused on law because of our domain expertise and because the problem is particularly pronounced in the law.

This would be great in engineering for specifications and such. We have product lifecycle management software to track document revisions and handle approvals but it doesn't integrate with .docx files, it just stores them. You have to download files manually and diff them in Word or Beyond Compare for redlines.

JUST CONVERT THE PDF INTO A STRUCTURED SCHEMA AND THEN LAWYERS CAN BECOME PROGRAMMERS LIKE GOD INTENDED

Seconded. As the client on a recent commercial build, the “project management” software they used to manage docs and change orders was so bad it wasted hundreds of hours. Everybody agreed including all of he subcontractors but I was told “everything else in this space is actually much worse”.

Simple for a developer sure. Just have a look at what entrylevel developers do (no hate, everybody starts somewhere).

This group of people is willing and ready to learn but you still often hear "just checkout the project again" when a problem is encountered.

Most people just use an app and are fine with that functionality. My partner and I use a Google Keep list that is shared between our accounts. Live editing included and it does everything just fine.

There are more elaborate app solutions out there that do more and solve most of the problems.

Seems like overkill, especially considering I exclusively use todo lists on my phone, where I can download a free app and never have to think about rebasing and diffing.

After years of trialling a variety of notebook setups, I eventually fell back to vscode & git. I've even given up on Markdown (nothing wrong with it, I just realised I never actually view my own notes in parsed Markdown so I stopped bothering).

All I need is a file structure that I understand, and an editor for typing and searching :)

Git is great for (i) persistence, (ii) availability and (iii) the merge flow encourages me to review/clean changes before merging them to main.

It really depends on the firm and their existing approach to file storage. In legal, they call this a Document Management System (DMS). Some firms have a loose process, so they use this as a standalone app. Other law firms have 20+ years of files in their DMS, so they use this as an integrated feature.

The DMS providers have a great business and their product is stickier than glue. Fortunately, they are very startup friendly and have built out a whole app store ecosystem so other companies can layer on new capabilities that deepen the value of the DMS and make it even stickier.

Oh god, I'm getting flashbacks to my first internship, where just about the only thing I liked about WP was that there was a key chord for inserting a section symbol, while Word didn't have that. I think some older lawyers told me they thought the only reason they still were on WP was because of that.

I wish it was even harder, a Word document is a jumble of hidden formatting instructions that is impossible to troubleshoot.

That's the goal!

What are you talking about? The dude made a full complete UX tailored for lawyers that has nothing to do with git for developers.

Google Docs is a step in the right direction but has several limitations.

1. Lawyers don't want everyone holding the pen at the same time. Specialists want to make their changes and have them reviewed in isolation from other's changes. Think of a redline like a pull request. You don't want other people's changes in your work when it's getting reviewed.

2. Google Docs breaks down when even a single person drafts outside of it. See the section of my essay about why lawyers will never stop using Word. Even if you managed to get an entire firm using Google Docs, it still wouldn't work because they need to exchange drafts with external parties.

This must be a different google docs from the one I have to use. It sort of works if there's one primary writer and editor, and everyone is contributing small suggestions through that person, but it definitely doesn't work if there are two people modifying the same section of text.

Google docs IME is great for collaboration until the number of reviewers exceeds, say, 5 people and/or there's a need for extended conversation on parts of the text. For simple editing? Fantastic. Loved it. For a debate over, say, product requirements or licensing... not so great.

Which could have been an email, and they can take as long as they need or want. I would get flooded with GenZ video call requests because of various similar factors.

That's a great point. That's why we built it to work and add value even if the other guy has not been onboarded onto the system. This made the engineering lift way bigger, because the system needs to be able to accept and process whatever the other guy sent you. This makes it an open-ended problem, and we needed to be able to handle any possible edge case that the other guy's docs could introduce.

Juro and others make the other guy onboard because that limits the scope of the engineering problem. You can only create what the platform lets you create, so you know in advance what the system needs to handle. This approach makes it easier to build. But the problem is that it is really hard to get the other guy to onboard. As a result, your MVP is not really an MVP.

Our approach required way, way more engineering work up front. But it put us in a position where getting the other guy to onboard is a "nice to have", not a requirement.