That is an odd caveat to throw on the end. Sure, to avoid frameworks you have to know what you are doing. Is that really such an outrageous expectation?

Not really. Frameworks are usually created to avoid boilerplate and provide some nice scaffolding to support you while you’re coding the business layer. And a lot of them do smooth over accidental complexity, even though the architecture is generic and may hinder you in the future.

But the learning curve still exist, as most of what you interact with is custome codes, modules and components.

Yes, absolutely, and it goes back farther than criminals. Why do you think everyone's grandma has a jewelry collection, while less of the youth do? Because before the 70s, women were not allowed to have their own bank accounts. Their gold and jewelry was the only type of wealth they could keep for themselves.

The other reason is the Christian historically yes-and-no relationship with usury (banking).

And even if that didn't turn me off as a potential customer, I'd be seriously questioning whether I want to hire someone who claims to be a designer, when they didn't even put together a design for their own site that effectively tells me who they are.

Basically, I think you are too close to your own site design to see just how flawed it is. Sorry is that sounds harsh. But I'd re-do your entire approach. Don't put up a portfolio and then try to add commentary at the bottom - put up a easy-to-read, concise explanation of what problems you can solve for people. In this scenario, you are the product, and you need to market yourself just like any other product - tell people right off the bat why you will improve their life. If you don't do that, the portfolio is meaningless.

I'm thinking back to when I was in band as a kid, and the idea of having to recognize tiny number inside the notes seems to make it more difficult to read, not easier. Even if not trying to read them, the visual is noisier.

Is the idea it offers help to new musicians, but experienced musicians can ignore it? Someone good enough to sight-read sheet music can disregard the new noise?

The funny thing is that the document authors like these ways of working. It is the tech people who don't. I've seen "Git for Word" proposed many times a year for a while now. And all of the ideas are interesting, but none of them appeal to my audience because they don't care about git's feature set. Nobody wants to branch and merge. Nobody wants a straight version history. ("Nobody" meaning nobody in my market, not nobody in the world.)

They want a storytelling experience. They want to know the why, not the what. And the workflow tends to be unidirectional, not with collaborative changes coming back together, but with expanding changes as each person adds their ideas and makes change for a specific instance of using a document. The experience we build for them bring in pieces of version history, pieces of comments, pieces of telling the story of why something was done, so people down the line can have more context to decide whether to accept or reject the changes.

It isn't that "Git for Word" is a bad idea - on the contrary, it would be great if someone pulls it off. My point is that building something that improves on Word isn't actually about the software, it is about the document workflows. If you find groups who work like software devs do, where documents receive small updates from a team, and bring all changes together for a final product, there is probably a market. But when evaluating such ideas, there has to be a reality check of whether the actual use of the documents truly matches the use case for git.

When I worked as a VFX freelancer I was amazed at the number of hours (=money) burned by marketing agencies who didn't manage to give me the definitive variant for a simple list of things they wanted. In one instance they gave me everything they had, including crude and unrecognisable filenames, hints about things that I should ignore via telephone etc. I had to make sense of it and compile a list which I sent them to approve. They ended up approving another list (!) which they themselves sent me two weeks prior and they only managed to correct this once I hinted at this.

Of course this is a example of saw qhow things should never be. This usually involves somebody getting sick and some uninformed person taking over etc. But what I learned on film sets is that you should choose the defaults of your communication culture in such a way, that it works under the absolute worst conditions (bad weather, hungry, stressed, confused, etc).

And I have seen so many organisations fail at precisely that. If you get I'll someone else should be able to take over without heading to an oracle. This is not a special function limited to a version control workflow, it is something that has to do with clear communication.

Using git can sometimes help avoiding the whole problem by making it obvious which file is the latest and which is a variant of it, the people using it will have to use clear communication as well (e.g. by writing good commit messages, choosing the "right" commit sizes, naming things the right way etc). So if you know how to use git, you just might value clear communications a little bit more than the average person.

As git is a distributed system I think it’s not at all clear what the definitive final variant might be —- and that is a strength.

That can be handled externally to git via ad hoc convention, say by using a system like gitlab or github and letting it declare one as “primary”, or by having someone post to a mailing list (“Commit X on a repo you can reach at URI Y is the official release”) both of which are common.

But in your example various people could mail you commits and not have any consensus on which is authoritative.

The defaults are sensible. Throw money at it and pay someone enough to sort things out and get it done, e.g. you as a freelancer get a data dump and ask the right question and the problem is solved. Sure it costs money. But everything costs money.

Git works great among peers. But most organizations are hierarchical. And the boss doesn't have to give a shit about which draft is the latest because the boss is the boss.

As a boss myself I have to say: I totally give a shit. Salaries are my company’s #1 expense by a wide margin. I don’t want my staff spending their time manually merging docs received via email when there are much better solutions out there. I hire people because they are smart and can get shit done that makes money, not because I want servants.

This is the killer app for Office 365 and google docs: stop wasting time emailing shit around, one canonical version even outside of company walls.

some would say whoever solves that problems is filthy rich

As a lawyer I can full confirm that our industry works as you have described (as regards documents workflows), and with my tech background I can also confirm that most features of dev-oriented solutions like git are mostly uninteresting from a lawyer's perspective.

I agree with both comments.

To add, in large-scale corporate/commercial practice (which is the area which I practised), Git would be useful in replacing email-based collaboration, but the switching costs seem too high.

Currently, the corporate law contract negotiation workflow is as follows:

1. a party adds their tracked changes to a Word document based on a template contract;

2. the party emails this document to party B;

3. party B reads the changes, may discuss the changes with their client, adds their tracked changes, and then emails the updated document to party A.

This process repeats for every document, punctuated by occasional conference calls between the parties, until the parties agree.

‘Git for law’ would be useful for lawyers in increasing efficiency - and thus reducing costs for clients.

However, the benefits for law firms of adopting a new Git-based workflow are likely to seem relatively small to lawyers. Their current email-based version control system is messy and time-inefficient, but generally functions with minimal error.

On this basis, I would predict that most corporate law firms would be very slow to adopt a Git-based system - the benefits may not justify the costs.

One should also note that lawyers, particularly contract/commercial lawyers, are conservative by profession. In my experience, most lawyers are very slow to adopt new technologies, highly risk-averse, and skilled at spotting risks. The combination of these traits means that any technology will have to offer a very high benefit to replace an existing legal workflow.

One very large problem that typically comes up in large teams: Only 1 team member can edit the the "live version" of a document (it's locked for editing by the version control system), the other team members need to work "offline" and then reintegrate their changes/drafts into the main document. Everybody has lived through the horror story of a team member in the different time zone still having checked out the live version and going to sleep :)

Sometimes you have to circulate a draft document in parallel to multiple parties (e.g. colleagues with special subject expertise + client's inhouse lawyers + client's technical experts + other party's law firm + other party's inhouse lawyers + other party's technical experts). It can happen that you need to reintegrate comments from different parties to different versions of the drafts, e.g., if your client gives feedback quickly and you re-circulate updated version internally, then you receive other party's comments to the older draft version...

Besides the mechanical aspects of reintegrating comments, it is also difficult to track if everybody who needs to sign off has actually signed off on the parts of the documents they had to review. Often it gets lost who made which comment/change. It can be quite awkward if a regulator asks you "Isn't the technical statement on page 12 contradicted by fact XYZ" - please explain until tomorrow - and you have to quickly figure out who actually put that in...

m@replace-with-my-username.com

Would be much appreciated!

Also is there anything that actually guarantees that the tracked changes were the only changes made? I haven't seen this but it seems like a serious flaw in the process.

Also what if you get an intern to do some of the work, then you want to review the changes between version:$lastyousaw and version:$current. IIUC the mail with tracked changes only allows you to view one "patch" at a time.

The mail allows you to see all patches, sometimes 'clean slate' is done by accepting all changes. While this sounds like a problem in theory, in practise its not.

I agree that things can be better somehow, but it is really difficult to see any solution which is at least 10% better. The current workflow also has the advantages: - data is as safe as your filesystem and email system together - Word file is generally not considered a vendor lock-in - everybody understands the workflow - nobody can block the workflow (like not checking in again with sharepoint)

Git was originally designed on an email based workflow for software development (hence the commands am, format-patch and send-email).

For contract negotiation, if the template contract was in plain text, then it could be emailed as a patch. The party would then apply that contract to their local git repository, make the changes and email the diff from the original template back to the first party.

So essentially, you could still use email, but have the diff between changes as the content in those emails (along with inline comments).

Unfortunately, corporate Outlook/O365 based email systems don't work very well when used in that fashion.

m@replace-with-my-username.com

I never trust the received file's "track changes", always compare to the latest version I've sent -- and it is extremely common to find a change that wasn't mentioned/discussed, and somehow magically "accepted" or otherwise not tracked in the other side's "track changes". Whenever I point these out, I always got a "oh, yes, forgot about that one", or "I didn't intend to put that in" or "I'm not sure why it didn't appear in the track-changes view" -- but out of tens of these (with multiple lawyers over multiple years), not one was ever in my favor.

Branching might not be as interesting on a single project - but diffing is, very much; and I'm sure it's not more coveted mostly because most lawyers either (a) don't realize how good it makes life for you when you can diff and blame easily, or (b) are abusing the fact that it is so hard to diff/blame on documents, and certainly (c) usually charge by the hour, so some efficiencies are actually going to cost them money if they implement them (a famous Upton Sinclair quote comes to mind).

IMHO this is a useful "feature" for lawyers. Don't forget that usually lawyers of two parties are working"together" only apparently, when in fact they are always litigating for their client's best interest.

The goal is not to reach a common agreement, but to reach the agreement that best serves the interest of one's client, most of the times at the expenses of the other party.

This is achieved in many ways, one being having text in a contract that the other party is not fully aware of, either because it's not properly understood or noticed.

This means that including in a document text without the other party noticing is a good old trick that quite valuable to any lawyer.

As a lawyer my position on this is that it's the other party to blame if it did not check the document properly (I always compare the documents for differences even when sent with revisions).

> (c) usually charge by the hour, so some efficiencies are actually going to cost them money if they implement them

I tend to disagree with this line of thought. Lawyers have a thousand ways to inflate their timesheets. Using a tool that makes their life more miserable by forcing them to do manual work that could be automated is certainly not one of them.

As a non-lawyer, this is why they say "the problem with lawyers is that 95% of them give the rest of them a bad name". And as I mentioned, I also always compare.

> Lawyers have a thousand ways to inflate their timesheets. Using a tool that makes their life more miserable by forcing them to do manual work that could be automated is certainly not one of them.

I agree, and they do inflate them regularly -- all lawyers I asked to draft NDAs and employment agreements for me charged a few hours worth for the first one "because they had to write it" even though it was unchanged from another client (for sure; I've seen that exact one before).

Still, they need to keep an air of "being busy" and "working hard", and the best way to do that is to occasionally work hard.

m@replace-with-my-username.com

Exactly like you've hinted, the right way to crack this is to bring a full-fledged word processor like Google Docs, but instead of ad-hoc realtime collaborations the software has to enable customizable unidirectional document workflows with controlled collaboration.

Most serious document creators don't want to branch and merge, instead they want to pass on the document through a series of stages. They want statistics on when, what and why of each stage. And at any point of time the document is in one definitive stage not scattered across emails/folders/versions/forks.

https://support.google.com/a/answer/9381067?hl=en

Unlike its normal collaboration mode, the file gets locked down.

It allows multiple people to work in parallel (and in private). When somebody sends a pull-request eventually, they are presenting a story of changes that they want to get into the document and people can discuss them and approve them individually. (Of course, git the tool isn't necessarily suitable for non-technical people, but git-the-workflow seems to be a good foundation.)

Could you elaborate on what such a tool could look like without git style branching?

I don't know, I'm just spitballing. Sounds like it'd be fun for awhile to attempt to seamlessly get this into the workflow and see how it's accepted.

I think it's more about the user interface. The user interface of Git is essentially what programmers already do - code.

It is _their clients_ who don't, not just tech people. I hired lawyers a few times. IMO their redline and email workflow is error-prone craziness that could use improvement. That said, I'm a "tech" person, so I might be biased.

I've spent many years in 'collaborative writing' in R&D, mainly grant proposals and joint reports/deliverables, most in the CS/IT domains. Writing those texts is very different from writing the software.

First thing you should realize is there are no 'tests', and all the 'code' is usually in a single big file. Anyone that has touched the document can have potentially messed up everything, both content, layouts and meta-data, and there is no automatic way to check whether it still makes sense. Many times people will not use the agreed upon editor/version, and sometime (often) that means a boatload of minor edits to the document all over the place just from opening and saving. Imagine everyone in your software team using different editors all with their preferred coding conventions that are automatically applied to the whole project at load.

From this you can deduce the enormous responsibility of ownership and gate-keeping in the workflow. The absolute worst collaborations I have been part of were those that somehow believed that if they used a collaborative document editing facility, wikis or Google docs for instance, that would negate the need for assigned owners/editors. Those tug-of-war shitstorms got exponential the closer one came to the submission deadline (technically incorrect, i know, but you know what I mean).

Some tips:

- Have well defined ownership for each section or part of your document. The owner receives and makes all changes for that part.

- have a final editor that is responsible for the complete document receiving the changes of the parts from their owners only.

- Do not trust 'track changes', but use Word's built in document compare if you are the final editor. For complex formatted documents (nearly all instances require you use an insanely styled template, you 'clean room' import (C/P through notepad) the text changes into the correctly formatted doc under your control.

- release the current trunk document often, ideally once per day. This requires staggering, with subeditors closing submission windows and submitting their updates to the main editor before EoB. Everyone editing should work against the latest release.

-Every version published by the final editor should be immutable. Mail it to everyone if needed, but if you use a link to some sort of repository make sure it is a deep link to a version that can not be updated in the repository, or hilarity will ensue.

- use versioning in the filename. filename_YYYYMMDD_HHMM_dXXX_rNN.docx where XXX is the assigned party acronym for the person making the update. 'YYYYMMDD_HHMM' is only touched by the editor, 'dXXX_rNN' is the NN'ed changes release by part XXX against version YYYYMMDD_HHMM .

Most certainly Git can function as a repository, but there will be people that will not work with it (nor any other repository) so always assume mail interactions as well.

Finally, there should be a special place in hell for the people that designed SharePoint versioning. Don't even think of going there.

HN Guidelines: https://news.ycombinator.com/newsguidelines.html

Specifically: "please use the original title, unless it is misleading or linkbait; don't editorialize."

Even the article is specific in that it is just reporting on something Trump said. And even Trump did not say it made people an enemy of the US, it said it made people an enemy of his White House.

I find that take interesting. I use Pandora to this day as my primary streaming source, as it has my vibes down perfectly, and no other services has that many years of training into what I like to listen to. But even more important, it is almost always the music source I see when I'm restaurants. I prefer small mom-and-pop type places, so maybe I'm only seeing a niche.

I'm not trying to argue it is a leading platform, as it clearly is not. But it is fascinating that people searching for music don't check what was a leading platform 10 years ago. Especially when the music in question is older than that. And the search started when it was a leading platform.

Actually that last point really confuses me - why would today's platform popularity have limited the search 15 years ago? That part of the story makes little sense. If this search began back when Pandora was at its peak, why wouldn't they have started from there long ago?

And the answer was right there on the original platform, invisible to even he who found it there in the first place.

For all the power of search engines and AI it was the author’s memory that finally unlocked the mystery.

This says SO MUCH about how our society has come to rely on this technology and it has so many blind spots it can’t find something that is still online and untouched for over a decade.

We can literally dig up artifacts from thousands of years ago and learn how people lived back then, but in ten years we will have forgotten everything we did while we are still here and the resources are still online. Just rotting out in the open ignored and one day gone forever with no way to recover it.

Insane

It felt like it suggested songs that have something in common with other songs you liked, while Spotify feels like it suggests songs that are popular with users who listened to the same songs as you did.

I wish it had taken off instead.

My understanding was that re-invention without copying any code is legal. But scraping code from the browser and re-using it is not. I'd love to know how that plays in the courts with LLMs, as their entire model comes from copying code as training material, not writing new code from scratch.

Regular humans train on copying code too (Stack Overflow, etc.) so unless they were trained on that specific codebase, I really doubt you have any sort of legal standing. And given how little compensation the authors got when their work got trained on, I wouldn't hold out hope for a big payout even then...