• 12 Posts
  • 284 Comments
Joined 3 years ago
cake
Cake day: July 10th, 2023

help-circle



  • Through pushing through user antagonistic changes completely at odds with users wants and hoping people are pliable enough to forget all about trying to be screwed so you can bide time until the next at attempt to screw users?

    Well, that’s the vibe I’m getting from you. I naively assumed open source was based on trust, shared effort and contributions to benefit users so they can install software on their machine that they know is reliable/trustworthy and privacy focussed because anyone can scrutinise it. Silly me.














  • You must work in dreadful places. I’ve seen it a few times, but most places have been productive.

    It needs a good lead dev to set the culture though.

    Whitespace change debates can be avoided by using rule sets in IDEs and agreeing standards within the team.

    Good static code analysis tools in pipelines and IDEs handle most technical issues leaving reviewers to focus on design, maintainability, clarity and readability.

    You can avoid pickiness if you communicate why, so they learn and understand. If you use PRs as a training and learning tool they’re quite productive. If not sure, ask why something was done.

    And if you get picky comments respond with “personal preference and not part of team rules”. But also, you cannot be defensive in your PRS. You have to be open to feedback and points and happy to discuss. Be polite even when feedback is invalid. Defendivesness kills constructive feedback and no matter how old you are and how long you’ve been doing it, you can still improve. Oh and if you been doing it that long, you’re a senior or lead and can influence how things are done.