Teoria czy praktyka - na co kładziecie większy nacisk?

3

W IT, podobnie jak w wielu innych dziedzinach, możemy poświęcić czas na zrozumienie problemu (rozpisanie algorytmu) i na jego praktyczne rozwiązanie (kod). Są nawet stanowiska, które leżą blisko krańców tego spektrum (umiem piękne wykresy, wiem):
screenshot-20210910115058.png
Teoretykiem może być architekt nie wnikający w to jak działa kod, profesor na uczelni obliczający złożoność kodu itp. Praktykiem może być junior, który sprawdza jak działa napisany przez niego kod i - jeśli działa - pisze program krok po kroku. To jednak są ekstrema. Podobnie jak przerzucanie się argumentami ad personam: "PHP hejtują głównie Ci co nie potrafią w nich pisać" - często są tak zwodnicze, że dyskusja zmierza na pola absurdu.
Pytanie zasadnicze: ile czasu poświęcacie na rozpisanie i zrozumienie problemu a ile na samo pisanie programu? Jakie są proporcje obu podejść?
Kolejna sprawa: doświadczenie doświadczeniu nie równe. Ktoś może pracować dziesięć lat i nie rozumieć co dzieje się pod spodem programu - rok powtórzony dziesięć razy. Inny z kolei może po roku intensywnej nauki rozumieć bardzo dużo i nie zostać przyjętym, bo nie ma doświadczenia. Czyli są rekruterzy, co myślą, że jak ktoś siedział z kodem ileś lat, to poświęcał ten czas na zrozumienie kodu. Coś tu nie gra ;)

2

Jeśli to możliwe, programuję małymi przyrostami, dlatego przeważnie nie ma jakiejś wielkiej filozofii w tym co robię. W czasie implementowania każdego kawałka widzę możliwe kontynuacje, więc potem już mniej czasu schodzi na teorię, bo w trakcie praktyki teoria się mieli w tle. ;)
Ale tylko w odniesieniu do twojego pytania. Ogólnie, teoria jest ważna i warto ją znać, czytać książki itd. Tyle, że po pierwszych kilku użyciach teorii, już wchodzi w krew i się nie myśli o tym zbyt wiele.

PerlMonk napisał(a):

Kolejna sprawa: doświadczenie doświadczeniu nie równe. Ktoś może pracować dziesięć lat i nie rozumieć co dzieje się pod spodem programu - rok powtórzony dziesięć razy. Inny z kolei może po roku intensywnej nauki rozumieć bardzo dużo i nie zostać przyjętym, bo nie ma doświadczenia. Czyli są rekruterzy, co myślą, że jak ktoś siedział z kodem ileś lat, to poświęcał ten czas na zrozumienie kodu. Coś tu nie gra ;)

Myślę, że w dużej mierze jest to heurystyka wynikająca z konieczności. Jak obiektywnie ocenić umiejętności programisty? A jeśli samemu jest się miernym programistą, to już w ogóle. :) Nie odpowiem na te pytania, bo nie mam dużego doświadczenia w rekrutowaniu.

1

"moje teoretyzowanie" ? to np takie cos :) ps rysunek z netaGPRS.gif

4

Klasycznie: to zależy. Czasem mam taska który jest prosty jak budowa cepa, siadam i zwyczajnie pisze od kopa. A czasami masz złożony problem który w ogóle nie bardzo wiadomo jak rozwiązać i trzeba kminić / przedyskutować z innymi ludźmi kilka godzin, a na koniec sama implementacja zajmuje kilkanaście minut.

5

Według mnie pierwszy post wątku, a postawione pytanie w ankiecie trochę do siebie nie pasują. Teoretykiem nie nazwałbym architekta ani kogoś, kto analizuje dany problem. Nazwałbym teoretykiem kogoś, kto zna dany język - i zna np w javie rodzaje garbage collectora, wie jak pod spodem działa HashMapa itp. A praktykiem nazwałbym kogoś, kto nie zna tych internali, po prostu "pisze i działa", dopóki ktoś nie zauważy błędu.

I w ankiecie zagłosowałem teoria i praktyka

7

Jedno i drugie jest potrzebne. Bo tak naprawdę jak masz jedno, to z czasem zdobędziesz drugie, a dopiero mając komplet będziesz pełnowartościowy.

Jeśli najpierw ogarniesz teorię, praktyki nabędziesz w trakcie pracy.
Jeśli z kolei jesteś samoukiem/masz wiedzę praktyczną, to teorię (jeśli będzie potrzebna) także dorobisz pracując.

Ale wybierając kogoś z doświadczeniem, ale "bez papierka" albo z wiedzą, ale bez doświadczenia - raczej bym się skłaniał ku temu pierwszemu.

screenshot-20210910131922.png

4

"W teorii nie ma różnicy pomiędzy teorią a praktyką. W praktyce – jest." ~~Yogi Berra

Myślę, że najlepiej znaleźć złoty środek ale kładę większy nacisk na praktykę starając się mieć z tyłu głowy jakieś podstawy teorii.

9

Zasadniczo to zajmuje mnie głównie praktyka - tak długo jak wszystko działa tak jak się spodziewam.
Nie znoszę magii, wiary, promieni kosmicznych i innego badziewia. Więc jak dochodzę do miejsca, gdzie jakieś czary powodują, że program raz działa raz nie to zaczynam zakuwać teorię.

1

Teoria. Wtedy dużo lepiej wypadam na rozmowach i dostaje więcej hajsu.

2

Programować można na trzy sposoby:
Wiedzieć jak ma coś działać w teorii, ale w praktyce nie umieć tego zaprogramować
Nie wiedzieć jak coś działa w teorii ale po prostu to zaprogramować.
Połączyć teorie z praktyką i nie wiedzieć jak coś ma działać i nie umieć tego zaprogramować.

1

Pytanie zasadnicze: ile czasu poświęcacie na rozpisanie i zrozumienie problemu a ile na samo pisanie programu? Jakie są proporcje obu podejść?

Czyli w tym przypadku TEORIA to po prostu analiza, rozpisanie i wycena zadania, a PRAKTYKA to prostu jego realizacja.
W tym przypadku poświęcam tyle czasu, ile jest wymagane aby je ukończyć. Nie każde zadanie, dla którego robię analizę trafia do mnie, nie każde zadanie które realizuję ma zrobioną analizę przeze mnie.

Natomiast zupełnie czymś innym są wiedza i umiejętności. W moim przypadku to maksymalnie dużo praktyki i minimum teorii.

4

w teorii na praktykę a w praktyce to nie wiem co robię

1

Nie bardzo rozumiem różnicę pomiędzy jednym a drugim. Jeżeli budujesz coś złożonego, to trzeba pomyśleć o algorytmie, zapewnieniu bezpieczeństwa, podziale na komponenty, wybrać narzędzia, zdefiniować interface'y dla komponentów, określenia architekturę każdego z nich, wreszcie napisać ten kod, zbudować go, monitorować działanie. Po drodze jeszcze trzeba wymyślić jak zespół, lub zespoły mają mieć zorganizowaną pracę, zapewnić infrastrukturę developerską (repozytoria, pajplajny, skanery), przygotować infrastrukturę dla poszczególnych środowisk, pomyśleć o planie testów. Nie wiem co z tego jest "teorią", a co "praktyką", bo zależnie od punktu widzenia można to wszystko przesuwać albo do jednej, albo drugiej szufladki.

Jeżeli za teorię uważasz wszystko co nie jest pisaniem kodu, to pewnie będzie to bardzo duży kawałek złożonego projektu. Lepiej przez 2 tygodnie wymyślać jak coś ma działać, niż pozwolić, żeby 20 osobowy zespół pracował przez pół roku nad zrobieniem czegoś, co nie ma szans zadziałać, albo osiągnąć po tych 6 miesiącach punkt krytyczny burdelu, gdzie dopisanie czegokolwiek (o czym było wiadomo od początku) jest niemożliwe.

W małych projektach oczywiście jest to prostsze. Np. pisałem kiedyś dużo aplikacji mobilnych, więc na rozpoczęcie kodowania wystarczał mi dzień dla każdej nowej - zrozumieć co ma robić, upewnić się, że nie ma czegoś nietypowego i kodować, bo to co trzeba było przemyśleć, zostało już przemyślane w 5 wcześniejszych projektach.

Pomyśl o wyszukiwarce Google - z jednej strony było tam mnóstwo teorii (Page Rank, przetwarzanie ogromnych ilości danych), powstało przy okazji parę doktoratów, ale ostatecznie okazało się to niezbędne do powstania wyszukiwarki, czyli było jednak praktyką.

1

W powszechnym rozumieniu teoria jest czymś w rodzaju suchej wiedzy, a praktyka implementacją. W nauce zaś teoria jest spójnym systemem aksjomatów i twierdzeń. Eksperyment oraz symulacja służą do testowania tych twierdzeń. Jedno bez drugiego nie może istnieć.

Programiści są natomiast z reguły inżynierami i wyrobnikami. Mamy pewne standardy i ich się trzymamy przy implementacji. Czy na budowie jeżeli ktoś wymyśli lepszą mieszankę cegły drogą eksperymentów to nazwiesz go teoretykiem? Na pewno architekt nie powinien być takim teoretykiem bo projekt nigdy nie zostanie ukończony. Według mnie architekt powinien być najbardziej doświadczonym programistą, praktykiem.

Jeżeli architekt zastanawia się całymi dniami nad P!=/==NP to projekt daleko nie zajedzie. Spolsky mówił o architektach bujających w obłokach. Ale nawet ich nie nazwałbym teoretykami bo ich teorie są często nieweryfikowalne. Bullshit, który sprzedają nie ma nic wspólnego z teorią w rozumieniu naukowym.

1

Zawsze byłem praktykiem i do tej pory zdecydowanie wole praktykę. Nie zmienia to faktu, że teoria sama w sobie jest nieodzownym elementem całego procesu i zwyczajnie warto wiedzieć pewne rzeczy. Przełoży się to na "sprawniejszą" praktykę ;)

4
PerlMonk napisał(a):

Pytanie zasadnicze: ile czasu poświęcacie na rozpisanie i zrozumienie problemu a ile na samo pisanie programu? Jakie są proporcje obu podejść?

Rozpisanie i zrozumienie problemu, to jest faza analizy w modelu wytwarzania oprogramowania. To jest praktyka, nie teoria.

2

Z mojego doswiadczenia niestety wiekszosc ludzi, ktorzy podaja sie za zdecydowanych "praktykow" to patologia. Mierni klepacze kodu, ktorzy klada framework na frameworku, a w praktyce nawet nie wiedza jakiego algorytmu uzywa sort() w pythonie, jak "traktowane" sa dane w wielowatkowosci i masy innych - wedlug nich "pierdół". W rzeczywistosci 99% tych ludzi to mierni klepacze kodu, ktorzy potrafia jedynie robic taski rozpisane od a do z. Wedlug mnie nie znac pewnych podstaw jak np ogolnego procesu kompilacji piszac w C++ to wstyd, a nie powod do uznawania sie za praktyka.

3

Praktyka to są dwie zasady:

  • działa? Nie ruszać
  • nieważne jak, aby działało
2

Programista to osoba, która przekuwa teorię na zera i jedynki. Pytanie "ile czasu myślisz nad problemem, a ile klepiesz kod?" to tak, jakby spawacza pytać "ile czasu siedzisz przy spawarce, a ile przy metalu?".

1

Teoretycznie teoria dziala...

0

Chyba nie można być programistą-teoretykiem.

3

W teorii cała wiedza o DDD jest zawarta w świętych księgach
W praktyce po przeczytaniu świętych ksiąg dalej często nie widać sensu używania DDD

2

Teoria jest zbędna jak nie potrafi się jej wykorzystać, moim zdaniem praktyka zawsze > teoria.

0

praktyka bez teorii jest slepa

teoria bez praktyki jest martwa

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