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 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0