Jaka jest różnica w wieloletnim doświadczeniu programisty w języku? [Zamknięte]

Jak stwierdzono w tytule, jaka jest różnica w wieloletnim doświadczeniu w danym języku pod względem programistów? Na przykład, jeśli jeden programista miał pięć lat pracy z językiem A, a drugi programista miał dwa lata pracy z językiem B, a następnie trzy lata z językiem A, czy byłaby zauważalna różnica między nimi?

"to zależy"

Doświadcz <> wiedzy lub zrozumienia.

Programista 1 może być bardzo dobry, nawet guru, lub może być kimś, kto grzebał w języku przez ostatnie 5 lat.

Programista 2 może być kimś, kto rozumie pojęcia niezależnie od używanego języka. Lub ktoś, kto uznał język B za trudny i ma nadzieję, że A będzie łatwiejszy.

Warto przeczytać „The Years of Experience Myth” z „ Kodowania horroru ”

To zależy.

Mam przyjaciela, który ma tendencję do trzymania się jednego języka, więc jeśli uważasz go za „programistę A”, to on ma pięciokrotnie doświadczenie w posługiwaniu się tym językiem.

Różne języki pozwalają robić różne rzeczy. Jeden esej, który szczególnie mi się podoba, nazywa się Paul Graham „ Beating the Averages ”. Próbuje w nim przekonać ludzi do nauki seplenienia, ale podaje także kilka bardzo użytecznych uwag:

Programiści bardzo przywiązują się do swoich ulubionych języków i nie chcę zranić niczyich uczuć, więc aby wyjaśnić ten punkt, użyję hipotetycznego języka zwanego Blub. Blub znajduje się w samym środku kontinuum abstrakcyjności. Nie jest to najpotężniejszy język, ale ma większą moc niż Cobol lub język maszynowy.

W rzeczywistości nasz hipotetyczny programista Blub nie użyłby żadnego z nich. Oczywiście, że nie programowałby w języku maszynowym. Po to są kompilatory. A jeśli chodzi o Cobola, nie wie, jak można cokolwiek z tym zrobić. Nie ma nawet x (wybrana funkcja Blub).

Tak długo, jak nasz hipotetyczny programista Blub patrzy w dół na kontinuum mocy, wie, że patrzy w dół. Języki słabsze niż Blub są oczywiście słabsze, ponieważ brakuje im niektórych funkcji, do których był przyzwyczajony. Ale kiedy nasz hipotetyczny programista Blub patrzy w drugą stronę, w górę kontinuum mocy, nie zdaje sobie sprawy, że patrzy w górę. To, co widzi, to tylko dziwne języki. Prawdopodobnie uważa ich za równoważnych mocy Blubowi, ale z tymi wszystkimi innymi włochatymi rzeczami. Blub jest dla niego wystarczająco dobry, ponieważ myśli w Blubie.

Kiedy jednak przejdziemy do punktu widzenia programisty używającego dowolnego z języków wyższych w kontinuum mocy, okazuje się, że on z kolei patrzy na Bluba. Jak możesz coś zrobić w Blub? To nawet nie ma.

Ogólnie rzecz biorąc, radzę uczyć się więcej niż jednego języka oraz poznać mocne i słabe strony języków.

Oczywiście programista, który ma więcej lat doświadczenia w jednym języku, lepiej zrozumie podstawowe biblioteki i osobliwości tego języka. Jeśli języki przyjmują ten sam paradygmat (imperatyw vs funkcjonalny), nie powinny mieć większych problemów z wybraniem tego języka poza uczeniem się go.

Największą trudność ze znalezieniem nowego języka miałem podczas próby przejścia z C # na Erlang, ponieważ reprezentował on nie tylko nową składnię, ale także nowy sposób myślenia o programowaniu.

Oto, czego oczekiwałbym / mam nadzieję:

1. Płynność - powinni być w stanie napisać więcej kodu z góry i mniej czasu na szukanie składni.
2. Poznaj różnicę między poprzednimi i obecnymi wersjami oraz sposób migracji kodu z jednej do drugiej.
3. Lepsze zrozumienie kompilacji, dystrybucji, testowania oraz tworzenia aktualizacji i poprawek.
4. Twórz / dołączaj dodatki do IDE i zyskaj z nich wydajność.

Języki nie są problemem. Możesz nauczyć się całego języka w ciągu kilku dni. Absorbowanie zajmuje więcej czasu, konwencje, interfejsy API i różne frameworki innych firm. Kiedy ludzie pytają o pięć lat X, nie dbają o język, chcą kogoś, kto ma duże doświadczenie w rozwiązywaniu problemów w tym języku i tak, aby nie musiał płacić za żadną krzywą uczenia się.

Fachowość i celowa praktyka.

Jeśli nie będziesz ćwiczyć celowo, nie zdobędziesz wiedzy specjalistycznej. (Musisz zbadać swoje błędy i je poprawić, ćwiczyć to, w czym jesteś słaby, a także pomóc ekspertowi, który powie ci, co robisz źle.)

Jeśli nie spróbujesz poprawić, możesz zostać nowicjuszem na zawsze!

Po dziesięciu tysiącach godzin świadomej praktyki zdobędziesz wiedzę specjalistyczną. (To odkrycie z edukacji / szkolenia dotyczy całej sieci.)

Jeśli twój programista A nie ćwiczy celowo, nigdy się nie poprawi.

Jeśli twój programista B nie ćwiczy celowo, nigdy się nie poprawi.

Jeszcze jedno odkrycie z tego samego badania: że jeśli mam 15000 godzin, a ty masz 10000, a ja dalej ćwiczę i ty też, nigdy nie będziesz lepszy ode mnie.

Znajomość dwóch języków prawdopodobnie sprawi, że B będzie lepszym programistą (z zastrzeżeniem zasad praktyki).

Zakładasz, że używasz ich w języku A? (Oczywiście, byłaby różnica w języku B.)

Zależy to częściowo od różnic między A i B (szczególnie jeśli skrócimy doświadczenie drugiego programisty z A). Jeśli są dość podobne, zasadniczo nie będzie różnicy w doświadczeniu. Jeśli A ma znacznie różne koncepcje, prawdopodobnie trzy lata są jeszcze wystarczające, aby się ich nauczyć. Biorąc pod uwagę bardzo dużą bibliotekę i skomplikowane narzędzia, może istnieć różnica między 3 a 5 lat.

Oczywiście najważniejsza jest tutaj jednostka. Dobry programista może dokładnie nauczyć się nowej platformy za trzy lata, więc nie powinno to stanowić problemu.

Zgodziłbym się, że język to język, a pojęcia to pojęcia.

Mój problem polega na tym, że obecnie jest wielu programistów, którzy bez zaawansowanego IDE nie mogliby w ogóle programować. Naprawdę nie są programistami, ale bardziej przypominają projektantów.

Wiem z własnego doświadczenia, że ​​wiele osób uwiodło upiorne środowisko programistyczne Microsoft. Nie jest źle, że upuszczają pole tekstowe na ekran, a następnie ustawiają właściwości za pomocą kreatora i przeciągają dane z obrazu bazy danych, ale czy naprawdę są programistami w dowolnym języku, jeśli wszystko, co robią, to konfigurują podstawowe testy równości?

Ci ludzie nigdy nie będą w stanie przyjąć Koncepcji, których się nauczyli i zastosować ich w innym języku.

Kiedy przeprowadzam wywiady z ludźmi, bardziej interesuje mnie to, w jaki sposób dokonali swojego rozwoju i jakich ram zastosowali. Lubię zadawać pytania typu „Jak napisać moduł obsługi zdarzeń?”, „Jak dokładnie umieszczasz dane w bazie danych?”, A nawet „Jak zmienić ten konkretny przycisk na fioletowy po kliknięciu?” to szybko wyeliminuje projektantów i opuści programistów. Przekonałem się, że 3 lub 4 lata faktycznego programowania z rokiem w moim wybranym języku są wystarczające na to, czego potrzebuję.

Po prostu kolejna opinia

Tal

„Lata doświadczenia w języku / platformie X” to w dużej mierze patologia rekrutacji ...

Jest otwarty na interpretację i nie jest tak przydatny, jak na pierwszy rzut oka. Jak powiedziano, mit lat doświadczenia jest dobrą lekturą.

Co najważniejsze, sam pomiar „lat doświadczenia” może być bardzo niedokładny. Oto przykład z mojego obecnego koncertu: moim głównym zadaniem jest opracowanie i utrzymanie aplikacji internetowej Java. Działa to jednak z zaplecza, którym jest MFC / C ++ / SQL Server. Dlatego też mam do czynienia z kodem C ++ praktycznie codziennie. ALE - to doświadczenie w C ++ jest względnie powierzchowne i zorientowane na konserwację, i tak naprawdę nie piszę już od podstaw całych dużych komponentów lub programów w MFC / C ++ (chociaż kiedyś w poprzednich rolach).

Czy nadal mogę zaliczyć te ostatnie 5 lat jako „5 lat doświadczenia w C ++”? Może. Może nie. W zależności od tego, jak chcę go sprzedać, aby zabezpieczyć określoną rolę, mogę z łatwością go obezwładnić bez kłamstwa lub przyznać, że nie było to tak naprawdę 5 solidnych „lat doświadczenia w C ++”. :) Jestem pewien, że wiele przypadków jest podobnych otwartych na tego rodzaju problem „niedokładności pomiaru”. Głębokość doświadczenia może rażąco obniżyć jakość doświadczenia. Zatem „X czasu spędzonego z C ++” nie znaczy wiele samo w sobie.

Tak, programista 1 nie ma znajomości składni języka B.

Koncepcje programowania są koncepcjami programowania. Język jest jedynie składnią.