I'm in my mid-40s and have severe ADHD and I've tried many many techniques and systems over the years. Over the last ~15 years I've come to evolve a set of systems that work for me.
I'm starting (in my "ample free time") to document them and in a series blog posts help people find systems that will work for them. My experience is that the best systems are the ones that have five characteristics:
1. They're simple
No complex patterns, no "we'll solve everything"
2. They require little or no task switching in the middle
This breaks my ADHD concentration.
3. They're forgiving if you fall off the wagon
You will always have bad days and need to restart. The system must make it easy.
4. The system must be very general, maybe even "too simple" but easy to customize.
There is a natural desire, especially in ADHD people, to over complicate, so the system must allow you to be as simple as possible, but then let you customize later.
5. They don't require any specialized tool (especially not an online tool). No system should be invariably tied to a specific piece of software or hardware. These may be excellent augmentations, but they should never be requirements.
Am I an "organized" person? No, but I'm far better organized than I was. Tasks rarely get missed now. I'm far more productive than I was (and I have stats to back up my assertion). I can almost always retrieve documents I need relatively quickly.
These systems won't change who you are, but they will assist you in being better at being who you are.
Your principles mirror my own, which have been developed and refined over the last ten years (I'm 34 now). There have been periods of overcomplicating things, but they've mostly reached a natural state that works for me.
Maybe interesting is the evolution of my system:
• 2015 and prior: Sticky notes, calendars, notebooks, sheets of paper, chaos
• 2016-2019: I found the bullet journal method and implemented the most basic form found here: https://bulletjournal.com/blogs/faq (collections, future log, monthly log, daily log) and never really evolved from that utilitarian mode.
• 2019-2025: I signed up for Notion and ported my bullet journal system there. I miss the physical version, but prefer the easy access and easy editing in the online version. In addition to Notion, I heavily use Google Calendar, and also Google Keep as a quicker-access and catch-all of smaller notes. I use Notion for life admin and Obsidian for work notes and files.
OP's Johnny.Decimal system caught my attention since I've been interested in a consistent and proven way to organize the files on my laptop, SSDs, Drive, as well as all my physical docs. I could also see it being a nice way to organize my Notion and Obsidian, but I also tend to rely on search and backlinking as others have commented about for their own systems.
I just wrote a sibling comment echoing essentially the same philosophy, although you've elucidated the principles in more detail. As I wrote, my system is basically use a paper filing system (don't overthink it, just alphabetically ordered, labeled manila files), Google Calendar, Google Drive, and Obsidian on my phone for miscellaneous note-taking.
I'm eager to learn more about your systems. Where's your blog?
I originally started with Johnny.Decimal for my life and after giving it a big try, switched to PARA.
J.D is fine (maybe even great) if your categories are relatively static, such as a small business, but as an individual, I found it very restrictive and challenging to remember. Moreover, while the decimals are cool, I found them somewhat irrelevant if I was the only one referencing them.
J.D is optimized for retrieval, where what I needed was optimized storage, and then occasional retrial.
To each their own of course, and using any system is better than none.
I would like to add that this is probably not deceptive advertising. At least not intentional deceptive as many people including me didn't know that CC licenses are not meant for software and is not considered open source. I don't know if it is common misunderstanding or not but I think there is strong case to say that some people intuitively would think so.
I think the license choice is great. It allows noncommercial use, modification, and redistribution. It’s not “open source” according to the champions of the term (since it violates the use-for-any-purpose requirement) but I’m a huge fan of this license and license several of my projects CC-NC-BY where AGPL would be too heavy-handed.
"It's not recognized as Open Source by the Open Source body, and doesn't meet the criteria of Free/Open Source Software, but is Open Source" is a bit like saying "I used GMO and petroleum based pesticides, but my produce is all organic."
Why should words like "organic" in relation to food mean without pesticides? I mean all carbon and water based life forms are organic, right?
I can define Open Source easily, using the OSI definition.
There is not a trademark for Open Source because they failed to secure the trademark, but we have decades of use for the term meaning something specific.
It might not be, but I can't understand how someone who has written such advanced software, and includes a monetization plan, and then posts about it on HN also doesn't take the time to choose a license.
Even if they didn't know CC wasn't suitable for software, everyone knows that non-commercial isn't Open Source.
I didn't dig into the software, but I wonder if the licenses for the dependencies allow this either, eg if any are GPL or similar.
This is wrong. CC is perfectly fine for software in some cases, such as here.
Ok, CC is not tailored specifically for software, thus the general advice "you should use something else" but I do not see why CC would not be suitable here to achieve OP's goals.
Unlike software-specific licenses, CC licenses do
not contain specific terms about the distribution
of source code, which is often important to ensuring
the free reuse and modifiability of software.
Many software licenses also address patent rights,
which are important to software but may not be
applicable to other copyrightable works. Additionally,
our licenses are currently not compatible with the
major software licenses, so it would be difficult to
integrate CC-licensed work with other free software.
Existing software licenses were designed specifically
for use with software and offer a similar set of
rights to the Creative Commons licenses.
Software licenses, especially the more "advanced" licences such as the GPL, MPL, and others include very specific language around the issue of what is use, what is distribution, what is is connecting to, derived works, and importantly, around patents.
The CC licenses do an amazing job when it comes to artistic work such as books, movies, music, etc. but you don't have the same issues there, and that's why even CC says that they don't recommend using them for software.
As someone developing CC0-licensed software, this had me a bit shook, so let me highlight that your link does clarify that CC0 licenses are fine for software and are entirely separate from other CC licenses.
> And non-commercial licenses are not Open Source, period. This has been well established since the 1990s, both by the FSF and the OSI.
That may be a bit misleading - the Free Software Foundation has long held strong opinions about the phrase 'open source'.[0]
IIRC 'open source' became formalised by the OSI around 1998 - and despite the stated intent to clarify things where arguably no clarification was needed (a lot of people felt it was not too onerous to explain the beer and speech, libre and gratis, concepts to novices) it continues to reduce clarity. Viz.
Ok, a non-commercial Creative Common license is not "OSI-open source" or "FSF-open source", but it is technically "open source". The source is open.
The open source societal movement is much broader than the narrow definition given by OSI or FSF.
OP, your tool is perfectly fine with a non-commercial creative common license. The fact that CC licenses are not specific for software does not imply it is a bad choice for software.
Here I find it is a very appropriate license for OP's needs : he wants to open the source code, but prevent that someone else takes it and makes money with it under another name.
This is totally fine.
Then say source available, not open source, because the latter connotes the freedoms as mentioned in the OSI definition, for most people who use that phrase.
Let's not redefine words based on what you personally think is correct when people en masse have been using them to mean a certain specific concept. It does not have to be trademarked, it can have a de facto meaning that everyone generally understands to be what it means.
That's because "open source" is a bad name, since it only focuses on source code availability rather than three other essential freedoms. "Free/libre software" always made more sense, but "open source" got significantly more popular.
While it's absolutely true that businesses need to make money, the idea that this must therefore logically conclude with a FLOSS and non-FLOSS version is not correct.
If you look at companies like Red Hat, and Nextcloud, neither of these companies sold proprietary versions of their software. Red Hat sold licensed versions of their software, but they were always FLOSS.
Nextcloud's CEO talks about how selling a proprietary version of your code is bad for your customers and puts your company into a Catch 22 with itself. "Do we add this feature to the 'Community' or 'Enterprise' version?" or worse "What do we do when someone makes a FLOSS plugin that competes or is better than our internal version of the same functionality?"
There's a huge need for a good chat system to compete with the likes of Slack, but Matrix has bitten me several times and I don't trust it. In an alternate universe, they could have made Matrix work well for all levels of users and then sold customization and B2B deals with their customers leveraging the community, which has always wanted Matrix to succeed.
Would you be able to point me to the talk or blogpost of nextcloud that talks about their business model in detail?
I would be very interested in how it works in practice, how they differentiate with their enterprise versions and so on.
I agree that their business model sounds like having the best of both worlds, so any material on the details that you could share would help me a lot figuring out how to replicate it for other solutions.
The feature exist in both versions but you pay for additional capacity which is not what they are talking about when they said deciding whether the feature should be in community or enterprise.
If you look up Frank Karlitschek and "I forked my own project and my own company", he's given this talk many, many times.
As for it being the best of both worlds, it depends what best means.
A company that wants to make a lot of money won't do well with this model. It's a slow growth model requiring a lot of hands on work that requires customers who are paying for features and custom installations.
It's labor intensive work that's quite the opposite of the proprietary software model, which has traditionally had a lot in common with the publishing or entertainment industry. Write a book, get paid for it for years.
I think the only reason Red Hat’s model works for them is that Linux distributions are obviously massive sprawling complex things, and maintaining LTS distros which you then sell support for is an incredibly complex and valuable thing that no intermediary can plausibly claim they can do. Even if the underlying code happens to be FOSS.
Matrix servers (and web servers and mail servers etc) are not as complex - and if anything you want incentives to make them less complex, not more. And the better job you do of making them easy to admin and support (ie the more scalable and stable they are), the less reason there is to pay the upstream for support but some system integrator instead.
> Linux distributions are obviously massive sprawling complex things
Just my perspective but I think this was also perhaps a product of the time when Red Hat really started growing, back when linux was a little more rough around the edges. These days it seems linux has enough polish that some (many?) corporations are happy to just use off the shelf ubuntu and call it a day and hope nothing breaks too badly.
I think another thing that has changed is that big business is less suspicious of open source and are less likely to feel that all the software they use has to be licensed from someone.
I think it has dawned on people that it is impossible to avoid using open source.
This is definitely true. It’s also completely normalised to build a large commercial service on open source and not even contemplate if or how the upstream project is funded, or consider funding the upstream a serious cost.
[0] has many more details but CentOS was never a drop in replacement and the new CentOS model is a big improvement for anyone wanting drop in replacements. I agree with everything else you said though, they were independent of IBM for nearly 3 decades and always were and still remain among the most active linux contributors (just see any of LWN's development statistics articles).
Zulip is excellent for geeks. I don't think it's for the broad public. We use it in our company with great success, but our marketing people still have not understood how topics are used (both by their own comments and by the evidence I see regularly).
Topics only help to keep things organized and better than other chat systems if they are reusable and long-term identifiable. If people create a new topic like e.g. "Wednesday meeting" or "The printer does not work" every time they want to say something you end up with same mess as in other chat systems. Also it's quite human that discussions get offtopic. Zulip has nice support to continue in or move the discussion to the right place. But to my experience only a couple of geeks uses them.
Yes, and even if it doesn't go to court, the university will know that it will cost them time and money.
It's entirely possible that university president or higher administration is unaware of the situation, and if they were, will intervene. The best way to do that is to have it brought to their attention via a legal letter, which then means they need to bring in their lawyers.
A good lawyer for the university won't want to fight because fighting is not in the best interest of the university. A good lawyer will say "We threatened the student with this? No good can come of that... let him register, let him graduate and make this all go away."
That doesn't mean the client (the university) will take it, but overall fighting isn't in their interest either.
You have invested years of time and presumably thousands of dollars into your schooling. Their threat that they will not allow you to graduate unless you give them unpaid labor without a clear boundary condition is a threat. While I haven't seen the correspondence, from what you said it appears they're doing the moral equivalent of one of those sitcom situations where someone is compelled to do what the other person wants under a threat, and even when they've done it, the threatening person keeps the threat.
A good lawyer (and not all lawyers are good) will help you understand your rights and your position.
As others have said, this is not an escalation of aggression, and not only don't you have to tell them whether you've seen a lawyer, unless the lawyer is speaking on your behalf- you don't have to tell them anything, and you shouldn't tell them, or tell us (in case they read this, which they likely will).
A lawyer in this case is more of a scholarly resource, telling you what your options are.
To add to that: it is understandable to expect and hope for the other party to behave rationally. But there is a power imbalance that the other party is exploiting and for all we know intends to continue.
Also not a lawyer, but discussed this with multiple lawyers. As long as you make very clear that you're summarizing the legal document, but the legal document you're providing is the canonical truth, you're allowed to provide those kind of summaries.
For example, Creative Commons has a visual/bullet point explanation of their licenses. That's entirely okay, as the legal text is the core license.
I had a similar discussion with a lawyer once about a TOS that also included a summary. The lawyer told me that as long as you make it clear that your summary is just a summary, and is not the agreement, and you point out the actual agreement, you're okay.
In this case, the OP is pointing to the legal text clearly and merely summarizing it's most salient points.
I remember in the late 90s when there were so many alternative interfaces for PCs. It was a great time for exploration on what could be done.
Kando is very pretty, and it can be fun to use an interface like this, but in terms of practicality, text inputs are better.
For example, on my desktop, there's an icon on my taskbar for Firefox, but most of the time, I get my screen to the search bar and type "F" and my system knows I probably want Firefox. Done.
There's a game I play, Astroneer, and it uses a pie interface. I often wish I could just type in what I want. It'd be faster.
I want to love this, but I can type on a keyboard so much faster, and use up so much less cognitive energy doing so than switching my hand to the mouse, pulling up a menu, reading the symbols (even if I have their location memorized) and pulling my wrist/arm in the right direction.
If you have both hands at your keyboard, that's 100% true. However, it really works well with workflows which rely on mouse, stylus, touch, or controller input.
Especially when used for "creative" or "artistic" tasks (e.g. painting, video editing, 3D modelling, etc.) pie menus can really have a benefit because you have your hand at the stylus or at the mouse most of the time anyways.
Kando looks incredible - congrats! And I can see how it works well for the use cases you described. Maybe it would be possible to add keyboard support? One could use left and right arrow keys to highlight an item and the up arrow key to select it.
Radial menus never worked for me with a mouse pointer, even though I like(d) the idea in theory. It’s somehow easier to reliably hit traditional rectangular menu items arranged linearly, then some wedge in an angle.
I agree, but I also really like the pie menus. Personally, I'd like the ability to simply write to match, but otherwise working as demonstrated. E.g. like the Windows search works when you've hidden the search bar. I'd prefer both, in other words.
ideally you have a button on your mouse to summon this, and use it when you are already using your mouse, and summon a different interface for typing from your keyboard, when your hands are there
I don't know, I just use FDE because I don't trust filesystem level encryption to protect against the many side channel attacks one can inject into a running system. LUKS is good enough for me.
I remember plenty of people who used SVN saying why did they need to use git. In fact, I remember companies complaining about distributed version control generally, saying they preferred centralized version control.
If it works for you, you can keep using it. No one will stop you, but you may find that just as SVN users have largely shrunk down, maybe the same will happen with git.
2. jj today
I use jj today and the biggest advantages for me are not needing to worry as much about the order of operations.
I write some code and then I come across a bug. I can pull out the bug and fix it while still working on my existing code. I don't have to go back in time to fix it.
I also appreciate not needing to stop just because of a conflict. This is something I miss from SVN, which was similar-ish in that conflicts didn't need to be addressed immediately, only jj's implementation is better.
Generally I find the jj workflow to be something that takes a few days of adjustment, then it just makes more sense.
3. The way things will be
jj is still relatively early. The commands to interact with git aren't all very intuitive or easy to use. I had to make some aliases to make this easier. More importantly, there's no jj backend yet. Once that happens and it's adopted by forgjo or another forge (Gitlab, Github), I think we'll see a big shift towards it.
I think git is going to be around a long time, but the day to day use of jj is so much nicer than git that I hope it will gain fast adoption.
> I remember plenty of people who used SVN saying why did they need to use git
I remember everyone saying “SVN is a piece of shit, I hate it, why can’t I easily create branches.” Also mixed revisions which was the worst part of it.
The jj people should really write a guide to show how it’s better than git because, so far, I’m still very confused and we’ve had that conversation on HN at least 10 times without anyone giving concrete examples.
For me, jj is better than git because it has achieved something of a holy grail: it is both simpler and more powerful, at the same time. It achieves this by having more cohesive primitives.
Take the index. I love(d) git’s index. It is a powerful way to build up focused commits. Jj does away with the index, yet gives you equivalent power. How? Because instead of a separate index concept, jj has a special name for a commit representing the index: @. Files are (by default) automatically tracked and included in @. Just like how you’d git add -p, you create a new commit for your work, then create a commit on top of it. As you work, @ gets built up with your code, and when you’re ready, jj squash (with various flags or paths to control exactly what gets added) to move them into your parent, “real” work commit.
So if it’s the same, why is it better? Because we’ve reduced the number of states: instead of dirty, staged, and committed, you just have committed. And with that, commands are simpler: no distinction between —hard or —soft for something like git reset, everything just operates on committed state. This means you can bring the full set of tools to manipulate commits to bear on your index!
The same goes with stashing: because heads are allowed to be detached, to use the git terminology, we don’t need a special stash concept: create a new commit that’s forward of where you’re working to “stash” your changes in there until you need them.
These are two simple examples, but it’s really about how everything fits together into an extremely powerful and cohesive tool.
And I remember everyone saying that git is confusing, that they get into states that they don’t understand and have to blow their local changes away, and that they have completely fucked their local copy more than once.
I’ll give you some concrete advantages:
1. Every time you run a `jj` command a snapshot of your local changes is made. I don’t know about you but often while I’m working on something experimental I have an idea for a slightly different approach, try it out, it doesn’t pan out, and I’m like fuck I wish I’d saved where I was an hour ago. git won’t do that for you but jj will.
2. The rebase workflow is dramatically better. Rebasing multiple commits with conflicts is excruciating. You have to fix it right here and right now but you’re in a weird repo state where you can’t easily to another commit and tweak it or look at the state of things at different times. It’s a pain in the ass and easy to get wrong. With jj there are no weird intermediate rebase states. Rebasing always succeeds and if there are conflicts you’re able to address them just by editing your changes as you would in any other situation.
3. I don’t have to make WIP commits or stash when switching between lines of work and I don’t have to remember to undo them when I come back. Your work is always committed. Stashing doesn’t need to exist any more and as a result I never have to worry about conflicts when unstashing. I never have to realize I’ve forgotten work that was stashed.
4. Named branches don’t follow you automatically. This is huge if you ever have to do some linear work that involves multiple PRs that have to be merged and deployed one by one by one. With git you have to make branch after branch after branch. And god help you if one of the earlier lines of work needs to be changed, now you have to rebase all the descendants. With jj all this work is linear. If you have to edit an earlier commit or insert a new commit inbetween two, it’s trivial.
5. And the real killer feature? I get to have all this and nobody on my team needed to change a thing for themselves.
I was a git expert. I’ve used it since before GitHub. I’ve written a barebones implementation of git from scratch. I was the guy everyone came to when they got stuck. I gave talks on git to my local language user meetup. And I will never need to touch it again.
> Every time you run a `jj` command a snapshot of your local changes is made.
I think that's going to be pretty divisive. For projects where your input is here, your output is there, and that's that I imagine it's fine. Getting people to implement one of the workarounds to avoid junking up the repo feels like a huge ask.
I’ve found most modern codebase have good gitignore discipline, but it’s true that there are codebases that are not. There are also some tools that by default write files to the current directory.
The auto add feature is configurable these days though, so if you don’t like it, you can turn it off.
Auto-adding your changes to existing files sounds like a great feature, auto-adding any random files it finds in the project is a terrible one. I can't imagine why the author decided that was a good idea. Can someone explain the reasoning behind it? I can understand someone wanting it as some point so it makes a certain amount of sense to add as an option, but not as the default. Makes me wonder about what other bad decisions have gone into the project.
I'm a bit more than skeptical. Right now, for a project at work, looking at files in the repo (for testing, etc) I have 294 files untracked and 10 ignored. Using jj all but the ignored files would be committed to the repo and I'd have to something akin to git's filter-branch to clean them out again to avoid that bloat.
I guess I should ask... is that final step made super easy? That is does jj make it easy to completely remove all traces from the repo of those auto-added files (like filter-branch)?
You live with those files showing up as untracked because it was easy and convenient to do so with git.
If git auto-added them from the get go, you would have used a pattern in your personal or project gitignore to skip them, or you would have put them into an ignored tmpdir, or you would keep them on a separate branch if you intend to make them part of the repo. None of these steps would have felt painful or out of place. You see files you don’t intend to include in `jj status` and you’d do whatever is appropriate to exclude them.
I’m with Steve here. I too was skeptical, and it’s turned out to be a complete non-issue.
> and I'd have to something akin to git's filter-branch to clean them out again to avoid that bloat
It’s even more trivial than you might imagine. If you have a commit that added files you don’t want to include you `jj edit` that commit, remove them however is appropriate (rm, mv, add to gitignore, whatever), and… there is no step 3. Later commits are instantaneously and automatically rebased so as to not include those files. Tools like filter-branch are completely unnecessary.
Cool. You've convinced me. A small change in workflow + easy cleanup sounds like it addresses most of my concerns. Though if I were to adopt jj I'd still probably just turn off the feature at first until I saw where I could have used it in practice. I'm going to wait and see for a bit myself. I'm pretty comfortable with git.
The way jj tracks changes isn't a feature you can turn off AFAIK. Maybe you can, but if you can, you shouldn't. This is fundamental to the jj internals and workflow.
As someone who also kept a lot of files in their repo that went untracked, it was a small adjustment. Add to my .gitignore, untrack the files, and done.
You can disable automatically adding untracked files to the repo, but you can't disable it from automatically incorporating changes to tracked files. I believe GP was talking about the former.
You don’t have to convert your team to use jj. So there’s nobody to resist but yourself.
For me, writing temporary output to a gitignored tmp directory has been trivial. And I do exploratory coding in a separate branch. Just because it’s part of the repo doesn’t mean it needs to get pushed.
I get what you are saying about the nicer workflows for those cases.
However, why would the contributors to jj not just try to make git better by addressing these weaknesses?
I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the issues outlined.
Yes, I know that some code bases are too far gone for major enhancements…
> However, why would the contributors to jj not just try to make git better by addressing these weaknesses?
Because the git workflow causes a lot of the difficulty and fixing it involves making a new concept: mutable changesets with a unique id which are built on top of immutable commits.
jj isn’t just some bugfixes or a few porcelain improvements, it deeply changes the way you approach things. And there’s a pretty decent amount of unlearning of subtly-broken concepts you need to do.
In some sense they already are making git better since that’s the data format that the tool supports.
Also, some of the UI improvements or even protocol improvements might make it into git eventually.
I’m skeptical about it being worthwhile to switch to a new backend. Maybe it would work if it’s just local, but a lot of IDE plugins and other tools would need to be written, and git has lots of inertia.
> why would the contributors to jj not just try to make git better by addressing these weaknesses?
Because jj isn't being built to improve git, but to allow using git at Google to work on Piper-backed code instead of hg/fig, and adding support for the abstractions that are needed to support git and piper was probably seen as free complexity on git's side.
This is slightly incorrect. I started it because I believed in the idea of modeling the working copy as a commit, but it's true that I made the storage pluggable from the beginning because I wanted to be able to convince my team at Google that we should use it internally too.
I thought it was simply a response to git5/git-multi getting deprecated once fig became popular.
I'm a bit surprised then, that's one of the things that has kept me from trying it as it feels weird to not have that much control over what gets into the commit. Using magit doesn't help as it's just way too good once you get used to it.
Think of it this way: they are trying to make git better by addressing fundamental weaknesses in git, but some of those weaknesses require a fundamentally different UI paradigm and as such aren’t practical to upstream, hence a new project.
> I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the issues outlined.
You would have thought? Plugins? Git doesn’t have plugins to my knowledge. Hooks are not plugins for security reasons. Meaning you can’t distribute hooks, have people install them and call it an extension.
Then, assuming that they could just make Git better. Are they interested in supporting all of Git plus their new work? Why would they be?
If anything, lazygit has shown it is possible to have more natural workflows on top of git as demonstrated by https://www.youtube.com/watch?v=CPLdltN7wgE, so it is indeed possible
Merges were so, so painful in SVN, though. Maybe SVN improved towards the end of its life? I remember everyone went well out of their way to avoid needing to merge until git, because it could take hours to resolve a heavily-conflicted tree.
People complain constantly about how painful git is when their simple workflows break down. It is legendarily complicated and difficult to use.
But when an alternative comes along and long-term git users try to tell people how much better it is? Everyone immediately forgets all their issues and frustrations. It’s honestly kind of bizarre.
Anecdata: I have no issues with my simple git workflow that I’ve used at the previous 3 companies I’ve worked for. As long as communication is solid across teams/people, merge conflicts and rebasing isn’t that big of a pain to introduce an un proven tool to an org.
My thought would be that most people are happy and it’s the <5% of people who complain the loudest that are heard.
Your org doesn’t have to adopt the tool. Nobody on my team needs to know or care that I use jj instead of git. The only people who do know or care have themselves switched when I showed it off to them.
I’ve worked too many places where I’ve helped fix too many coworkers’ broken git repos to believe in a simple git workflow. Basically everyone uses the same fetch/branch/commit/merge-to-main approach and people still constantly run into problems. None of the people with some claimed simple workflow are doing anything meaningfully different than what everyone else is doing.
It’s just astonishingly easy to internalize all the fixes and band aids we’ve adopted to smooth the sharp edges and forget how often we have to work around them.
But I don’t see the complaints that were claimed. I help people as well. They learn, and we move on. If they don’t learn then we have another problem to solve.
I will admit there is occasional call where I have to get someone out of a twisted pretzel, but that is few and far between.
You don’t deal with rebase conflicts? You don’t ever unstash to the wrong branch? Or to the right branch, but it was changed and now it’s applied uncleanly? You don’t ever want to go fix a previous commit? You don’t ever need to do linear work that gets merged one piece at a time into the trunk?
All of these things (and others) can be worked around with varying levels of annoyance ranging from just living with it to new commands that help out to changing your workflow to completely avoiding some workflows. But in my experience nearly everyone deals with those annoyances on a semi-regular basis.
With a proper workflow and communication, only the first one (rebase conflicts) is a semi-regular occurrence (once a month). The others I have never had to do while working on a team. We establish a clear way of working and everyone abides by it.
And before you say well this doesn’t work with a bigger team, my team is 8 and the org is 50 on the same codebase. At “google scale”, I understand this might not be the same case.
If someone has to go out of that workflow to fix a previous commit on main, they submit a pr on top of latest.
Again, I don’t see the major complications here. It seems to me to be fixing a communication issue in an org more than anything.
jj has no evidence today to support the idea that it will be a main tool in the future.
An even heavier burden of proof comes from the idea that it could be adopted by mainstream forges, so it's certainly not an argument on how jj is better than git.
I'm starting (in my "ample free time") to document them and in a series blog posts help people find systems that will work for them. My experience is that the best systems are the ones that have five characteristics:
1. They're simple
No complex patterns, no "we'll solve everything"
2. They require little or no task switching in the middle
This breaks my ADHD concentration.
3. They're forgiving if you fall off the wagon
You will always have bad days and need to restart. The system must make it easy.
4. The system must be very general, maybe even "too simple" but easy to customize.
There is a natural desire, especially in ADHD people, to over complicate, so the system must allow you to be as simple as possible, but then let you customize later.
5. They don't require any specialized tool (especially not an online tool). No system should be invariably tied to a specific piece of software or hardware. These may be excellent augmentations, but they should never be requirements.
Am I an "organized" person? No, but I'm far better organized than I was. Tasks rarely get missed now. I'm far more productive than I was (and I have stats to back up my assertion). I can almost always retrieve documents I need relatively quickly.
These systems won't change who you are, but they will assist you in being better at being who you are.
reply