Ile swobody powinien mieć programista przy wyborze języka i frameworka?

67

Zacząłem pracować w firmie, która jest głównie zorientowana na C #. Mamy kilka osób, które lubią Javę i JRuby, ale większość programistów tutaj lubi C #. Zostałem zatrudniony, ponieważ mam duże doświadczenie w tworzeniu aplikacji internetowych i ponieważ skłaniam się ku nowszym technologiom, takim jak JRuby on Rails lub nodejs.

Niedawno zacząłem od projektu budowy aplikacji internetowej z naciskiem na wykonanie wielu rzeczy w krótkim czasie. Lider oprogramowania podyktował, że używam mvc4 zamiast szyn. To może być OK, z wyjątkiem tego, że nie znam mvc4, nie znam C # i jestem jedynym odpowiedzialnym za tworzenie serwera aplikacji WWW i interfejsu użytkownika front-end.

Czy nie ma sensu używać frameworka, który już znam bardzo dobrze (Railsy) zamiast mvc4? Powodem tej decyzji było to, że lider technologii nie zna Jruby / rails i nie będzie możliwości ponownego użycia kodu.

Kontrargumenty:

  • Nie będzie uczestniczył w tworzeniu kodu i, szczerze mówiąc, nie jest potrzebny w
    tym projekcie. Tak więc nie ma znaczenia, czy on zna JRuby / szyny, czy nie.

  • W rzeczywistości możemy ponownie użyć kodu, ponieważ mamy wiele aplikacji Java, z których JRuby może pobierać kod i odwrotnie. W rzeczywistości poświęcił niektóre zasoby na konwersję biblioteki Java do C #, zamiast po prostu uruchamiać bibliotekę Java w aplikacji JRuby on Rails. Wszystko dlatego, że nie lubi Javy ani JRuby

Zbudowałem wiele aplikacji internetowych, ale używanie czegoś nieznanego powoduje pewne rozproszenie i nie jestem w stanie zbudować niesamowitej aplikacji w tak krótkim czasie, jak jestem przyzwyczajony. To by było w porządku; nauka nowych technologii jest ważna w tej dziedzinie. Problem polega na tym, że w tym projekcie musimy szybko wiele zrobić.

W którym momencie deweloper powinien mieć możliwość wyboru swoich narzędzi? Czy to zależy od firmy? Czy moja firma jest do kitu, czy jest to normalne? Czy istnieją bardziej zielone pastwiska? Czy patrzę na to w niewłaściwy sposób?

Spencer
źródło
45
„Odrzucanie rozkazów” czegoś takiego może być posunięciem ograniczającym karierę.
Dan Pichelman
39
Firmy lubią standaryzować narzędzia, ponieważ redukują koszty zarówno z punktu widzenia zakupów aplikacji, jak i zarządzania zasobami firmy. Zarządzanie licencjami jest w rzeczywistości dość czasochłonne. Ponadto, jeśli wszyscy używają własnego języka / wybranych narzędzi, możliwość przetasowania ludzi między miejscami pracy staje się znacznie trudniejsza. Wreszcie, twoje skargi dotyczące twojego przywództwa są identyczne z tym, dlaczego chcesz użyć wybranego narzędzia. Nie znasz mvc4 lub go nie lubisz. Sw lead jest leadem, więc jest to ich wezwanie, chyba że możesz przedstawić argument, który może zmienić ich zdanie.
Dunk
22
To wszystko powinno zostać rozwiązane podczas rozmowy kwalifikacyjnej.
user16764,
30
Jesteś programistą czy programistą Ruby ? Języki powinny być jak narzędzia. Niektóre mają mocne i słabe strony, ale od rzemieślnika zależy, jak najlepiej je wykorzystać. Firma podyktowała standardowy zestaw narzędzi z oczywistych powodów.

Odpowiedzi:

98

Powiedziałbym, że musisz porozmawiać z kierownikiem zespołu i powiedzieć coś takiego:

Wiem, że jesteście sklepem .NET, ale tak naprawdę zostałem zatrudniony do moich umiejętności Java / JRubyRails. Mogę zbudować nową aplikację w X czasie przy użyciu narzędzi, które już znam. Mogę nauczyć się C # / mvc4 tak, jak chcesz, ale zajmie to >> X czasu. Co chcesz?

To podnosi kwestię „umiejętności-you-were- (przypuszczalnie) -hired-for” kontra „umiejętności-you-need-teraz”, a także pokazuje, że jesteś w stanie nauczyć się nowych umiejętności, ale że będzie brać dłużej, aby opracować nową aplikację, ponieważ jesteś nowy w tym zestawie narzędzi. A ty nie chcesz pokazać, że jesteś chętny do nauki nowych umiejętności. Brak otwartości na naukę nowych umiejętności jest dobrym sposobem na zapewnienie, że twoje zatrudnienie zakończy się, gdy twoje umiejętności nie będą już potrzebne.

Co do twojego pytania na końcu:

W którym momencie deweloper powinien mieć możliwość wyboru swoich narzędzi? Czy to zależy od firmy? Czy moja firma jest do kitu, czy jest to normalne? Czy istnieją bardziej zielone pastwiska? Czy patrzę na to w niewłaściwy sposób?

Zwykle zależy to od firmy. Jeśli firma kupi narzędzia MS i standaryzuje wszystko na platformie VisualStudio i frameworku .NET, może być bardzo niewygodne, jeśli jeden programista nalega na użycie Linuksa i C. Jest to normalne. Mogą istnieć wyjątki, gdy firma jest mniej wybredna wobec redaktorów, na przykład pozwalanie programistom na wybranie Vi vs. Emacs, pod warunkiem, że wyniki są takie same. Wiem, że niektóre firmy pozwalają nawet programistom wybierać system Windows vs. Linux, ale język, w którym pracują, ma bardzo dobre wsparcie i środowiska wykonawcze dla obu systemów operacyjnych.

Dlaczego firmy to robią? Spójność jest jednym z powodów. Debugowanie rzeczy może być bardzo trudne, gdy aplikacja jest mozaiką plików binarnych zbudowanych w ulubionych językach / ramach różnych programistów, wbudowanych w różne narzędzia i przetestowanych na bardzo różnych systemach. Jeśli wszyscy programiści pracują w większości na podobnych konfiguracjach, tego rodzaju problemy zostaną rozwiązane.

W twoim przypadku wygląda na to, że zostałeś zatrudniony do pracy w technologii, która jest niestandardowa w tej firmie. Wydaje mi się to dziwne i możesz porozmawiać z osobą, która cię zatrudniła, o tym, dlaczego tego chcieli.

FrustratedWithFormsDesigner
źródło
31
„Mogę zbudować tę nową aplikację w X czasie za pomocą narzędzi, które już znam. Mógłbym nauczyć się C # / mvc4 tak, jak chcesz, ale zajmie to >> X czasu. Czego chcesz?” - Świetna odpowiedź. Ustaw go w formie kompromisu kosztowego.
Christian Ternus
Zgoda. Chodzi o ekonomię. Gdy już spojrzysz ekonomicznie na swój punkt widzenia, ŻADNY prowadzący, który jest prawdziwy, wysłucha cię i ponownie rozważy swoją postawę. Wyjaśnij kompromis: Np .: więcej czasu oznacza, że ​​rzeczy nadejdą później, że termin może być przekroczony, co oznacza uderzenie w przychód . Czasami muszą w istocie wskazać ścieżkę do celu „wymiany”.
Dr
6
+1. Jedynym sposobem, w jaki ta odpowiedź mnie nie satysfakcjonuje, jest to, że nieco odznacza aspekt nauki. Deweloper, który chce się uczyć, jest o wiele bardziej wartościowym zasobem niż ten, który wie wszystko o jednym i nie zmieni się .
Corey
7
+1 Chciałbym również podkreślić (domyślny) punkt, że jeśli lead zdecyduje się pójść z MVC, OP jest zobowiązany do zapięcia się i wykonania projektu w MVC.
Dan Lyons
„Niektóre firmy pozwalają nawet programistom wybierać system Windows kontra Linux” - a także często można spotkać użytkowników komputerów Mac w świecie Ruby. (Moja firma jest głównie sklepem z Ruby, ale nie ma żadnych ograniczeń dotyczących edytora lub systemu operacyjnego - a teraz mamy programistów używających Linuksa i Maca, ale obecnie nie ma programistów z komputerami z systemem Windows).
Ben Lee
140

W którym momencie deweloper powinien mieć możliwość wyboru swoich narzędzi?

Kiedy nie wpływają na twój zespół.

Czy patrzę na to w niewłaściwy sposób?

Absolutnie.

Tak, masz krótki termin. Tak, możesz to zrobić szybciej w Railsach. Ale firma jako całość musi wdrożyć i utrzymywać aplikację. Jeśli firma ma stabilną grupę dobrych programistów C #, prawdopodobnie utrzymanie aplikacji w języku C # będzie prawdopodobnie tańsze (i przyniesie lepszą jakość).

Twoi DBA i inni pracownicy administracyjni prawdopodobnie znają ten stos i dysponują procesami wdrażania i aktualizacji tego stosu. Nawet jeśli możesz wykonać kod szybciej, może to potrwać dłużej, jeśli weźmiesz pod uwagę wszystkie koszty związane z uruchomieniem profesjonalnej aplikacji internetowej.

Pamiętaj, że poświęcisz znacznie więcej czasu na utrzymanie aplikacji niż jej pisanie. Zoptymalizuj ten koszt.

Telastyn
źródło
19
Świetna odpowiedź. „Najlepsze” w tym przypadku może nie oznaczać optymalizacji w celu jak najszybszego początkowego opracowania , szczególnie dla początkowego programisty . Z perspektywy biznesowej aplikacja będzie prawdopodobnie poświęcać znacznie więcej czasu w trybie konserwacji i obsługiwana przez cały zespół , więc to powinno być podstawą decyzji ramowej.
Eric King,
4
Myślę, że jest to ogólnie dobra rada. Nie wybrałem go jako odpowiedzi, ponieważ w moim szczególnym przypadku wiele obaw nie ma zastosowania. Będę odpowiedzialny za skonfigurowanie wdrożenia i wdrożenie aplikacji. Zdecydowanie zgadzam się z częścią dotyczącą utrzymania, jest to ważna kwestia. Kto wie, gdzie będę za kilka lat, kiedy ktoś będzie musiał zaktualizować kod.
Spencer
2
Prawdopodobnie NIE zostałeś zatrudniony za swoje umiejętności JRuby / Rails, ale zostałeś zatrudniony za doświadczenie w tworzeniu aplikacji internetowych, a oni tak naprawdę chcą wykorzystać to w kontekście MVC4 i C #.
Jay Stevens
Chociaż zdobywasz dobre punkty, nadal nie ma sensu, aby facet, który nie ma doświadczenia na tym stosie i prawdopodobnie nie jest nim zainteresowany, zrobiłby to. Dlaczego nie zmusić jednego z facetów C # do zrobienia tego? Wszystko, co zrobią, to sprawi, że ten facet poczuje się, jakby nie był właścicielem swoich projektów, sprawi, że poczuje się wypalony i doprowadzi go do odejścia z firmy.
s73v3r
@ s73v3r - Mam nadzieję, że OP wiedział, w co się pakuje. Szczerze mówiąc, jeśli masz mnóstwo twórców C # (i bazy kodu), to powinno to być oczywiste dla faceta Railsów podczas wywiadu. Jeśli
podjąłby
41
  1. Najwyraźniej zostałeś zatrudniony z powodu swojej zdolności do przystosowania się do „nowych” technologii. C # nie różni się pod tym względem. Czy na pewno nie chcesz skorzystać z okazji, aby nauczyć się czegoś nowego?

  2. ASP.NET MVC jest pod wieloma względami bardzo podobny do Ruby on Rails.

  3. Nie będziesz wiecznie w tempie ślimaka. Jeśli znasz już ROR, ASP.NET MVC będzie dla Ciebie świetny. Sztuką jest nauka języka C #.

Robert Harvey
źródło
18
+1, wiązanie się z jednym językiem / strukturą jest głupie. Skorzystaj z okazji, aby otrzymać zapłatę za naukę nowych rzeczy. A .NET ma wiele aktywnych i interesujących prac rozwojowych.
jozefg
Zgadzam się, że są one podobne, ale istnieją znaczące różnice, które mogą zsumować się do wielu godzin. Biorąc pod uwagę skończoną liczbę godzin dla projektu, myślę, że szyny to oczywisty wybór. Nie jestem przeciwny uczeniu się nowych rzeczy, jak wspomniałem w pytaniu.
Spencer
Punkt 1 nie jest oczywisty - OP mówi, że zostali zatrudnieni z powodu doświadczenia Java / JRuyb / Rails / nodejs: Zostałem zatrudniony, ponieważ mam duże doświadczenie w tworzeniu aplikacji internetowych i ponieważ skłaniam się ku nowszym technologiom, takim jak JRuby on Rails lub nodejs. OP nie mówi o ich zdolności adaptacyjnej ani o tym, że ich zdolność adaptacyjna jest powodem, dla którego zostali zatrudnieni.
FrustratedWithFormsDesigner
2
+1, zgadzam się, nigdy nie rozumiałem argumentów gatunku „Wiem doskonale, jak zrobić A w języku L1, ale zupełnie nie mogę tego zrobić w języku L2”.
Shivan Dragon,
2
@Spencer: Gdy poprosisz nas o radę, a każda osoba udziela ci tej samej porady, prawdopodobnie powinnaś ją przyjąć. Nie ma sensu kłócić się z odpowiedziami, kiedy przyznajesz, ale zadajesz pytanie, że nie wiesz, jaka jest prawidłowa odpowiedź.
Andrew Coonce
21

Argumenty za pozostaniem w Javie / JRuby

Możliwe, że twój szef chce, abyś produkował. Zatrudnili cię, abyś mógł zwiększyć wartość firmy. Upewnij się, że rozumieją, że zmusza do korzystania z ram, że nie znają oni będą powodować:

  1. Twórz wyniki wolniej
  2. Utwórz kod niższej jakości

Nawet najlepsi programiści potrzebują czasu na rozgrzanie w nowych językach / ramach.

Argumenty do nauki MVC4 i C #

Nauka nowych języków jest dobra. Inwestowanie w swoje umiejętności programistyczne jest ryzykowne tylko wtedy, gdy język / platforma, której się uczysz, zniknie w najbliższej przyszłości, a biorąc pod uwagę, że Microsoft się z tobą bawi, nie sądzę, żeby to był problem. Zarówno C #, jak i MVC mają najnowsze aktualizacje, które poprawiły je oba, a kolejne aktualizacje są w przygotowaniu.

Sprawiając, że staniesz się osobiście bardziej dopracowanym programistą, nigdy więcej nie znajdziesz się w takiej sytuacji. Najlepsza część? Twój szef zapłaci ci za naukę tych rzeczy, co oznacza, że ​​zarabiasz, aby zarobić więcej pieniędzy.

Dolna linia

Możesz wygrać tę walkę, ale pozostanie ci praca z niezadowolonymi kolegami. Po prostu wyjaśnij swojemu menedżerowi zalety i wady każdego z nich, a wtedy oboje wyjdziecie szczęśliwsi.

Ampt
źródło
11
+1 ”, co oznacza, że ​​zarabiasz, aby zarobić więcej pieniędzy” bingo!
GrandmasterB
Jak to wskazuje (i kilka odpowiedzi), istnieje kompromis między początkowym tworzeniem czasu a wdrażaniem / konserwacją przez wszystkich innych. Podejmij przyzwoity (ale pełen szacunku) wysiłek, aby sprawdzić, czy Spiczaste Włosy są skłonne dokonać tego handlu, ale jeśli nie, tylko uszanuj ich decyzję i ciesz się zarabianiem za naukę czegoś nowego w czasie pracy w firmie.
brichins
@brichins: Myślę, że jednym z głównych problemów z tą odpowiedzią jest to, że tak naprawdę nie wskazuje ona na to, co mówisz!
ruakh
@ruakh Miałem problem z ustaleniem, na którą odpowiedź pozostawić ten komentarz - masz rację, ta nie odnosi się do tego konkretnego kompromisu (chociaż wskazuje na napięcie w miejscu pracy, które może wyniknąć). Prawdopodobnie powinienem był również wyraźnie powiedzieć, że PO powinien być pewien, że rozmawiał ze wszystkimi decydentami (bez przekraczania czyjejś głowy), aby, jeśli / kiedy projekt nie dotrzyma terminu, mógł grzecznie przekazać „Powiedziałem ci front, który prawdopodobnie by to zrobił. Może zamiast tego w następnym projekcie możemy spróbować Ruby?
brichins
18

W którym momencie deweloper powinien mieć możliwość wyboru swoich narzędzi?

Gdy wspomniany programista jest liderem oprogramowania.

Z pewnością możesz (i powinieneś) uzasadnić użycie innego zestawu narzędzi, jeśli martwisz się produktywnością, ale bądź przygotowany na odpowiedź, której nie polubisz. Może istnieć cholernie dobry powód, dla którego Twój lider chce, abyś używał określonego zestawu narzędzi, czy to kompatybilność z obecną architekturą, obawy dotyczące konserwacji, problemy z licencjonowaniem itp.

BTW, fraza

z naciskiem na zrobienie wielu rzeczy w krótkim czasie

odpowiada za więcej zgagi i zamętu w branży oprogramowania niż za wszystko inne.

John Bode
źródło
2
+1 „Gdy wspomniany programista jest liderem oprogramowania”. Dokładnie. Czasami, kiedy kłócisz się o swój punkt, a Twój Partner nie zgadza się z tobą, dzieje się tak, ponieważ Twój Partner ma lepszy widok na ogólny obraz. To jedna z tych sytuacji.
Andrew Coonce
Nie zgadzać się. W ten sposób poprowadzisz swoich podwładnych do niczego innego, niż zwolenników, którzy zapomną, jak podejmować decyzje i brać za nie odpowiedzialność. Jeśli tego chcesz - w porządku. Myślę, że są miejsca, w których ludzie będą mądrzejsi niż ty jako lider zespołu. Ale tak, niektórzy ludzie mają z tym problem, a to tragiczne.
JensG
Poważnie wyśmiałem twoją odpowiedź na „jest odpowiedzialny za więcej zgagi i zamętu w branży oprogramowania niż cokolwiek innego.” ... dziękuję! Nie mógłbym tego lepiej sformułować!
Alexus
11

Zauważam, że nie mówisz, że zostałeś zatrudniony jako programista JRuby lub Java.

Oto dlaczego powiedziałeś, że zostałeś zatrudniony: „[B] ponieważ mam duże doświadczenie w tworzeniu aplikacji internetowych i dlatego, że skłaniam się ku nowszym technologiom, takim jak JRuby on Rails lub nodejs.”

Innymi słowy, podoba im się Twoje doświadczenie w Internecie i chęć uczenia się nowych technologii.

Teraz proszą Cię o korzystanie z Internetu i naukę nowej technologii.

Pytanie brzmi: czy zamierzasz to zrobić, czy nie?

Kyralessa
źródło
9

Największy koszt oprogramowania polega na jego utrzymaniu

Przeczytałem, że największy koszt (80%) to utrzymanie oprogramowania. Początkowy rozwój to tylko 20% całkowitych kosztów rozwoju.

Czytałem przypadek o deweloperze, który opracował kod i komentarze w swoim ojczystym języku (nie angielskim), a kiedy inni członkowie zespołu udoskonalili i utrzymali kod, było to prawie niemożliwe, ponieważ język (nie żaden język programowania) był obcy do nich.

Podobnie, jeśli opracujesz kod w wybranym przez siebie języku programowania, pozostanie innym członkom zespołu byłoby trudne do utrzymania.

Rozwiązanie: programowanie w parach

Zastanów się, czy nie poprosić pracodawców o powiązanie cię z kimś, kto zna wymagany język programowania i możesz współpracować. Możesz uczyć się od siebie nawzajem, a jeśli jedno z was opuści firmę, drugi zna kod.

Artykuł w Wikipedii na temat „Programowania par”: http://en.wikipedia.org/wiki/Pair_programming

Kaydell
źródło
3
Jeśli napiszesz coś, co tylko Ty rozumiesz, utkniesz w utrzymaniu tego na zawsze.
jwernerny
6

Wiele firm po prostu woli trzymać się tego, co zawsze robili, lub tego, co jest „bezpieczne”. Jest powód, dla którego Java i PHP są nadal bardzo popularne. W tej chwili wyszukanie „COBOL” na rzeczywiście.com zwraca 2144 ofert ... co powinno naprawdę mówić samo za siebie. W branży nie zależy na dobrym kodzie, zależy mu na kodzie, który może doić tak długo, jak to możliwe (nie oznacza to, że C # jest zły, a tak naprawdę nie jest).

Pomyśl o tym: kod przetrwa. Istnieje duża szansa, że ​​ktoś zachowa Twój kod, a C # jest bezpieczniejszym rozwiązaniem niż Node.js i Rails. Nie zdziwiłoby mnie to, gdyby za 5 lub 6 lat liczba programistów Rubiego zmniejszyła się o połowę, po tym wszystkim, co przytrafiło się Perlowi i innemu językowi, który w pewnym momencie był uważany za język „it”. JavaScript prawdopodobnie nie zniknie, ale już zaczynamy widzieć, że jest używany jako swego rodzaju ASM (lub nawet C) sieci - język pośredni, który inne języki mogą skompilować, aby napisanie w nim kodu po stronie serwera mogło bardzo dobrze stają się przestarzałe.

Gomi
źródło
4
Chociaż jest to prawdą, dość słabą praktyką rekrutacyjną w sklepie C # jest zatrudnienie programisty Ruby, który nie zna C #, bez wyraźnego wyjaśnienia, że ​​praca, do której jest zatrudniony, polega głównie na rozwoju C #.
Carson63000,
5

Moją główną troską związaną z tym, że programiści wybierają sposób realizacji swoich celów, jest to, że zwykle zakładają, że tylko będą edytować kod. Spójrz na to w ten sposób, 12 miesięcy później mogą potrzebować zmian; nie jesteś dostępny (opuściłeś firmę lub naprawdę zajęty innym zadaniem), a inny programista musi zrezygnować z kodu. Jeśli jest to sklep C #, to korzystanie z ich zestawu narzędzi jest dobrą pracą zespołową. Nowe technologie powinny być badane i wdrażane, ale tylko wtedy, gdy kierownictwo uzna, że ​​czas jest odpowiedni, ponieważ mają oko na wiele celów, a nie tylko jeden.

daveD
źródło
3

Proszę to odwrócić. Wyobraź sobie, że zatrudniasz programistę Ruby, a oni nalegają na wdrożenie swojej pracy w Asp.net/MVC.

Co byś im powiedział? To jest nasz stos, stary. Naucz się z tym żyć.

Złota zasada, oto ona, która ma złoto, ustanawia reguły.

Warren P.
źródło
1
Ale dlaczego miałbyś zatrudnić kogoś, kto nalega na użycie .NET do roli Ruby?
Bobson
3
@ Bobson, ponieważ są bystrym młodym programistą, który wydaje się być w stanie rozwiązać problemy z wieloma różnymi technologiami, zadowalająco rozwiązał ogólne problemy z programowaniem i złożyli podanie o pracę.
2
@ Bobson: Więc teraz argumentujesz, że firmy nie powinny zatrudniać programistów, którzy nie mają doświadczenia w wybranym języku firmy. Wszyscy inni zdają się kłócić w drugą stronę, twierdząc, że mogą naprawdę szybko nauczyć się nowego języka, więc firma nie powinna przekazywać dobrego programisty tylko dlatego, że nie jest ekspertem w konkretnym języku ... jeszcze.
Dunk
2
Zostałem zatrudniony, ponieważ mam duże doświadczenie w tworzeniu aplikacji internetowych i dlatego, że skłaniam się ku nowszym technologiom, takim jak JRuby on Rails lub nodejs”. - nie został zatrudniony jako programista XYZ, jest to „zatrudniony jako programista z doświadczeniem w nowszych technologiach” (że firma może być zainteresowana aktualizacją rzeczy w przyszłości).
3
@ Bobson: Kiedy jestem zatrudniony w nowej firmie, nie tylko wiem, co przynoszę do stołu, ale także wiem, nad jakim projektem będę pracować i czego ode mnie oczekują. Jeśli OP nie będzie miał kłopotów z uzyskaniem tych informacji, wstydź się. Biorąc to pod uwagę, myślę, że tak naprawdę jest to przypadek zatrudniania przez kogoś kogoś, kto uważa, że ​​jest dobrym programistą z odpowiednią wiedzą na temat domeny, aby mógł pomóc zespołowi, a oczekiwanie, że wybranie rzeczy mvc4 będzie niewielką przeszkodą. Może firma nie wyjaśniła tego zbyt dobrze, ale OP również nie zrobił swojej roli.
Dunk
2

Istnieje wiele sprzecznych celów, a problemem jest znalezienie najlepszego kompromisu. Mamy termin, mamy kierownika zespołu, który żąda określonego zestawu narzędzi, i mamy programistę niedoświadczonego z tym zestawem narzędzi, ale skazanego na wyprodukowanie czegoś w (oczywiście krótkim) terminie.

Ważne jest, aby zrozumieć, że kierownik zespołu ma prawdopodobnie kilka dobrych powodów, dla których żąda dokładnie tego zestawu narzędzi (jednym z nich może być rzeczywiście przyzwyczajenie się do tego zestawu narzędzi z jakiegoś powodu, którego jeszcze nie znasz). Najlepsze, co możesz zrobić przy pierwszym uruchomieniu, to dowiedzieć się, jakie dokładnie są te powody.

Postawmy na twoim stanowisku, spróbuję porozmawiać z kierownikiem zespołu i wyjaśnić sytuację, jaka jest Twoim zdaniem, oraz opcje i jaki wynik (w tym krótko- i długoterminowe efekty ekonomiczne) zostaną wygenerowane postępując zgodnie z każdą z tych opcji. Na przykład może zostać wyznaczony inny, bardziej doświadczony programista, który będzie cię trenować, być może z sesjami programowania w parach lub podobnymi.

O ile kierowanie zespołem nie jest kompletnym kretynem, powinieneś być w stanie znaleźć konsensus, który ma sens w odniesieniu do projektu i ogólnych celów firmy.

JensG
źródło
2

Bah. Wszyscy się mylą.

Bądź lepszym twórcą niż ludzie z jednej platformy, a będziesz mieć o wiele ciekawsze opcje niż kiedykolwiek. Na razie więc naucz się MVC. A we własnym czasie dowiedz się więcej o platformach, które naprawdę Cię interesują. Rozwijaj swoje umiejętności węzłowe. Naucz się Django. Zwróć uwagę na wszelkie shenanigany Java lub wcześniejsze MVC .NET, na które jesteś narażony, a następnie uciekaj, ale przynajmniej naucz się wystarczająco, aby móc krytykować i wyjaśniać, ile myśli włożyłeś w ledwo ukryte uprzedzenia związane z nienawiścią tych platform. (okej, może tam wyświetlam)

A teraz ważna rada. Jeśli nadal będziesz doskonalić swoje specjalizacje, jednocześnie dywersyfikując swoją wiedzę w innych obszarach, w końcu znajdziesz się w miejscu, w którym możesz znaleźć nową pracę o każdej porze roku w mniej niż dwa tygodnie w dowolnym większym mieście, robiąc rzeczy, które są najbardziej interesujące co najmniej w połowie czasu. Kiedy znajdziesz się w tym miejscu, nie godzi się na pracę, w której mówią, że tego chcą, a do drugiego dnia robią to, ŻE bez nadziei na ulgę przewidywalną w długiej perspektywie. Po prostu grzecznie wyjaśnij i przeproś, ale nie, naprawdę nie chciałeś tego robić i powiedziałeś tyle w swoim wywiadzie, a potem! @ # $ Ing przestań i ruszaj dalej, gdy upłynie kilka tygodni i nieuchronnie nie zrobili nic, aby pomieścić fakt, że przedstawili ci fałszywe stanowisko i odmawiają uznania tego.

Ale zaufaj mi, znalezienie nowego koncertu jest zawsze o wiele lepsze niż bycie poważnie zirytowanym i nieszczęśliwym przez jakikolwiek czas dłuższy niż 5 minut. Ale oczywiście najpierw musisz zapłacić swoje składki, abyś mógł to zrobić. Niektórzy ludzie nigdy tego nie zrobią. Dlatego chcą wszystkiego, co znają najlepiej. I oczywiście inne odpowiedzi nie są tak naprawdę błędne. Ma sens, aby sklep .NET współpracował z .NET, jeśli muszą zachować głupie rzeczy.

Oczywiście nie ma sensu, dlaczego dywersyfikują się za pomocą dewelopera Rails / JS / UI i mają tylko do robienia aplikacji MVC. Ale teraz. Być może będziesz musiał go odebrać i spłacić swoje składki. I jak powiedziałem w komentarzach, MVC naprawdę nie jest takie złe. Naprawdę zły wybór, biorąc pod uwagę wszystkie opcje, ale na pewno nie najgorszy. Jest to całkiem proste, nie rzuca 10.000 warstw abstrakcji na wszystko, co się faktycznie dzieje, i nie jest tak przekręcone po stronie klienta, że ​​przekląłbyś nazwiska inżynierów MS odpowiedzialnych, gdyby ktokolwiek mógł się niepokoić uczyć się ich.

Więc dotrzyj do tego miejsca, w którym możesz odejść, kiedy chcesz, jeśli jeszcze tego nie zrobiłeś, a może nawet okaże się, że masz bardziej sceptyczne spojrzenie na rzeczy, które obecnie lubisz. Możesz nawet nie lubić szyn tak samo jak ja. Nie chodzi o to, że z Ruby jest coś nie tak (oczywiście poza tłumaczem).

Erik Reppen
źródło
1

W zależności od twojej sytuacji może być niebezpieczne założenie, że wiesz, dlaczego cię zatrudnili, a tym bardziej założenie, że twój kierownik wie o tym i zgadza się, że zatrudnianie osób posiadających twoje umiejętności jest dobrym pomysłem.

Poprosiłbym o skorzystanie z powyższej porady i uzasadnienie biznesowe, dlaczego powinieneś pójść z JRuby nad C #, może twój argument i ramy czasowe oznaczają zerwanie ze starymi sposobami ma sens. Nie zakładałbym po prostu, że jest w porządku, czy nie, przekazał kierownikowi lub poprowadził fakty i pozwolił im podjąć decyzję, to po co im płacą duże dolary plus trochę CYA.

Scott S.
źródło
1

Moim szczerym zdaniem, jedną rzeczą, która odróżnia dobrych programistów od wielkich, jest ich zdolność do przystosowywania się do nowych technologii. Żyjemy w dynamicznym świecie, w którym dzisiejsza najlepsza technologia stanie się jutro przestarzała. Dlatego deweloper, który nie chce się dostosować, ma ograniczone zastosowanie dla firmy. Byłoby dobrze, gdyby nie fakt, że znalezienie i zatrudnienie dobrych ludzi jest naprawdę bardzo trudne, a kiedy firma znajdzie swój klejnot, planuje na dłuższą metę.

Widziałem firmy zatrudniające się poza zakresem technologii i robią to z tego samego powodu. Chcą zdobyć świetnych programistów, nawet jeśli oznacza to czekanie na dostosowanie się do nowych technologii.

Teraz twoja sytuacja. Jako nowy facet w grupie byłbym bardzo ostrożny co do tego, co mówię, a nie do moich przełożonych. Jasne, że uciekniesz od wielu rzeczy w oparciu o założenie, że wciąż jesteś w trakcie dostosowywania się do nowego środowiska. Jednak podważenie autorytetu i upartej wytrwałości w preferowanej technologii sprawi, że przełożeni będą myśleć, że popełnili błąd, zatrudniając cię i że nie chcesz opuścić strefy komfortu.

To, co wybierzesz, zależy od ciebie, ale proponuję, abyś spróbował nauczyć się nowej technologii. Nie zaszkodzi, obiecuję.

Vladimir Kocjancic
źródło
1

Zakładam, że byłeś szczery podczas wywiadu na temat braku wiedzy na temat C #, ponieważ jeśli tak nie było, możesz być w bardzo niepewnej sytuacji z prawnego punktu widzenia.

Dobrzy programiści znają programowanie. Podczas gdy nikt nie może być oczywiście dobrze obeznany we wszystkich językach i ramach, istnieje znaczna podobieństwo między większością z nich. Jeśli nie zostaniesz poproszony o pracę w języku, który znacznie różni się od tego, co stanowi obecnie główny nurt (na przykład Lisp), dobry programista powinien być w stanie się przystosować.

Oczywiście jest krzywa uczenia się. Jeśli pracodawca cię zatrudnił, musi mieć pewność, że potrafisz postępować zgodnie z tą krzywą w rozsądnym czasie (ponownie, zakładając, że byłeś szczery z góry, jeśli nie znasz C #). Język C # pożycza dużo od Javy, a bardziej ogólnie, większość języków programowania opartych na klasach jest zasadniczo całkiem podobna (wspomniałeś o node.js, który opiera się na ECMAScript, który jest językiem opartym na prototypach, więc oczywiście jesteś wygodne z innymi paradygmatami programowania.

Dobrzy programiści powinni nie tylko być elastyczni, ale także chętni do uczenia się nowych rzeczy. Podczas tworzenia oprogramowania zazwyczaj uczysz się lub przestajesz mieć znaczenie.

Oczywiście twój pracodawca, zakładając, że wiedział, że nie znasz C #, musi się z tobą spotkać w połowie drogi. Jeśli wykażesz ochotę do nauki, muszą dać ci czas i środki, aby to zrobić. Wrzucanie cię do głębokiego końca jest niesprawiedliwe i niepotrzebnie stresujące. Musisz usiąść i odbyć spokojną, racjonalną dyskusję z przełożonym. Jeśli chcą tego w języku C #, muszą być gotowi zaakceptować, że będziesz na krzywej uczenia się podczas pracy nad tym i niesprawiedliwe byłoby narzucanie ci ścisłych terminów. Jeśli terminy nie są elastyczne i mają duże znaczenie strategiczne, należy je przygotować, aby pozwolić sobie na pewną swobodę w wykonywaniu pracy w tym terminie. Jeśli potrzebują w swoim biurze bardziej popularnego języka, być może możesz poprosić o wdrożenie go teraz w tym, co „ zna się na dotrzymywaniu terminu, a następnie jako kolejny projekt ponownie wdrożysz go w języku C # jako ćwiczenie edukacyjne i dostosujesz oprogramowanie do wymagań wewnętrznych, gdy tylko spełni zewnętrzne. Tak jak powiedziałem, większość dziś najczęściej używanych języków ma wiele cech wspólnych, więc sprowadzają się one głównie do szczegółów implementacji.

Musisz być przygotowany na to, że prędzej czy później zaakceptujesz, że pracujesz w sklepie C #, a zatem musisz mieć C # za pasem.

GordonM
źródło
0

Może nie są zadowoleni ze sposobu, w jaki wszyscy używają MVC w środowisku .NET. Zbyt wiele może być traktowane jak formularze internetowe. Nie inaczej jest, gdy ktoś z wykształceniem proceduralnym zaczyna w OOP, umieszcza wszystko w jednej dużej klasie i kontynuuje biznes jak zwykle.

Ten pierwszy projekt nie jest idealną sytuacją, ponieważ chcą, aby zostało to zrobione tak szybko. Zdobądź jak najwięcej szybkości w .NET i zacznij jak najszybciej uruchamiać funkcje. Nie spodoba ci się sposób, w jaki to robisz, po prostu pamiętaj, że zaczniesz refaktoryzować to i zastosować swoje umiejętności w innym języku.

Mam nadzieję, że twój sposób korzystania z MVC4 (zakładając, że wszyscy inni nie robią tego całkiem dobrze) w bardziej Rubinowym stylu, przyłapie i oderwie wszystkich od mentalności Webforms.

JeffO
źródło