• 0 Posts
  • 81 Comments
Joined 1 year ago
cake
Cake day: July 2nd, 2023

help-circle



  • I’ll rephrase them, except in good faith:

    1. Talking directly to the people about the work is better than a 95 state JIRA pipeline

    2. Document your finished working work, not every broken POC, because that’s a waste of time

    3. If the contract isn’t actually going to meet the desires of your stakeholders, negotiate one that will

    4. If you realize the plan sucks, make a better plan.

    My company paid to have Kent Beck come to workshop with our Sr devs. I expected to dislike him, but he won me over pretty quick.

    I don’t remember what it was, but someone was like “Kent, we do X like you recommend in the manifesto, but it creates Y, and Z problem for us”

    And he was like “So, in your situation it isn’t providing value?”

    Guy was like “No”

    “Then stop doing it.”

    It’s not hard. It’s the most fucking common sense shit. I feel bad for them because these guys came from a world where there were these process bibles that people were following. So they wrote like, basically a letter saying “if your Bible doesn’t serve you, don’t follow it”

    And all these businesses dummies were like “oh look, a NEW bible we can mindlessly follow”


  • Ok, I think I see your position more clearly now:

    You’re thinking about people who are interested and installing based on technical interest and curiosity.

    In those cases, I think you’re probably right. There is probably some base competency at play. A desire to learn. Probably someone in their sphere to support.

    I’m thinking more about the type of people who would buy a Chromebook. Or my cheap ass parents who want to squeeze another 5 years out of an ailing laptop. They don’t want to spend any money and just want to use Facebook and YouTube. Send some emails. Connect to wifi. Print their boarding passes. Not have their machines riddled with viruses within minutes because their windows OS isn’t getting security updates anymore. I think this is actually a massive use case, and I want Linux to be accessible to them without needing to use the terminal for anything.


  • I can’t even begin to count the number of times I’ve seen absolutely terrible advice posted and taken regarding how to do things in Linux. Can’t connect to something? Easy, make a blanket iptables rule to permit everything. Something can’t read a file? Chmod 777. Install isn’t working? Just install as root and use root as your general login from there on out.

    It’s hard to learn Linux.

    But it’s even harder to FORGET what you’ve learned, to empathize with what it was like to not understand it at all. That’s why it’s SO HARD for us who’ve been using it daily for a decade to empathize with newcomers.

    It’s why people literally can’t fathom why people are afraid of the terminal.

    It’s why, even when someone takes the time to explain why, people go, “nah, that couldn’t possibly be it”

    It’s like when gun people can’t comprehend why people are afraid of guns. The answer is obvious they just can’t hear it.

    Edit: I think I better understand that there are more nuances around the cases now, and I think I’m being unfair by making blanket statements about what is and isn’t obvious



  • IMO, caution, wariness, concern, and unfamiliarity manifest as revulsion.

    EVs. Solar panels. Heat pumps. Anything outside of CIS heteronormal relationships.

    I’m my experience, after the age of like, 25, people (in GENERAL… Obviously many expectations) feel like they’ve got life figured out and push back against pretty much anything that challenges whatever they’ve grown accustomed to.

    Nobody bitched about the DOS prompt when nobody knew how to use computers. Young people learned it. Old people insisted computers were a fad and pushed back entirely.

    In my calculation, it’s just typical and predictable human response. Open to other theories though.


  • I mean, the answer to this is obvious if you can empathize.

    Gui has baked into it hints on cause and effect. The terminal is a freeform incantation machine where you need to know and utter magic spells.

    sudo rm -rf /

    Is just as magically nonsense as

    sudo apt-get update

    If you don’t know what ANY of it does, your capacity to fuck things up is unbounded on the terminal. In a GUI, rightly or wrongly, you expect your capacity to fuck things up is bounded by the context at hand. I do not expect that I can nuke my system clicking through Firefox.

    You can claw the terminal from my cold dead hands, but I’m not offended by the notion of a GUI.

    Why? Because developer attention scales broadly by usage. Well used projects get more love. If we could even break 10% home adoption of any Linux distro and the runaway effect of net new developer input would destroy closed source operating systems, and I’m here for it. If that means adding a fucking Ubuntu checkbox to let people enable Wayland without strictly requiring the command line go fucking nuts.




  • This is an interpretation of what happened. It’s the one that paints America in the most favourable light, for sure.

    Another one is that the “no surrender” mentality was a direct result of the terms of the Potsdam Declaration which demanded “unconditional surrender” from Japan. Japan knew they had lost, they were just hoping to fight for the SPECIFIC surrender condition of the preservation of the Imperial line (aka, let the Emporer still be the Emporer, preserve the family).

    Had the Potsdam Declaration permitted that concession, it very well may have been the case that no nukes would have been necessary.

    Anyways: tough to understand the exact truth of any hypothetical situation. I just think it’s unfortunate that the “The USA HAD to, though” argument is so often repeated without a very full context of the surrounding political realities. It’s a very bite sized explanation, and it paints the USA in a fantastic light. It’s perhaps not a coincidence that it was AT Potsdam that the west hinted to Stalin of the existence of the nuclear bomb.

    What’s the point of building the thing if you can’t prove to the world you have it, and are willing to use it?


  • It depends VERY much about the content and invitees of the meetings.

    If you’re there to give your expert engineering feedback, awesome. If you’re there to receive the information you need in order to provide expert engineering feedback, awesome.

    So often, I find, meetings are too broad and end up oversubscribed. Engineers are in a 2 hour meeting with 10 minutes of relevance.

    There are serious differences in meeting culture, with vast implications oh the amount of efficacy you can juice from the attendees.




  • So you’re saying that for you, not only do you generally not see value is knowing types, but that them being explicitly defined is DETRIMENTAL to your ability to read the code?

    For me, it’s like if I whip open a recipe book and see tomato sauce, dough, cheese, and pepperoni are the ingredients. Before the recipe details specifically how they are combined, I have a pretty good context from which to set expectations based on that alone. It’s a cheap way to build context.

    But I don’t think you’re all lying. And you are very likely not all incompetent either. I wish I could sit down with you and have you show me examples of code where explicit types are detrimental to readability, so I could examine if there are cases that exist but are somehow being mitigated by a code style policy that I’m taking for granted.