Konstruktywne kłótnie

4

Będąc dzieckiem zasłyszałem rozmowę studentów informatyki dyskutujących o matematyce. Popatrzyłem na nich z uznaniem, bo dyskutowali na temat sposobu obliczenia czegoś i doszli do wniosków mimo różnic zdań. Teraz wiem, że to zwyczajnie była pasja. Na swoim roku widziałem może jedną osobę, która miałaby taką wiedzę i umiałaby tak dyskutować. Teraz najczęściej widzę jałowe dyskusje o językach programowania, systemach operacyjnych i roli biznesu. Ale żeby omówić matematyczne ujęcie np. problemu komiwojażera, to nie ma komu.
Wiem, że mało kto jest aż tak ambitny i chce poświęcać tyle czasu na teorię, ale brakuje mi dyskusji o czystej informatyce, czyli algorytmice. To wymaga bardzo abstrakcyjnego myślenia, gdzie równie dobrze można radzić sobie z matematyką.

5

Dziś w dobie 200 języków, i 2000 frameworków, bibliotek, i innych dziwactw ludzie nie mają na to czasu. W pracy rzadko kiedy sięgasz po zaawansowaną matmę. Płaci się za znajomość narzędzi, i umiejętność ich wykorzystania. Ciężko wymagać od Springowca dyskusji o algorytmach gdy zjadają go xml'e. To o czym piszesz raczej bardziej w ośrodkach naukowych / badawczych.

0

Dokładnie, nie ma informatyki na poziomie bez znajomości matmy.
Jak dwie osoby znają się na rzeczy to w końcu któryś któregoś merytorycznie przekona do swojej metody i współpraca będzie kwitła.
Co innego jak mamy do czynienia z osobą niekompetentną lub co gorsza z podejściem typu "ja mam rację i koniec" .

3
Lubię Naleśniki z Dżemem napisał(a):

Będąc dzieckiem zasłyszałem rozmowę studentów informatyki dyskutujących o matematyce. Popatrzyłem na nich z uznaniem, bo dyskutowali na temat sposobu obliczenia czegoś i doszli do wniosków mimo różnic zdań.

Może lepiej by było, gdybyś zamiast tylko patrzeć z uznaniem, wziął z nich przykład i zastosował w swoim życiu w różnych dyskusjach, nie tylko tych o matematyce?

0
Hispano-Suiza napisał(a):

Dziś w dobie 200 języków, i 2000 frameworków, bibliotek, i innych dziwactw ludzie nie mają na to czasu. W pracy rzadko kiedy sięgasz po zaawansowaną matmę. Płaci się za znajomość narzędzi, i umiejętność ich wykorzystania. Ciężko wymagać od Springowca dyskusji o algorytmach gdy zjadają go xml'e. To o czym piszesz raczej bardziej w ośrodkach naukowych / badawczych.

Z drugiej strony te języki powstały w jakichś okolicznościach. Myślę, że nie działo się to w wyniku pstryknięcia palcami tylko dyskusji, czasem wielomiesięcznych.

0
Lubię Naleśniki z Dżemem napisał(a):

Z drugiej strony te języki powstały w jakichś okolicznościach. Myślę, że nie działo się to w wyniku pstryknięcia palcami tylko dyskusji, czasem wielomiesięcznych.

Powstawanie samego języka to na pewno temat nie wzięty z powietrza. Nikt nie wstaje rano, i nie dochodzi do wniosku, że zrobi nowy język, który będzie najlepszy, najszybszy, najlżejszy, najwydajniejszy, naj(...). Natomiast jeżeli chodzi o frameworki, i biblioteki (zwłaszcza w JS) to mam wrażenie, że dokładnie tak one powstają :-)

1
somekind napisał(a):
Lubię Naleśniki z Dżemem napisał(a):

Będąc dzieckiem zasłyszałem rozmowę studentów informatyki dyskutujących o matematyce. Popatrzyłem na nich z uznaniem, bo dyskutowali na temat sposobu obliczenia czegoś i doszli do wniosków mimo różnic zdań.

Może lepiej by było, gdybyś zamiast tylko patrzeć z uznaniem, wziął z nich przykład i zastosował w swoim życiu w różnych dyskusjach, nie tylko tych o matematyce?

Niniejszym szukam polimatów.

1

Teraz najczęściej widzę jałowe dyskusje o językach programowania, systemach operacyjnych i roli biznesu

Takie dyskusje też mają sens, o ile ich uczestnicy potrafią zaakceptować inny punkt widzenia, przyjąć, że coś w tym jest. Ja np. tak mam, że z kimś się nie zgadzam nt. ww. rzeczy, ale jednak ktoś też ma swoje racje i argumenty. Więc moje zdanie jest najmojsze, ale ktoś może mieć za to spojrzenie z innej perspektywy. I nawet jeśli się z kimś nie zgodzę, to jednak mogę zobaczyć pewną drugą stronę rzeczywistości, pewien "edge case" (niekoniecznie chodzi o edge case czysto techniczny, ale także po prostu specyficzna sytuacja w której jest osoba X, pewien kontekst, w którym pogląd Y ma sens).

1

Co prawda z trochę innej bajki, ale w trakcie studiowania margetingu i zarządzania uderzała mnie "brzydkość" naszych podręczników. Byłam przyzwyczajona do takiego akademickiego podejścia pełnego fascynacji każdym zagadnieniem, wyobracaniem go na wszystkie możliwe strony, zrozumieniem i dopiero wtedy odłożeniem na półkę. Zetknęłam się natomiast z podejściem: to jest młotek, walimy nim w gwoździe, gwoździe są po 3.50.
Taki świat niestety :(

0
Lubię Naleśniki z Dżemem napisał(a):
Hispano-Suiza napisał(a):

Dziś w dobie 200 języków, i 2000 frameworków, bibliotek, i innych dziwactw ludzie nie mają na to czasu. W pracy rzadko kiedy sięgasz po zaawansowaną matmę. Płaci się za znajomość narzędzi, i umiejętność ich wykorzystania. Ciężko wymagać od Springowca dyskusji o algorytmach gdy zjadają go xml'e. To o czym piszesz raczej bardziej w ośrodkach naukowych / badawczych.

Z drugiej strony te języki powstały w jakichś okolicznościach. Myślę, że nie działo się to w wyniku pstryknięcia palcami tylko dyskusji, czasem wielomiesięcznych.

Paradoksem upowszechnienia się informatyki jest to, że w tej powszechnie stosowanej informatyce jest coraz mniej informatyki. I to nie tylko z punktu widzenia ćwierćmózgiego juzera przewijającego tablicę na FB, ale - jak widać - również z punktu widzenia wytwórców samej technologii.

0
Freja Draco napisał(a):
Lubię Naleśniki z Dżemem napisał(a):
Hispano-Suiza napisał(a):

Dziś w dobie 200 języków, i 2000 frameworków, bibliotek, i innych dziwactw ludzie nie mają na to czasu. W pracy rzadko kiedy sięgasz po zaawansowaną matmę. Płaci się za znajomość narzędzi, i umiejętność ich wykorzystania. Ciężko wymagać od Springowca dyskusji o algorytmach gdy zjadają go xml'e. To o czym piszesz raczej bardziej w ośrodkach naukowych / badawczych.

Z drugiej strony te języki powstały w jakichś okolicznościach. Myślę, że nie działo się to w wyniku pstryknięcia palcami tylko dyskusji, czasem wielomiesięcznych.

Paradoksem upowszechnienia się informatyki jest to, że w tej powszechnie stosowanej informatyce jest coraz mniej informatyki. I to nie tylko z punktu widzenia ćwierćmózgiego juzera przewijającego tablicę na FB, ale - jak widać - również z punktu widzenia wytwórców samej technologii.

Z drugiej strony będzie garstka dobrych programistów, którzy będą tworzyć frameworki, systemy operacyjny itd. W końcu żeby pisać jądro Linuksa trzeba coś umieć. Czyli będzie jak kiedyś: mało kto widział, ale wszyscy patrzą z uznaniem ;) .

3

Jesteśmy chyba na tym niewdzięcznym etapie podobnym do schyłku XIX wieku, gdy nie było już zbytnio pola do popisu, bo co dało się opisać mechaniką klasyczną i klasycznymi prawami fizyki, to zostało opisane, mechaniki kwantowej jeszcze nikt nie wymyślił, rewolucja przemysłowa ostatnich ~150 lat wystrzeliła wszystko do przodu i może świat nauki był bardziej uporządkowany niż w czasach rewolucji, ale niektórzy zaczynali żyć w przeświadczeniu, że wszystko już wymyślono i wynaleziono. Co najwyżej mogli się kłócić, czy prąd stały jest lepszy/gorszy od zmiennego albo czy silnik benzynowy zastąpi turbinę parową gdzieś-tam.

No i teraz mamy w sumie to samo, "wszystko lub prawie wszystko", co dało się wymyślić w kwestii klasycznej informatyki zostało już wymyślone, co najwyżej można usprawniać istniejące rozwiązania lub robić je od zera z jakiegoś powodu, no i kłócić się o to, który język / framework / paradygmat jest lepszy, a praca sprowadza się do wciskania gotowych rozwiązań w nowe use case'y. Niby świat mamy bardziej uporządkowany, niż wtedy, gdy ludzie dopiero wymyślali i odkrywali podstawowe prawidłowości czy narzędzia, ale człowiek czuje, że jest pod ścianą i dalej nie pójdzie, a "odkrycia" sprowadzają się do owinięcia starych rozwiązań w nowe opakowanie i bardziej chwytliwą nazwę.

Ale może rozwój komputerów kwantowych coś popchnie do przodu, już od paru lat istnieje coś takiego jak np. działający w chmurze IBM Q Experience gdzie teoretycznie można się pobawić bramkami kwantowymi, gdzieś tam rozwijają Q# czy Quantum Toolbox for Python - mam nadzieję, że dzięki temu pojawi się trochę więcej "mięcha" nawet w tak zapadłej dziurze, jak Polska ;)

5

@Lubię Naleśniki z Dżemem: czego Ty w ogóle oczekujesz :D W wielu wątkach zachowujesz się jak gimbaza więc nie myśl sobie, że ktokolwiek kto zna się na tych wspomnianych algorytmach zechce z Tobą dyskutować. Nikt nie chce sprowadzać poziomu dyskusji pod Ciebie, ponieważ to jest poniżające.

5
superdurszlak napisał(a):

No i teraz mamy w sumie to samo, "wszystko lub prawie wszystko", co dało się wymyślić w kwestii klasycznej informatyki zostało już wymyślone, co najwyżej można usprawniać istniejące rozwiązania lub robić je od zera z jakiegoś powodu, no i kłócić się o to, który język / framework / paradygmat jest lepszy,

Powiedziałabym, że jest nawet gorzej, bo często zmienia się sprawdzone, wieloletnie rozwiązania na gorsze byle tylko coś zmienić, tylko po to, żeby pokazać, że coś się zmienia. Gdzieś tak do 2006-2010 oprogramowanie zmieniało się, bo sprzęt pozwalał na nowe możliwości. Nawet taka kontrowersyjna w sumie głupota jak Aero Glass pojawiła się, bo technicznie dało się zrobić coś, co dla starszych maszyn byłoby nierealne. Natomiast później desingem zajęli się styliści zaczęło się przerabianie obłego na kanciaste i na odwrót. I w dodatku to uzasadnienie, mówiące wprost, że użytkownicy są już otrzaskani z interfejsami, więc można je robić mniej czytelne ale zgodne z aktualną modą.

No a druga kwestia to to, że żeby zrobić taczkę, każdy bierze teraz podwozie z kombajna i instaluje na tym stosowną wtyczkę.

2

Tak trochę na marginesie: 20 lat temu marzyły mi się smartwatche. Wyobrażałam je sobie jako takie połączenie Casio Databank z programowalnym kalkulatorem Texas Instruments. Monochromatyczny ekran LCD, możliwość wgrywania i pisania dowolnych programów, łączność bezprzewodowa i - przede wszystkim - trzy lata pracy na baterii.

Natomiast, to co obecnie jest sprzedawane w powyższej kategorii kompletnie mnie nie wzrusza, ślepy, podświetlany ekran, kompletnie zbędny, rozbudowany system operacyjny, energożerny procesor i akumulatorek starczający na jeden dzień pracy. W dodatku robią właściwie tylko za dodatkowy ekran do smartfona i amulet dający +20 do szpanu.

3

Co do tematu ale nieco z innej beczki. To ja pracując w korpo obecnie zaczynam wątpić czy można cokolwiek skrytykować, wyrazić niechęć, nie zgodzić się, bo jeszcze ktoś mnie oskarży , że robię na kimś "blame". Coraz trudniej mi zrobić code review, bo ludzie zaczynają mieć coraz większy problem z byciem ocenianym.

Dyskusje o technologii są faktycznie miałkie, i często brak im argumentów. Gdy ja głównie skupiam się na ewentualnych tradeoffach itp. Część po prostu użyje X bo... ma na to ochotę.

0
rav3n napisał(a):

Dyskusje o technologii są faktycznie miałkie, i często brak im argumentów. Gdy ja głównie skupiam się na ewentualnych tradeoffach itp. Część po prostu użyje X bo... ma na to ochotę.

To tak jak ostatnio zasłyszana historia, o gościu, który chciał zaciągać 4kb lodasha do jakiejś pierdoły, która nie jest co prawda dostępna z poziomu samego JS ale jest do napisania w dwóch-trzech linijkach. Polski outsourcing jak widzę ma się dobrze.

1
Hispano-Suiza napisał(a):
rav3n napisał(a):

Dyskusje o technologii są faktycznie miałkie, i często brak im argumentów. Gdy ja głównie skupiam się na ewentualnych tradeoffach itp. Część po prostu użyje X bo... ma na to ochotę.

To tak jak ostatnio zasłyszana historia, o gościu, który chciał zaciągać 4kb lodasha do jakiejś pierdoły, która nie jest co prawda dostępna z poziomu samego JS ale jest do napisania w dwóch-trzech linijkach. Polski outsourcing jak widzę ma się dobrze.

Mniej więcej. Ja ogólnie miałem okazję ostatnio rozmawiać o graphql. Frontendowcy rozmawiali ze mną tak jakby to miało uleczyć raka. Zaznaczam, że nie krytykowałem użycia tego ale zwracałem uwage na rzeczy, które mogą być problematyczne. I że nie trzeba używać na dzień dobry wszystkich ficzerow tego, ale z rezerwą.

3

Dyskutować on czymś merytorycznie kiedy jest się w tym samym zespole to jeszcze prosta sprawa. W najgorszym przypadku tech-lead albo manager rozstrzygnie.

Gorzej kiedy wchodzisz do innego zespołu, masz tam mniej punktów doświadczenia i widzisz jak coś jest spartolone ale każda próba konstruktywnego zwrócenia uwagi kończy się "my mamy większe doświadczenie i wiemy, że tego nie da się zrobić lepiej".

Mam teraz takiego pecha, że przyszlo mi zaprojektować coś z takim jednym "seniorem" z innego zespołu. Koleś jest obiektywnie dość średni, kiedyś pisałem z nim jakiś kod i zrobił drabinkę 7 ifow na coś co można było ogarnąć jednym; twierdząc przy tym, że jego rozwiązanie jest prostsze. Tak, tak prostsze, że nie uwzględniało kilku przypadków brzegowych a dwa obsługiwane przypadki były źle (jak zwróciłem uwagę w review, to dorzucał kolejne ify).

Dobra, może to był wypadek przy pracy, historia. Może jest lepszym projektantem niż koderem. Pierwszy zrobiłem draft projektu, starając się uwzględnić wszystkie przypadki a zarazem zachować elegancką regularność i prostotę. Dostałem komentarz "to jest za skomplikowane i pewnie nie będzie działać". Konkretów brak.

Dzień później gościu stworzył swoją wersję. Owszem, 3x krótsza. Analizuję jego pseudokod i widzę, że jeden warunek będzie zawsze prawdziwy, i cały jeden komponent filtrujący coś tam jest przez to bez sensu, więc daje komentarz. Gościu poprawia wprowadzając deadlock. Wytykam deadlock. Za pierwszym razem nie łapie mojej analizy. Za drugim też nie. Podaje przykład. Załapał. Modyfikuje kod. Wprowadził coś w rodzaju NPE. Pseudokod jest niespójny. Co więcej powołuje się na nieoczywiste terminy niezdefiniowane wcześniej. Znowu wytykam. Dostaję odpowiedz "to nie jest kod źródłowy, tylko projekt i to się nie musi kompilować".

Wywiązuje się oczywiscie długa dyskusja która drogę wybrać i kolega często używa argumentów w stylu że "tak się nie da" albo "że jego jest prostsze" (jak się nie uwzględnia 90% przypadków brzegowych to nie ma się co dziwić, że jest prostsze), że "on to rozwijał 2 lata i z jego doświadczenia wynika, że tak będzie lepiej".
Widząc jednak jak ten moduł działa po tych dwóch latach, to mam poważne wątpliwości....

No i dyskutuj tu z takim....

1
rav3n napisał(a):

Co do tematu ale nieco z innej beczki. To ja pracując w korpo obecnie zaczynam wątpić czy można cokolwiek skrytykować, wyrazić niechęć, nie zgodzić się, bo jeszcze ktoś mnie oskarży , że robię na kimś "blame". Coraz trudniej mi zrobić code review, bo ludzie zaczynają mieć coraz większy problem z byciem ocenianym.

Dyskusje o technologii są faktycznie miałkie, i często brak im argumentów. Gdy ja głównie skupiam się na ewentualnych tradeoffach itp. Część po prostu użyje X bo... ma na to ochotę.

Jeśli ujmujemy rzecz w "byciu ocenianym" to z ludzie z reguły tego nie lubią. Gorzej kiedy godzą się code review i dalej mają problem z ocenianiem. Biorą to zbyt osobiście. Ja miałem okazję widzieć jak paru osobom ponad sto komentarzy ludzie dopisali. Czy się obrazili z tego powodu? Skądże!

Moim zdaniem dopóki wszyscy rozmówcy nie będą czuli, że wszyscy chcą przyczynić się do propagacji idei, dopóty ktoś się obrazi i zacznie nakręcać spiralę. W końcu ciężko poprawić humor komuś jeśli sobie się nie umie.

3

Ja się nie obrażam, jeżeli ktoś znajdzie w moim kodzie błąd albo kilka i mi je wytknie. Po to jest recenzja. Każdy popełnia błędy. Nawet fajnie, bo dzięki temu bug nie dojdzie do testów albo gorzej - klienta. Poprawiam, daję mikro-bonus autorowi wnikliwej recenzji i jedziemy dalej.

Gorzej, jeżeli wymiana zdań przy okazji konfliktu/recenzji zaczyna schodzić na tematy niemerytoryczne i rozmówcy zaczynają stosować argumenty personalne, tudzież argumentują kto ma większe doświadczenie itp. Na szczęście w moim zespole takie coś się jeszcze nie zdarzyło, ale jeśli by się zdarzyło to bym ostro interweniował.

1 użytkowników online, w tym zalogowanych: 0, gości: 1