> I think the difference is in whether we can accept (or tolerate) externally-imposed structure, especially when we disagree with it. If not, the best coping mechanism is to build your own from the inside.
Yes. You're being more precise than me here. This is spot on. The way I build and manage my own structure is to combat exactly this. For me it's a combination of habits and tools evolved over many years, and it will continue to do so.
Ah. Great input and an approach I really haven't considered! I think this could be great advice for people who struggle with various degrees of decision fatigue.
Personally I tend to be quite impulsive and somewhat random "by design". Some might call it "creative". In any case, I tend to get energy from uncertainty where others around me prefer more structure. And vice versa, I feel more friction when there are no choices. My personal backlog serves as a counterweight in order to stay on track.
Yes. And that's also the risk I run with including such anecdotal "evidence" from my own process, because it definitely won't click with everybody.
I've witnessed people close to me be highly successful with the "single file" approach that you yourself swear by. My point was that most people probably will have some benefit of choosing some approach, and not try to keep it all in your head.
I honestly didn't want the post to center around the organizational bit, it was a late addition, because there's the caveat that it gets interpreted as "this is how you gain productivity". In my specific case it's more about flushing thoughts that otherwise would continue to drift in my mind. This is also why I write. It's calming due to the fact it allows me to lay things to rest.
> I think the critical factor here is to be honest with yourself about what is or is not actually working for you.
Yes, and in order to do so you need to do the occasional introspection and be a mindful of your ways. We all have our quirks and it's also fine to acknowledge this. I still have plenty of "bad habits", many which I have no intention of breaking any time soon.
I completely see your point, and my boring response is "it depends". How heavily I rely on my personal organizational setup depends a lot on context. For instance, at $WORK I need time-tracking and tracability of tasks due to audits. Having a system I barely have to think about is crucial to me in this setting not to waste time in horribly slow web-based ERP-systems. For personal projects I stick to a single text file of issues and ideas. Knowing what to use when is part of the general assessment imo.
OP here. This is one of the exact things that, in my mind, makes programming hard. It probably wasn't covered in the post, but striking the right balance between "bug free" and "pragmatism" towards accepting lack of functionality and error tolerance, is crucial.
Within certain domains like healh-care (my area these days), space travel, military, edge case management play a significant role in the valuation of where to place your effort (although it doesn't exclude the ability to fail fast and hard during development cycles). In other domains exposing users for these hard failures is considered perfectly fine. It depends...
It's just one other aspect - when thinking beyond just the code - that makes the decisions and consideration I have to make every day "hard".
Author here. Thank you for this and from what I can tell you're nailing my frame of mind and where I was coming from with this.
Writing valid computer programs - from "Hello, World!" and the likes - is safe to say "easy". What programming has turned into - and what a large percentage of professional programmers have to deal with on a daily basis - is not.
So it's an article sure to stir up some comments, because we're all coming at it from different angles and people considering themselves programmers fill a wide variety of roles in their companies and in the profession. If people feel they're having an easy time, good on them! But neither feel no shame when the imposter starts creeping in on you or you feel the mountain you have to climb is too tall.
Yes. This one was hard for me to explain. I've discussed it with others too and might try to rephrase it again in the post.
As far as I know, there's no other git command that let's you (as easily) change which commit a local branch is pointing to without first checking it out. And "without checking it out" is the crucial part.
If, as the example tried to explain, you have a huge piece of software (think C++ monorepo) that takes ages to build, unnecessary switching of files back and forth easily messes up build tools relying on modified timestamps to determine what needs to be rebuilt. (Sure, blame the build system, but that might not be a trivial fix.)
So, in that example, the use-case is to make sure the branch is up to date before switching to it. (And you could of course argue that why don't you just create a new branch, which is also a completely valid approach).
Ah, what a stellar use case. It's been forever since I looked into git notes (or was it annotations? can't check right now). But I guess those had significant flaws. Empty commits that you can use the message as a todo-list and fixup/amend in changes as you go. Might try this.
Don't get me wrong, I'd say that's a very good approach too. A lot of my personal repos are private and synced through personal infrastructure so I don't always bother with those kind of files.
Thank you for this elaborate explanation and very valid use-case. I did find out that octopus merges have been used quite extensively in e.g. the Linux history as I was trawling the archives for one of the anecdotal remarks I made. I eventually found them both, by the way (post updated):
I suppose whenever you've got scenarios where integrating a significant volume of unrelated work (with low probabilities of conflicts) it starts to make a lot more sense. I guess it's not really been that relevant to me personally.
I shared your concern with letting Nix manage all configs because it felt wrong to me to have an abstraction layer over all kinds of configs. I've later realized that's got a big benefit of being able to use values across various configs, like high DPI settings for specific machines with 4k monitors as an example.
Version controlling Nix expressions is trivial since it's all just text files. So i basically use just git for that. With flake lock files you get a pretty high guarantee that rebuilding your configs (or machine setup) will be quite reproducible.
I should add that I do still have some imperative/manual steps still though, mostly setting up doom emacs.
I should add that my Nix endeavors begun way back when I started doing Haskell because of the binary caching for Haskell libs. Nix has then gradually taken over pretty much everything I do related to software. So the OS switch was inevitable.
Yes. You're being more precise than me here. This is spot on. The way I build and manage my own structure is to combat exactly this. For me it's a combination of habits and tools evolved over many years, and it will continue to do so.