931 karma · joined June 10, 2018
On the other side of the spectrum is more wholesome long-horizon activities like a challenging side project, career progression, or fitness goals. There's certainly an element of variable ratio reinforcement in all of these, but because the rewards are so much more tangible, and you get to exercise more of your agency, these activities generally feel quite meaningful on reflection.
Playing pinball is somewhere in the middle, probably on the cheaper side of the spectrum. Introspective people can generally reflect on a session and decide whether it was a good use of their time or not.
I really think that 'how do you feel after a long session of this' is a good measuring stick. Very few people will tell you that they feel good after a long session of social media scrolling or short-form content.
Another good measuring stick is 'do you want to want to be doing this?'. I want to want to go to the gym and gain 10kg of muscle. I do not want to want to spend hours on tiktok every day.
If any of the above questions have been or your mind too, you might find this interview valuable.
I'm glad you like lazygit, hopefully I can continue to keep it in high esteem :)
A new version just came out today https://github.com/jesseduffield/lazygit/releases/tag/v0.39....
In the next release we're adding worktree support: if you use worktrees in your daily flow I'd love to know what that flow looks like and what your pain points are so feel free to join the discussion here: https://github.com/jesseduffield/lazygit/discussions/2803
If I've neglected to address your specific criticism I'm happy to do so here
A private method is indeed an abstraction. If you take a chunk of code and extract it out into a method, that's an abstraction, regardless of whether it's private or not.
> Say a branch is never reached through a public interface but you test it in your unit tests since you don't know. This aspect is completely hidden from you.
This is purely a tooling problem. There is no good reason why your linter can't flag that a private method is unused in non-test code.
> Encapsulation literally defines this as a core principal. If you don't accept that then you don't accept the most important concept of OOP.
Do you have a source evidencing this claim? I would be surprised to find any canonical source stating that private methods should be held to a different standard to private classes and private packages
> If you want to break encapsulation you need to come up with an argument that's better than: "It's easier for me in this specific case".
My argument is this: we 'break' encapsulation every time we write a test that's not end-to-end. The question is how much we want to break it, and that question depends on how stable and well-defined the abstraction is that we want to test. If a private method is stable and well-defined, and if the cost of extracting it out into its own class is too great, then it's appropriate to test. A private method is less likely to be stable and well defined compared to a class or a package, because it's at the bottom of the encapsulation hierarchy, but it is not fundamentally different to other levels of encapsulation, and therefore there will be times when it is appropriate to test.
We choose not to run only end-to-end tests because it's expensive both in terms of writing the tests and running them. We choose not to run only unit tests at the lowest possible form of encapsulation because they're more likely to need rewriting when we refactor. Instead we pick out abstractions at various levels of encapsulation that warrant testing in isolation. The decision on whether to test a private method or a private class or a private package differs only in degree, not in kind.
To convince those who disagree with you, you'll need to make a case for why private methods should in fact be held to a different standard than other levels of encapsulation. I'm open to being persuaded on this point but I can't think of an argument that convinces me.
If the one public method just calls private method A, B, and C in order, passing the result of one step to the next, and if we don't need to handle different variants of A, B, and C (meaning dependency injection is not necessary), we arguably don't gain much from splitting the original class in two. We're left with a very small class of a single method that's tightly coupled to the extracted class. We can remove the coupling with dependency injection, but now we need to add some code that actually injects that dependency at runtime. So understanding how the pieces fit together is harder. The only benefit to splitting the class that I can think of is in preparing for a future situation where orchestrating the three helper methods becomes more complex, or where you actually do need to handle different variants of A, B, and C via dependency injection. But it feels like premature abstraction to me, single responsibility principle notwithstanding.
On your point about language limitations, I also wonder about this. I vaguely recall coming across a post that mentioned testing private methods just wasn't an option in various languages in the early days, and it's possible that were that not the case, we wouldn't have so many advocates of the never-test-directly viewpoint. That's not to say that the viewpoint is wrong though.