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.

I have long felt the same way as you. But I do think everyone benefits from structure - 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. If you examine your own sense of spontaneity, you may find some scaffolding you've built up too.

> 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.

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.

Thank you for this nuanced view.

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.

For me, the crucial part is to create a tool/script that just gets one task done as fast as possible. I don't need tools that can do everything. Often it's just a bash script that executes like 5 commands to execute/build something, so that I don't even have to think about those steps and don't forget one.

Tho it is a really fine line to not get hung up on those organizational tasks, yes.

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! Right on the money! Thanks for coming back to state that it makes sense to you now.

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.

I habitually start with 'touch .gitignore' and then committing that.

Since an empty .gitignore doesn't actually do anything and has never been an issue to rebase onto, it works out fine for me.

I should probably, arguably, switch to using --allow-empty but my current workflow is long since baked into my fingers and has yet to cause a problem for me or anybody else, so if I switch it'll be for reasons of pure pedantry (which me being me may eventually be quite sufficient motivation, but hasn't just yet).