• サぺルOPM
    link
    fedilink
    Polski
    arrow-up
    1
    ·
    4 months ago

    W programowaniu też się to sprawdza. Kiedy się nie myśli o tych toksycznych rzeczach, programy wychodzą bardziej innowacyjne. Można wybiec pomysłami o wiele dalej. Można mieć program z którego jesteś zadowolony. A nie taki by zadowolić innych.

    • naur
      link
      fedilink
      Polski
      arrow-up
      1
      ·
      4 months ago

      Moje wnioski z kodowania po godzinach - nie publikować absolutnie niczego.
      Rób to dla siebie, a nie gwiazdek i followerów na GitHubie.

      • サぺルOPM
        link
        fedilink
        Polski
        arrow-up
        1
        ·
        edit-2
        4 months ago

        Ja bym dodał, żeby nawet nie wspominać. Jest to trochę krzywdzące dla przyjaźni opartych na wymianie doświadczeń. Nie znam dobrego momentu w którym można się czymś pochwalić. Bo wydaje mi się, że potem przestanę lubić projekt i zacznę publicznie narzekać.

        Kiedy pisałem ostatnio emulator, nie mogłem pozbyć się myśli o tym, że robię go dla kogoś. Wymyśliłem nawet tło historyczne w którym by fajnie pasował i był bardziej atrakcyjny dla innych. Potem wpadłem w pułapkę bezsensownego udoskonalania. Na szczęście był przy okazji eksperymentem o zarządzaniu kodem, który też się nie udał. Więc i tak zyskałem doświadczenie. Głównym założeniem było tylko jak zrobić interpreter poleceń i bootloader na różnych starych procesorach. Bo miałem niedosyt po Benie.

        W skejtingu ludzie uczą się tricków. Potem pokazują je znajomym na żywo. W programowaniu to tak jakby zrobić przy spotkaniu jakiś hackathon albo jam. Gdzie kodujesz od zera na miejscu z innymi, którym ufasz, pod wpływem chwili. Więc są inne intencje.

        To się różni od publicznego kodu, który raczej powstaje z intencją, że będzie spełniał życzenia odbiorców. Dobrym przykładem jest tu opowieść autora programu copyparty.