• 0 Posts
  • 39 Comments
Joined 8 months ago
cake
Cake day: December 9th, 2023

help-circle
  • I think that sometimes what happens to people is that they build the life that they implicitly believe they are “supposed” to be living because that is what they see everyone else around them doing, rather than based on an honest self-assessment of whether this really is the what will make them happy. When they realize that this life is not actually making them very unhappy, they look for outside factors to blame because they did everything that they were “supposed” to be doing so it could not have been their own misinformed choices that led them to this point.

    And in fairness, no one chooses where they are born and the cultural conditioning that we receive, so this is not entirely their fault. It is really a societal problem that we do not encourage enough people to engage in true self-introspection to figure out for themselves what is important to them and what they want to get out of life so that they make these kinds of decisions with great deliberation and personal self-insight rather than taking the default option.






  • Something that definitely separates me from some of my less experienced coworkers is that, when I sit down and start to implement a plan I came up with in my head, if it turns out that things start exploding in complexity then I reevaluate my plan and see if I can find a simpler approach. By contrast, my less experienced coworkers buckle down and do whatever it takes to follow through on their plan, as if it has now become a test of their programming skills. This makes life not only more difficult for them but also for everyone who has to read their code later because their code is so hard to follow.

    I try to push back against this when I can, but I do not have the time and energy to be constantly fighting against this tendency so I have to pick my battles. Part of the problem is that often when the code comes to me in a merge request it is essentially too late because it would have to be essentially completely rewritten with a different design in order to make it simpler. Worse, the “less experienced” coworker is often someone who is both about a decade older than me and has also been on the project longer than me, so even though I technically at this point have seniority over them in the hierarchy I find it really awkward to actually exercise this power. In practice what has happened is that they have been confined to working on a corner of the project where they can still do a lot of good without others having to understand the code that they produce. It helps that, as critical as I am being of this coworker, they are a huge believer in testing, so I am actually very confident that the code they are producing has the correct behavior, even when I cannot follow the details of how it works that well.









  • Yes. My rule of thumb is that generally rebasing is the better approach, in part because if your commit history is relatively clean then it is easier to merge in changes one commit at a time than all at once. However, sometimes so much has changed that replaying your commits puts you in the position of having to solve so many problems that it is more trouble than it is worth, in which case you should feel no qualms about aborting the rebase (git rebase --abort) and using a merge instead.


  • The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation–running the full test suite at each step to verify that my changes were correct–than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.




  • If, as you say,

    I’m unconcerned with how it was intended since that’s totally irrelevant to what it actually is.

    Then why did you waste time describing what you believed was the intention behind it earlier when you said,

    I think of it as a rhetorical flourish to emphasize the importance they placed on representing states rather than people.

    Regardless, the other point that I made that you haven’t addressed still stands: they put that prohibition against banning the slave trade in there for a reason, and that reason was presumably not “as a rhetorical flourish”, so either the people who insisted that it be present were horribly incompetent at writing legal language that would preserve their own interests, or your personal opinion as to how Constitutional law works in this case is missing something important.



  • Indeed, the limitation in what can be amended is in practice totally powerless. I think of it as a rhetorical flourish to emphasize the importance they placed on representing states rather than people.

    It isn’t worded as a “rhetorical flourish”; it is worded incredibly clearly and explicitly as a prohibition:

    Provided that no Amendment which may be made prior to the Year One thousand eight hundred and eight shall in any Manner affect the first and fourth Clauses in the Ninth Section of the first Article; and that no State, without its Consent, shall be deprived of its equal Suffrage in the Senate.

    In fact, taking your reasoning a step further: are you likewise arguing that when the prohibition against banning the slave trade prior to 1808 was included here, that it was also understood to be a “rhetorical flourish” with no teeth behind it? If so, then why did they go to so much trouble to put it in? It seems like a lot of wasted effort in that case.