Jak często zespół pisze wszystko na miejscu? [Zamknięte]

W ostatnim wywiadzie zapytałem ankieterów: „jak oceniasz nowe technologie i biblioteki (takie jak SignalR) i wprowadzasz je do użytku?”. Powiedzieli, że nie, że zamiast tego piszą wszystko sami, aby nie musieli polegać na nikim innym.

Firma nie pracuje dla rządu lub kontrahentów w dziedzinie obronności, ani przy projektach o kluczowym znaczeniu dla bezpieczeństwa, ani nic podobnego. Byli tylko twoją średnią, średniej wielkości firmą programistyczną.

Moje pytanie brzmi: jak często zespoły same piszą wszystko? Czy powinny mnie martwić zespoły, które to robią?

Edycja - większość każdej odpowiedzi mówi, że jest to coś, czym należy się martwić. Czy drugi wywiad byłby odpowiednim czasem, aby poprosić ich o wyjaśnienie / powtórzenie swojego stanowiska w sprawie pisania wszystkiego we własnym zakresie?

Postawa, by nigdy nie korzystać z bibliotek stron trzecich, jest niedorzeczna. Pisanie wszystkiego samemu jest okropnym wykorzystaniem czasu twojej firmy, chyba że istnieje ścisły wymóg biznesowy, aby każdy wiersz w bazie kodu został napisany przez pracownika firmy - ale jest to niezwykły scenariusz, szczególnie dla firmy z sektora prywatnego, takiej jak opisałeś.

Bardziej racjonalną i dokładniejszą odpowiedzią może być to, że użyliby tylko bibliotek stron trzecich, które:

• Zaspokoić potrzeby kodu, który sami by napisali
• Były dostępne na licencji zgodnej z modelem biznesowym firmy
• Zawarte testy
• Przeszedł przegląd kodu

Jeśli te kryteria zostaną spełnione (i z mojego doświadczenia, przegląd kodu jest bardzo elastyczny, szczególnie przy dobrych testach), nie będziesz już „polegać na nikim innym” - polegasz na istniejących, dostępnych i najlepiej solidnych kod.

Jeśli kod jest open source, to w najgorszym przypadku biblioteka innej firmy zostaje zachowana. Ale kogo to obchodzi? Testy dowodzą, że biblioteka jest dostosowana do twoich potrzeb!

Ponadto awersja do istniejących bibliotek stron trzecich poważnie ogranicza produktywność programistów. Powiedzmy, że firma pisała aplikacje internetowe i odmówiła użycia (np.) JQuery, więc zamiast tego napisała własną alternatywną bibliotekę dla różnych przeglądarek w celu uproszczenia manipulacji DOM. Z niemal całkowitą pewnością możemy założyć, że ich wdrożenie:

• Będzie miał interfejs API obcy dla programistów, którzy znają już jQuery
• Nie będzie tak dobrze udokumentowany jak jQuery
• Nie będzie mieć odpowiednich wyników Google w przypadku problemów z korzystaniem z biblioteki
• Nie będzie tak testowany w terenie jak jQuery

Wszystkie te punkty stanowią główne bariery dla wydajności programisty. Jak firma może sobie pozwolić na rezygnację z takiej wydajności?

Zaktualizowałeś swoje pytanie, aby zapytać, czy jest to właściwe, aby poruszyć drugą rozmowę. To absolutnie jest.

Być może źle zinterpretowałeś odpowiedź swojego ankietera w pierwszym wywiadzie, a może ankieter po prostu niepoprawnie wyjaśnił pozycję firmy i nowy ankieter może to wyjaśnić.

Jeśli wyjaśnisz, że obawiasz się ich stanowiska wobec bibliotek zewnętrznych, istnieją co najmniej dwa możliwe wyniki:

• Są otwarci na zmiany, a twoja troska o ich proces sprawia, że ​​wyglądasz lepiej niż niektórzy inni kandydaci.
• Nie są otwarci na zmiany i uważają cię za „programistę, którego nie chcielibyśmy zatrudnić”. Nie ma znaczenia, to i tak nie jest to miejsce, w którym chcesz pracować.

To wydaje się niezwykle niekonkurencyjne. Pracowałem w sklepach, które postanowiły pominąć standardowe biblioteki typu open source, takie jak Hibernacja, i stworzyć własne z powodu niektórych „krytycznych” brakujących funkcji. Ostatecznie oprogramowanie było niezwykle drogie w budowie i utrzymaniu. Oczywiście, koszt wewnętrznej biblioteki był rażąco niedoceniany. Podczas gdy biblioteka wewnętrzna została napisana, biblioteki standardowe szybko się rozwijały, dodając nowe funkcje, które nie były dostępne w bibliotece wewnętrznej. Ostatecznie praca przy użyciu standardowej biblioteki zajęłaby godzinę zamiast dwóch dni. I to było złe dla karier dewelopera, gdy świat ich mijał. Unikałbym takiego sklepu. Lubię dostarczać i nie mam cierpliwości, aby przepisać, kiedy będę mógł ponownie użyć.

W sklepie występuje choroba o nazwie Nie wynalazł tutaj . Jest to dobry powód, aby zakończyć rozmowę na miejscu i natychmiast wyjść. Można to wyleczyć jedynie przez odgórne sprzątanie domu, co jest bardzo mało prawdopodobne.

Odpowiedź na twoje pytanie jest niestety o wiele bardziej powszechna niż myślisz i zdecydowanie jest to powód do niepokoju.

Tak, zdecydowanie się martw! Cuchną arogancją i (przepraszam, że jestem surowy) głupotą. Każdy programista z połową mózgu użyje biblioteki takiej jak signalR zamiast pisać ją samodzielnie. Nie ma sensu marnować czasu na rozwiązywanie problemu, który już został rozwiązany. Prawdopodobnie postaram się najpierw uzyskać więcej informacji - być może cię źle zrozumieli (może to być trudne, jeśli wywiad się skończy!)

Mam kilku przyjaciół, którzy oboje (krótko) pracowali w domach programowych z zespołem, który nie wymyślił tutaj . Więc mentalność jest tam.

Obaj dokonali obserwacji wokół kultury, którą popierało zespoły programistów. Obaj zakończyli współpracę z ludźmi, którzy byli dość wyspecjalizowani, jeśli chodzi o poglądy na rozwój oprogramowania, i ludźmi, którzy tak naprawdę nie byli skłonni do uczenia się nowych rzeczy i dążenia do jakości. Niezależnie od tego, na jakim etapie kariery jesteś, zawsze chciałbyś pracować gdzieś, gdzie masz szansę na naukę nowych rzeczy od swoich rówieśników. Wydaje się jednak, że tego rodzaju środowiska nie można znaleźć w miejscach, w których wszystko chce się rzucać.

To nie jest powszechne w miejscu, w którym mieszkam, i znam wiele firm przez kolegów. Zaszedłbym tak daleko, by powiedzieć, że to natychmiastowe „nie, dziękuję” ode mnie.

Nie będę zwracał uwagi na dobre punkty, które już napisałem, ale dodam jedną rzecz.

Właśnie utrudniają zatrudnianie.

• Wszyscy nowi pracownicy mają jeszcze bardziej stromy przebieg nauki niż tylko główna część oprogramowania / domeny
• Najlepsi kandydaci zostaną zwolnieni, ponieważ nie będą chcieli, aby ich umiejętności zostały wykorzystane.
• Ludzie prawdopodobnie nie pozostaną długo, gdy zdadzą sobie sprawę, jak źle nie jest korzystanie z ich ulubionych narzędzi, a rotacja personelu jest droga

Teraz oczywiście będą ludzie, którzy lubią to wyzwanie, ale myślę, że byliby w mniejszości.

Będą też firmy działające na „skalę internetową”, Amazon, Facebook itp., Które mają szalone niestandardowe potrzeby, ale znów są to mniejszości.

Nie sądzę, aby firma produkująca oprogramowanie mogła dziś przetrwać bez polegania na oprogramowaniu zewnętrznym i / lub otwartym oprogramowaniu, i aby pozostać konkurencyjnym, muszą oczywiście aktywnie śledzić nowe technologie. Często jednak istnieją dobre powody, aby przyjąć przynajmniej dość defensywne stanowisko.

Na przykład, jeśli sprzedajesz oprogramowanie i twierdzisz, że zapewniasz wsparcie 24/7, a także jesteś prawnie odpowiedzialny za prawidłowe działanie oprogramowania, musisz bardzo dokładnie wiedzieć, co się stanie, jeśli wystąpi problem z twoim oprogramowanie w, powiedzmy, fabryce, gdzie 1 godzina przestoju w produkcji może kosztować kilka milionów dolarów, a potem w tej bibliotece open source, której używasz, zdarza się poważny błąd. Uwierz mi, przeprowadzisz bardzo dokładne oceny danego oprogramowania.

Jednak z tego, co napisałeś, ten scenariusz nie wydaje się być sednem sprawy.

Jeśli jesteś firmą technologiczną o określonej wielkości, wydaje się, że będziesz rozwijać coraz więcej własnych technologii, na przykład: Google rozwija dużo, jeśli nie większość, jeśli nie całe oprogramowanie, podczas gdy większość z nich w dążeniu do uczynienia go standardem branżowym.

Dla mniejszych firm wydawałoby się to stratą czasu, gdy próbują wysłać konkretny produkt z własną logiką biznesową, a z mojego doświadczenia nie widziałem, aby robiły to małe i średnie firmy.

Staje się bardziej skomplikowany, gdy mówimy o mocno wyspecjalizowanej bazie kodu, na przykład: algorytmach szyfrowania - niektórzy ludzie mają podstawową wiedzę na temat tego, jak działają, ale skomplikowane etapy wdrażania rozwiązania wydają się strzelać sobie w stopę chyba że zatrudnisz kryptografa, który specjalizuje się w takich rzeczach.

Niektóre firmy pozwalają na tworzenie własnych projektów open source, co wydaje się bardziej odpowiednie.

Osobiście nie wybrałbym się do miejsca o takiej kulturze.

To, co masz, to naprawdę dobra okazja, aby przejść do drugiego wywiadu i zadać im trudne pytania. Nie wiem, co robi firma, więc trudno powiedzieć, dlaczego wydaje się to dziwny wybór. Możesz użyć komentarza @Daniel Pryden w odniesieniu do korzystania z bibliotek stron trzecich przez Google.

Każde oprogramowanie, z którego korzystasz, zarówno wewnętrzne, jak i zewnętrzne, ma zalety i wady. Nieużywanie narzędzia, ponieważ nie jest ono wewnętrznie, nawet jeśli jest to najlepsze narzędzie do pracy, wykazuje pewien zamknięty sposób myślenia i nigdy nie będzie zachęcać do innowacji i kreatywności.

Być może jednak jesteś osobą, która wprowadzi tę zmianę. Powodzenia ze wszystkim.

Oczywiście, że powinieneś odejść. Nie widziałem tego tutaj wspomnianego, ale największym powodem do przerzucenia pracy jest to, że nie zyskasz zbyt wiele umiejętności zbywalnych.

Wyobraź sobie, że podczas następnego wywiadu pytają, z jakimi technologiami pracowałeś, i możesz wspomnieć tylko o nagich kościach C ++ .. To brzmi jak poziom absolwenta

Duże firmy same piszą wszystko.

Samo napisanie go ma kilka zalet:

1. Gwarantujesz, że sam będziesz właścicielem oprogramowania
2. Możesz poprawnie obliczyć kwoty pracy, które zostały wykorzystane do jego utworzenia
3. Powtarzanie kroków staje się możliwe, nawet jeśli następnym razem biblioteki lib nie będą dostępne
4. Zmniejsza to wzdęcia
5. Nie powtarzasz tego, co już zrobili inni
6. Masz gwarancję, że masz wystarczająco dużo ludzi, aby to utrzymać
7. Możesz modyfikować każdą część oprogramowania
8. Rozmiar oprogramowania jest ograniczony ilością posiadanych zasobów

Oto, jak łamią się wszystkie punkty, jeśli korzystasz z biblioteki innej osoby:

1. Ktoś inny jest właścicielem biblioteki lib
2. Nie wiesz, ile wysiłku włożono w stworzenie biblioteki lib
3. Nie można utworzyć kolejnej wersji produktu na nowej platformie, ponieważ te same biblioteki nie są już dostępne
4. Zdolność do implementacji wymagań zależy od tego, czy lib zaimplementował je lata temu
5. Ktoś inny również korzysta z tej samej biblioteki, uzyskując te same ograniczenia i funkcje
6. Ponieważ nie utworzyłeś bibliotek, nie masz wystarczającej liczby osób, aby utrzymać całe oprogramowanie w twoim produkcie
7. Biblioteki są plikami binarnymi, niemodyfikowalnymi. Nawet jeśli źródło jest dostępne, nie masz wystarczającej liczby osób, aby zmodyfikować tak dużą ilość kodu.
8. Utrzymanie kodu, który utworzyłeś + biblioteki to większy wysiłek, niż początkowo szacowałeś