• 0 Posts
  • 27 Comments
Joined 11 months ago
cake
Cake day: February 7th, 2025

help-circle
  • The sheer moral corruption of making profit from other people’s suffering is bad enough in the arms industry, but at least the security dilemma of international relations provides a fig leaf of justification: Trusting in other countries’ idealism has been shown to be ineffective, so the most effective way of protecting your country against foreign aggression is to make it more expensive to attack it. To keep peace, one must be ready for war, such that this readiness might deterr either party from actually starting one.

    Of course, that justification of military industry as defensive necessity doesn’t extend to imperialist wars of aggression (Ukraine, Palestine, Venezuela), which is where the moral corruption starts.

    But to directly gamble on that suffering? That’s just blatantly fucked up.








  • Your target group and the effective user base might not strictly overlap. You can’t always anticipate that. Even if your target group is junior devs, it may be hard to accurately imagine their perspective on something you’re necessarily more familiar with. And even if you do, investing the time to explain and document may detract from the fun you have actually achieving “milestones” in terms of features. Particularly for many open source projects, the devs’ fun is ultimately the driving factor.

    It’s a start, but not a full solution.


  • From personal experience:

    One part is manuals / docs being hard to use. Some seem to assume a measure familiarity with the subject, creating a certain entry barrier. They’re perfectly usable as reference for people who know the gist but look up details, but for younger devs, it’s disheartening to get the sense that you don’t understand anything. That’s a common issue with FOSS tools, in my experience, where the devs naturally prioritise developing the actual tool. Asking and getting an answer for a specific example can help get a foothold and start climbing that, but it’s no guarantee.

    A second part is that manuals don’t always cover things you can’t do (because obviously it’s hard to predict what people would come up with wanting to do), but it’s hard to tell whether that’s just incomplete unless you ask and get an explicit, hard “nope”. Bonus points for commercial products documenting what you can do, but not with your current license: You’ll diligently read the page for what you want to do, attempt to implement it, then be hit with “please upgrade to Premium for this feature”.

    A third part is terminology. Just like the non-features, it’s impossible to predict all the ways someone might describe what they want to do if they don’t know any better way to phrase it. I’d count language barriers into this as well, which is an issue that a smaller, US-heavy software development world wouldn’t have had to the same degree as we do today.

    And finally, of course, there’s convenience, which is where I think the managers have the greatest impact: The less time you have to spend learning how to RTFM or digging through the docs, the less time is “wasted” on things that aren’t immediately productive. Particular non-IT-background managers may not appreciate the value of such skills, so they’d rather have you spend someone else’s time taking a shortcut than invest your own.

    So I think this is an issue arising naturally from several independent factors, which makes it hard to tackle effectively. Managers should plan for and encourage taking time to understand the manual, but I don’t see a universal solution to the documentation quality and language barriers.

    Also, retiring to have a farm is a mood.








  • Ideological drive, I suppose? Accounting is still about investment of capital.

    I like to view it as a form of egoism: favouring socially beneficial policies not (just) because it helps others, but because it helps me too. Things like collective bargaining power to improve conditions for everyone (including me), worker protections (which also protect me), a solid healthcare system (so I can get good healthcare)… You get the point.

    It’s my go-to argument for people saying “I don’t care about [demographic]”: This isn’t just about helping others, it’s about helping you too. Whatever good we do for everyone also includes you.

    Personally, I also believe in social values, but it’s not the only plausible reason to approve of social measures.



  • I learned of the PARA method somewhere on Lemmy, and found it (or an adapted version) really well-suited for myself:

    https://fortelabs.com/blog/para/

    The short of it is to structure files in four categories:
    Projects (with a definable scope and end)
    Areas of responsibility (stuff that needs to be done repeatedly or constantly without any defined “end”, like timesheets or budget plans)
    Resources (learning material, reusable assets)
    Archive (finished / abandoned projects, areas no longer relevant for you, resources you’re not longer interested in)

    I suck at the “abandoned project” part, because I refuse to accept when I’m not gonna keep at something any more, and sometimes have stuff lingering in my “Areas” that should long be archived. I also have some things that are kinda perpetually ongoing developments without any clear “end”, although each increment of work does, so they occupy some hybrid space between Area and Project. I’ve put them in Projects anyway, because the point is to help me find things and making “Projects” the place to find “Things I’m working on” is easy enough.


  • Without knowing your dynamic or their tone:
    They probably just wanted to poke fun and baited you into setting it up. It’s kinda like updog or ligma.

    Of course, it could also be ignorance, or malice, but personally, I don’t randomly ask people what OS they use unless I expect them to even understand that question. Their reply suggests they are well aware that you’re using Linux, so ignorance is unlikely, and if they knew your answer and didn’t want to hear it, they probably wouldn’t ask.