[–] 9 points 3 weeks ago (1 child)

not answering you, but for people having doubts after reading your reply: please translate it yourself because its not just that, there's 1984 stuff like this inside:

Parents or other guardians of minors shall, in accordance with the law, fulfill their responsibilities for family education, educate and guide minors to love the Communist Party of China

  • source
  • parent
  • context
  • [–] 3 points 2 months ago

    are they actually loosing any sensible userbase across all windows versions though? from statcounter I fail to see that, what stats do you guy usually look up too?

  • source
  • [–] 16 points 4 months ago (1 child)

    But I’m also scared. Not of the tech itself, but of what happens when capitalists decide to fully automate labor.

    Dont worry that's not gonna happen. A collegue of mine use llms regularly for code reviews, but you have to put in the work to understand whether what they say makes sense and filter out false positives which are not occasional.

  • source
  • [–] [S] 2 points 4 months ago (1 child)

    Thanks, that's actually interesting. I've found making #5 work with limited human resources / deadlines challenging, and wondered what to do. My answer in the past has been to lower review quality (reviewing faster) while keeping #5.

    In my case the priority for reviews was high, but we were limited by the reviewers/developers ratio since most people would not do reviews...

  • source
  • parent
  • context
  • [–] [S] 1 point 4 months ago (1 child)

    The problem of deciding what should be merged or blocked

    If you want to merge something and I read it over and reject the PR because you forgot about concurrency, that doesn’t mean you don’t get to merge, it means that it’s not finished baking. And assuming you give a shit about the code your response should be “oh shit, lemme fix that and resubmit” OR “actually this code will never have concurrent access, and here’s why.” You’re making this process sound adversarial when it isn’t. It’s a group effort. Everyone wins or loses together.

    You're obviously right, you're misunderstanding me. With blocked I didn't meant "forever", I meant until the issues is discussed. I'm merely asking how the reviewer is making the call on what should be addressed before merge in #5

    If there is work that needs to be done, and you are asked to do it, the code will be merged when it’s right. I don’t decide what to merge, I decide when something is ready to merge.

    you're really nitpicking my English, which I know is not great, but yeah that's what I was asking, so you use #5 with a single person making the final call on when something is ready.

    You’re making this process sound adversarial when it isn’t.

    Absolutely not, I've never said or thought that. But of course development is made of people and computers can only tell you what compiles, not "when it's right" as you say. So of course I'm more curious to understand how to solve situations when you do have conflict, if you don't it's easy.

  • source
  • parent
  • context
  • [+] [S] -7 points 4 months ago (3 children)

    Everything gets reviewed. If you have a constructive comment you put it in the review.

    I’m a tech lead now so that’s basically the end although if they want to argue their case I’ll hear them out.

    So basically you're saying that all the comments are welcome, and should be argued, but you have to appoint a person that have the final say on what to merge right?

    I’m not sure what problem you think is being moved to the reviewer.

    The problem of deciding what should be merged or blocked, I've mainly made this post to understand that, so saying "#5 or you're crazy" doesn't answer much. But I've probably worded that badly.

  • source
  • parent
  • context
  • submitted 4 months ago* (last edited 4 months ago) by to c/programming@programming.dev
     

    Hey, I want your opinion on code reviews, what is the best way to use them in a professional environment? Pick one of the following and give me your thoughts (from the most forgiving to the most strict):

    1. no code reviews, they are useless
    2. optional code reviews
    3. mandatory reviews on code that is already merged, optional fixes
    4. mandatory reviews on code before merging (like a pull request), with a time-frame for optional fixes (i.e. whether to fix what has been pointed out is up to the author), merge will occur anyway.
    5. mandatory reviews on code before merging (PR) with mandatory fixes.

    Of course in open source development with public contributions, you'll often see (5), but I'm not convinced it could work in professional dev.

    Edit: I'm talking about a team of 5 mid to senior devs (no junior or interns) working on a 2-3 year project without many security concerns, but feel free to give me your general opinion.

     

    A lot of posts like the one in the picture are mostly dominated by an image, that if tapped is just displayed as an overlay instead of opening the post. The areas where tapping cause the post to open are very small...

    Is there a way of making it easier or a gesture I'm not aware of?

    submitted 2 years ago* (last edited 2 years ago) by to c/askelectronics@discuss.tchncs.de
     

    Bought a new PC, and I was measuring its consumption out of curiosity. I noticed something weird (to me): when the PC is off (in fact, I completely disconnected the PSU and did the same test), there is quite some current running in the power cable to the PSU (0.15A).

    Further measures showed a power factor of (almost) zero, and I can actually measure a capacity of 2uF across the PSU ac input.

    I did the same thing on an older PC I have, and there is no current / capacity. So what would the reason of a capacitor across the mains on the input be in a PSU?

    PS: the PSU is a Thermaltake Toughpower GF A3 1050W

    Edit: I found some official measurements for this specific PSU: https://www.cybenetics.com/evaluations/psus/2249/ that have 40W standby apparent-power by design

    view more: next ›