Pronouns: he/him/his

  • 0 Posts
  • 49 Comments
Joined 2 years ago
cake
Cake day: July 1st, 2023

help-circle
  • Here’s how I approach old and slow:

    1. Older software is mature and battle tested. It’s been around long enough that the developers should know what they’re doing, and have built a strong community for help and support.
    2. Slow is okay when it comes to accuracy. Would I love to back up my gigabytes (peanuts compared to some of you folks out there with data centers in your attics) in seconds? Yes. But more importantly, I’d rather have my data be valid for if I ever need to do any kind of restore. And I’ve been around the block enough times in my career to see many useless backups.






  • 👆 This. In my experience, I’ve seen a lot of developers get upset about “their code” not being used, time wasted, or someone else changing the code after the fact. Who cares? Once you commit that code, it’s no longer your code. It’s the company’s code. Your paycheck will reflect the same amount of money regardless — and if it doesn’t, you may want to find a better employer. 😅











  • In my experience, this amount of conflicts typically occurs because 1) most people mass commit a bunch of (mostly unrelated) changes at once, which leads to 2) inexperienced/impatient devs to clobber incoming merge conflicts without doing proper merges (mostly because they can’t make heads or tails of the diffs).

    This is very easily mitigated if all developers would make small, related commits (with descriptive commit messages and not “committing changes”). This makes everybody’s life easier because 1) diffs are smaller and readable for conflicts, 2) the dev can see the progression of code through commit history, 3) broken code is more easily revertable (and traceable) if something goes wrong, and 4) it’s easier to cherry pick specific changes if the whole changes cannot be published all at once.

    Also, git pull --rebase is your friend and not scary at all. It applies all incoming changes first, then applies your new commits last. 9 out of 10 times it avoids conflicts.

    Lastly, use a GUI. There are plenty out there to suit your tastes, and I feel they are a safer and easier alternative than CLI. Some GUIs are very safe and even allow undo operations on most things.



  • Sometimes it takes a little unintentional embarrassment to drive a point home. It’ll make them think twice next time.

    What I mean by that is that as long as you’re not intentionally or maliciously trying to embarrass them, then you shouldn’t feel bad. You cannot always control how somebody receives information; nor should you. The best you can do is to be clear and polite in your communication. If someone’s feelings get hurt, that’s on them to reconcile, not you.

    This is genuinely like parenting a child: they need to develop their critical thinking skills, and to gain their own confidence. So they must be left to make their own mistakes to learn from. Your job is to give show them the tools to use, give advice when necessary, and be there to catch them when they fall; because they will fall.

    Doing this will help bolster their self-confidence and make them better mid-/senior-developers later in their career. Coddling them and constantly holding their hand will make them reliant on other people and prevent them from learning anything.

    Edit: also remember KISS. 😊