6 ms·
> Giving up tests and versions, I ended up with a much better program. I can’t understand how anyone would willingly program without using source code control
by munchler 2y ago
> Giving up tests and versions, I ended up with a much better program.
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”?
- shepherdjerred 2y agoYeah, this is not good advice for the average person, even for solo projects.
- codr7 2y agoI agree, and the author probably does as well. I didn't get the feeling it was meant as general advice.
- shermanyo 2y agoI think in this case, the author means coding version logic into the app itself. eg. versioned API endpoints for backwards compatibility
- layer8 2y agoThis is about a desktop text editor built with LUA on a C++-based native framework for writing 2D games: https://git.sr.ht/~akkartik/lines2.love https://git.sr.ht/~akkartik/lines2.love Very unlikely to have versioned API endpoints involved.
- shepherdjerred 2y agoI don't think so: > 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.
- mattacular 2y agoI don't get what they mean by "Version control kept me attached to the past." You don't have to look at the history to use other features of version control. Typically everything is moving forwards in a repository.
- Izkata 2y agoBest guess, a reflexive need to keep diffs as small as possible. Personally I think this is a completely wrong mindset, having version control is what allows you to go wild because you can always use the version from before a crazy refactor - and if it goes wrong you can even keep it around on a branch for reference later on with a second attempt.
- hetman 2y agoYour quotes seem to reinforce parent's assertion he's not talking about version control in the form of tooling but some kind of versioning in the code itself: "...while tests and versions..."
- resonious 2y agoHe specifically mentions version control and avoiding merge conflicts, so I'm pretty sure it's stuff like git that he's finding himself cautious about.
- jay_kyburz 2y agoHow do you get a merge conflict with yourself?
- wtetzner 2y agoThat makes sense, but then why not just work on trunk and don't worry about branching?
- bugbuddy 2y agoCould this person be intentionally giving bad advice?
- bubblebeard 2y agoI think it’s just an alternative way of thinking. It’t not one I agree with, but I can see where the author is coming from. Think he’s just tired of spending time on useless tasks around his projects. For all we know they may be, but I do have hard time viewing testing and version control as overhead xD
- codr7 2y agoI'm pretty sure he's trying to find his balance, because it is always a balance and we tend to err big on the other side.
- bubblebeard 2y agoYeah exactly
- raincole 2y agoThe author is probably experiencing mental fatigue or even burnout about programming. If version control bothers you that much I'd say it's a good sign that you need to take a break.
- akkartik 2y agoThis seems very far from my subjective experience. The little platform-independent programs I write for myself and publish are a source of spiritual rejuvenation that support my day job in a more conventional tech org with a large codebase, large team and constantly changing requirements. 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 https://akkartik.name/post/wart-layers) This comment may also help clarify what I mean: https://news.ycombinator.com/item?id=41158040 https://news.ycombinator.com/item?id=41158040
- lnenad 2y agoAll of your comments are without any arguments against vc. It also seems there is a missunderstanding of your state, you seem to use it but you aren't focused/disciplined in its use? > 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.
- akkartik 2y agoBut I said VC is not "bothering"! 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.
- xelxebar 2y agoAs programmers we are inundated with choice and options. Our tooling and whatever the zeitgeist considers "best tooling" tends to err on the side of making $THING easier to do. 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.
- sethherr 2y ago> branching encourages cutting a program into "independent features" 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?
- tmn 2y agoI’m working on a feature that is a moderate refactoring and extending of an existing feature. I’m in some sense taking extra burden by ‘sculpting’ my change out of the existing code and the working backwards to come up with the logically contained and discrete commits to get from where I started to where I want to go. 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?)
- nine_k 2y agoThe author does not seem to have to support any professional / paying users, and wants freedom to experiment more than a guarantee of a known working version. The author also does not seem to work on large systems, or do significant teamwork (that is, not being the only principal author). 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.
- imiric 2y agoTests and version control still have immense value when working solo. 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.
- akkartik 2y agoWhatever floats your boat, but just to be clear my own language and virtual machine do have tests. The value of tests depends on the domain. Graphics and games benefit less from tests. My graphical text editor straddles the worlds. 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.
- akkartik 2y agoI'm trying to build something small with a quickly frozen feature set. I've chosen to build on a foundation that changes infrequently. There is more background at https://akkartik.name/freewheeling https://akkartik.name/freewheeling. 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 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.
- galaxyLogic 2y agoO the joys of solo-programming! I do it too and the thing I find interesting about it is I think a lot about how to program better like you are. If I was working on a team I would probably not think much about it, I would be doing just what my boss tells me to do.
- pseudoramble 2y agoThis context helps me understand more what you're getting at quite a bit. I dunno if I could manage the same approach but I at least appreciate how you're thinking about it. Thanks!
- voiper1 2y agoYep, commit your code when it "works". Then I can safely go off on a hair brained experiment, knowing I can easily throw away the changes to get back to what worked.