I can’t understand how anyone would willingly program without using source code control in 2024. Even on a single-person project, the ability to work on multiple machines, view history, rollback, branch, etc. is extremely valuable, and costs almost nothing.
Maybe I’m misunderstanding what the author means by “versions”?
You're absolutely right that this approach doesn't apply to most programs people build today, with large teams and constantly mutating requirements.
I do still have source control. As I say in OP, I just stopped worrying about causing merge conflicts with other forks. (And I have over 2 dozen of them now; again, see the link above for details.) So I have version control for basic use cases like backups or "what did I just change?" or getting my software on new machines. I've just stopped thinking of version control, narrowly for this program, as a way to help _understand_ and track what changed. (More details on that: https://akkartik.name/post/wart-layers) One symptom of that, just as an example of what I mean: I care less about commit message hygiene. So version control still exists, but it's lower priority in my mind as a part of "good programming practice" for the narrow context of programs like this with frozen feature sets, intended to turn into durable artifacts that last decades.
In such a situation, all these tools may not provide a lot of value. A flute player in a large orchestra playing a complex symphony needs notes and/or a conductor; a flute player playing solo against a drum machine, or, playing free jazz, does not much need notes, and would likely be even hindered by them.
Tests help with ensuring that you don't introduce regressions, and that you can safely refactor. It's likely that you test changes manually anyway, so having automated tests simply formalizes this, and saves you time and effort in the long run.
Version control helps you see why a change was done, and the ability to revert changes, over longer periods of time. We tend to forget this even after a few weeks, so having a clean version control history is also helpful for the future version of you.
Not having the discipline to maintain both, and choosing to ignore them completely, is just insane to me. But, hey, whatever works for OP. I just wouldn't expect anyone else to want to work with them.
The only scenario where I could conceive not using either is in very small projects with a short lifespan: throwaway scripts, and the like. The author is writing their own language and virtual machine, which don't really align with this. Knowing their philosophy, I would hesitate to use anything they made, let alone contribute to it.
I'm still using version control as I've clarified elsewhere. I wasn't expecting this post to gain such a broad audience; I realize now it is really about how one's workflows can keep one stuck in a rut, a local optimum.
> The value of tests depends on the domain.
I agree with this. And like I said, for small throwaway projects and quick experiments I can see how tests and version control can be tedious to deal with. But even in projects like your Freewheeling Apps, where you're releasing them to the public and encourage people to use, you're doing them and yourself a disservice to not have tests.
But you clearly know what you're doing, so I'll stop preaching. :) Good luck with your projects!
BTW, I'm a big fan of LÖVE and it's super interesting what you're using it for. I only imagined it was good for games, not apps.
https://git.sr.ht/~akkartik/lines2.love
https://git.sr.ht/~akkartik/text2.love
I tend to gravitate towards tests, and taking out tests as I describe in OP is a lot of work.
If version control bothers you that much I'd say it's a good sign that you need to take a break.
I'm not "bothered" by version control. I've not even stopping using it. As I say in the post, I just don't think about it much, worrying about merge conflicts and so on, when I'm programming. I've stopped leaning on version history as a tool for codebase comprehension. (More details: https://akkartik.name/post/wart-layers)
This comment may also help clarify what I mean: https://news.ycombinator.com/item?id=41158040
> I'm not "bothered" by version control. I've not even stopping using it. As I say in the post, I just don't think about it much, worrying about merge conflicts and so on
How is using VC, especially in a solo project, "bothering"? It really does seem you just hate the tooling around modern software development and you just want to spit out code that does something for you and yourself. Which, again, is fine, but it's usually not a good idea if you are making something for other people/users.
Perhaps I should replace the word "versions" in my post with "workflows". In some situations the workflows I settle into contribute to a feeling of being stuck in a local optimum. Throwing away familiar and comfortable workflows can help find a global optimum. It's just the first step, though. It takes hard work to build everything all at once. But it can be valuable for some projects if you aren't happy with where you are.
But having 1000 easy options always available introduces severe cognitive burden to pick the correct choice. That's part of the reason why we as an industry have enshrined all shorts of Best Practices and socially shame the non-adherents.
Don't get me wrong, bad architecture and horrible spaghetti code is terrible to work with. However, questioning the things that feel Obviously Correct and exploring different and austere development environments that narrow our set of available choices and tools can sincerely operate to sharpen our focus on the end goal problem at hand.
As for version control, branching encourages cutting a program into "independent features"; history encourages blind usage of potentially out-of-date functional units; collaborative work reifies typically-irrelevant organizational boundaries into the code architecture (cf Mel Conway); etc.
Version control's benefits are also common knowledge, but there are real tradeoffs at the level of "solving business problem X". It's telling that such tradeoffs are virtually invisible to us as an industry.
But, you can choose not to branch then?
I’m really confused about the trade offs of version control. I can understand trade offs of branching strategies, but at its most fundamental (snapshots of your code at arbitrary times), I can’t think of any drawbacks?
Are you familiar with the artistic practice of adding "artificial" constraints in order to promote creativity and productivity? See Gadsby, the novel written without using the letter "e", or anything produced by Oulipo.
The point is that we have a superabundance of choice with software architecture and programming tools. One subset of those tools comprises things provided by version control. Give yourself a version control-less, limited development environment and see how it influences the way you think about and practice coding. There will be sharp edges, but if you give it an honest attempt, you will also very likely discover novel and better ways of doing more with less.
There are many things you can try. Disable syntax highlighting in your editor; try exclusively using a line editor such as ed; flatten your codebase into a single directory; code everything in a single file; organize your data structures to minimize pointer chasing; support extreme cross-platform compatibility (10 OSes?); write platform-independent code using "only assembly" (a la Forth, sectorlisp, or whatever); write a thing and then nuke and rewrite 5 times; etc.
IMHO, value in the above is most easily discovered by retaining a strong introspective eye throughout your personal development process. Where are the pain points? What processes force you to think about non-end goal issues? When does coding feel the most glorious? When did you have the deepest insights? Blah blah blah.
Not OP, but I'd argue you are the one moving the goalpost here.
If someone says they are not using "version control", I'm going to assume that they are not using git (or similar) at all. Any other meaning would be so arbitrary to be almost useless. No one can guess where you draw the line in the sand between "I'm not using any version control tool" to "I'm technically using a version control tool but I'm not doing version control because I don't do X,Y,Z".
I personally can't imagine writing any non trivial piece of code without using git. Even in its more basic form, the advantages are overwhelming. But at no point of my 20+ years of development I've ever applied the same rigorous version control rules of professional environments to my personal projects. At best I've used branches to separate features (rarely, and mostly when I got tired of working on a problem and wanted to work on a different one for some time), and PRs to have an opportunity to review the changes I made to see if I forgot to do something. At "worst" I simply used it as a daily snapshot tool (possibly with some notes about what's left to do) or as a checkpoint after getting something complicated working.
If the author has finally figured out rigorous source control can be unnecessary and counterproductive on small projects - good on them! But if that's the case then say that. Calling the fine tuning of which process you want (or don't want) to use "no version control" is just misleading.
I would be nice to just make my change without having to show it in a series of discrete steps.
I’m not actually opposed to this standard, but trying to show one perceivable downside that op may be alluding to (I’m not actually sure?)
You could just check in your code every night. And, vs not having those commits (even without messages) - what could possibly be the downside?
If the OP is referring to version control because they're needing to handle multiple branch types, switching between versions etc that is much more involved....but also makes it even harder to see how you can manage that by simply dropping version control entirely?
From the article, it does seem like it's not about any sort of specific feature they use, but rather the sheer basic "save versions of code" aspect of VC:
"Version control kept me attached to the past"
To go back to an earlier comment, this honestly sounds like burnout to me if you're having temporal anxiety from saving code.
> Back in 2015 I was suspicious of abstractions and big on tests and version control. Code seemed awash in bad abstractions, while tests and versions seemed like the key advances of the 2000s.
> In effect I stopped thinking about version control. Giving up tests and versions, I ended up with a much better program.
> Version control kept me attached to the past. Both were counter-productive. It took a major reorientation to let go of them.
You don't have to look at the history to use other features of version control. Typically everything is moving forwards in a repository.
I didn't get the feeling it was meant as general advice.