Jakiego kapelusza nie powinien nosić programista? [Zamknięte]

Z mojego doświadczenia wynika, że ​​twórcy oprogramowania noszą wiele czapek i pełnią różne role z różnymi obowiązkami. Od nie tylko kodowania, ale czasem pisania SQL, projektowania interfejsu użytkownika, projektowania bazy danych, manipulacji grafiką, a nawet testowania jakości.

Jeśli podstawową rolą jest pisanie oprogramowania / kodu, jakie role powinien przyjąć programista? Czy są jakieś?

Celem tego pytania nie jest to, że programista nie jest w stanie pełnić innej roli, ale posiadanie dodatkowej roli faktycznie działa wbrew głównej roli lub powinno być naprawdę dedykowaną rolą kogoś, kto nie programuje przede wszystkim.

Sysadmin. Opracowywanie oprogramowania i obsługa infrastruktury IT to dwa różne zestawy umiejętności, które wyglądają podobnie do osób postronnych. (To wszystko po prostu uderza w komputery, prawda?) Dla małej firmy pokusa będzie bardzo silna, aby sprawić, by Informatyk był odpowiedzialny za wszystkie maszyny w biurze.

Jeśli masz umiejętności, aby faktycznie nosić obie czapki, niesamowite; ale jest to jedna z tych rzeczy, które mogą być o wiele dłuższe niż ludzie sobie uświadamiają, a jeśli samouka podczas swojej drogi, prawdopodobnie nie radzą sobie zbyt dobrze.

Nosisz kapelusz, o który prosi pracodawca. To sprawia, że ​​jesteś graczem zespołowym. To właśnie sprawia, że rozwiązujesz problem .

Ludzie są zbyt pochłonięci pomysłem bycia „deweloperem”, „architektem” lub „analitykiem”. Chrzanić to. Powinieneś być rozwiązaniem problemu. Kod to tylko narzędzie w twoim pasie.

Rozwiązywanie problemów nigdy nie wychodzi z mody.

Jeśli mój pracodawca chce, żebym zapewnił wsparcie techniczne lub zbudował komputery, niech tak będzie. Wydaje się, że marnują pieniądze, biorąc pod uwagę wynagrodzenie programistów, ale to ich sprawa. Jestem tutaj, aby rozwiązać problemy. Jakkolwiek mogę to zrobić, zrobię to. A jeśli po pewnym czasie czuję, że moje talenty są zmarnowane lub satysfakcja z pracy nie jest tam, gdzie chcę, to mam po prostu prawo do przejścia do innej pracy.

Ale podstawowe pytanie - nie ma kapelusza, którego nie nosisz. Cholera, jeśli chcą, żebyś przyniósł kawę, zrób to. Rozwiąż ich problemy; po prostu wiedz, że masz prawo znaleźć inną pracę, jeśli chcesz zmienić.

Próbnik!

W razie potrzeby wyślij nam testerów bezpośrednio ze szkoły testera!

Bez testerów ludzie oczekują, że wszystko zadziała bez końca, ponieważ programista jest testerem i są bardzo inteligentni, więc powinno działać.

Nie twierdzę, że jedzenie psów nie jest dobrym pomysłem. Myślę, że testerzy są teraz bardzo ważni, kiedy jestem programistą.

Powinieneś być ostrożny, aby stać się zwykłym facetem w przypadku problemów ze sprzętem biurowym . Może to obejmować rozwiązywanie problemów z komputerem, administrowanie serwerem, tworzenie kopii zapasowych, a nawet pracę systemu telefonicznego. Popełniłem błąd, wspominając o moim poprzednim doświadczeniu ze sprzętem i ostatecznie moje obowiązki związane ze sprzętem / rozwiązywaniem problemów poważnie kolidowały z moimi obowiązkami programistycznymi.

Programista nie powinien być jedynym testerem własnego kodu .

Programiści piszą kod z zestawem założeń. Jeśli testerzy mają identyczny zestaw założeń, nie wykonają nieoczekiwanej funkcjonalności poza tymi granicami, a wiele problemów pozostanie niewykrytych.

Co więcej, aby posunąć się naprzód, deweloperzy nie mają silnej motywacji, by próbować coś zepsuć, podczas gdy testerzy (być może na poziomie podświadomości).

Nie oznacza to, że testy programistyczne są bezużyteczne. Wręcz przeciwnie - dobre testowanie przez programistów umożliwia testerom skupienie się na poszukiwaniu głębszych problemów. Jednak testy programistyczne nie zastępują dedykowanego testera.

Dwa, o których mogę myśleć od samego początku.

1. Wsparcie techniczne. Nie jestem tu po to, aby pomagać klientom w przejściu przez nową witrynę lub uczyć ich korzystania z funkcji.
2. Chociaż może być konieczne komunikowanie się z klientami na różnych etapach procesu, chyba że jesteś programistą zarządzającym, tak naprawdę nie powinieneś bezpośrednio komunikować się z nimi na temat funkcji i implementacji projektu.

Można powiedzieć, że rozwój CSS / UI byłby poza „sferą programistyczną”, ale z mojego doświadczenia wynika, że ​​jest to dziś umiejętność niezbędna. Nie możesz po prostu uciec od tabel i polegać na kimś, kto je poprawnie zaimplementuje. Może nie podoba mi się wdrażanie projektu lub modyfikowanie kodu w celu obsługi nowego projektu, ale to część zadania.

Pisanie zapytań jest w porządku, testowanie Q / A jest w porządku (a IMO powinno być zadaniem programisty, mając do czynienia z działem zewnętrznym, ale najpierw powinieneś go przetestować). Administracja serwera to trochę szara strefa. W zależności od tego, jak duży jest projekt lub jeśli masz dedykowanego administratora serwera, może on być potrzebny.

Ogólnie rzecz biorąc, z mojego doświadczenia wynika, że ​​większość programistów nie powinna rozwijać wyglądu interfejsu użytkownika - chociaż z pewnością jestem w stanie opracować interfejs użytkownika (i często go tworzyć podczas budowania prototypu lub dowodu koncepcji), to jest to lepiej pozostawić ludzkiemu czynnikowi (który w naszej małej firmie jest grafikiem, który również układa ekrany i tworzy większość podręczników i broszur).

Poza tym programiści nie powinni przeprowadzać testów zapewniania jakości - to jest zadanie działu kontroli jakości (firma, w której pracuję, produkuje wbudowane urządzenia medyczne, więc jest to wymóg, aby testy były wykonywane przez osobny dział).

Z drugiej strony nie widzę powodu, dla którego programiści nie mogą projektować baz danych i pisać SQL, jeśli mają do tego odpowiednie zaplecze - robiłem to wiele razy.

Wsparcie techniczne

Tak wiele mojego dnia jest marnowane, odbierając połączenia z pomocą techniczną ...

Niektóre popularne to:

• „Moje konto jest zablokowane” lub „Nie pamiętam hasła”
• „Mój [telefon | klawiatura | mysz | komputer] nie działa”
• „Mój komputer działa wolno, czy możesz sprawdzić, czy jest coś niezwykłego?”
• „Dlaczego X zdarza się, kiedy kliknę ten przycisk? Powinien to być Y”
• „Ciągle otrzymuję te wyskakujące okienka ....” lub „Myślę, że mam wirusa”
• „Tej osoby już nie ma, czy możesz wyłączyć wszystkie jej rzeczy?”
• „Mamy nowego pracownika, czy możesz skonfigurować go przy użyciu loginu, karty bezpieczeństwa, numeru telefonu, e-maila itp.?”

Każda rola, która zmusza go do samodzielnego zarządzania. W małych zespołach często występuje tendencja do mianowania jednego ze starszych programistów kierownikiem projektu, ale także utrzymywania go w zespole jako programisty. Prowadzi to do różnego rodzaju problemów, ponieważ ten facet, jako programista, jest zasadniczo niezarządzany. Zamiast delegować wszystkie zadania innym członkom zespołu, często kusi go przydzielenie wielu z nich, zwłaszcza najtrudniejszych. Tak więc najtrudniejsze zadania, które najprawdopodobniej powodują problemy, są przypisywane do osoby, która jest tylko w 50% dostępna jako programista i jako taka nie podlega nikomu. Kiedy inni członkowie zespołu nie są w stanie dostarczyć, zamiast skopać tyłek, spróbuje wykonać swoje zadanie, ponieważ jako kierownik projektu odpowiada za sukces, a najbezpieczniejszym sposobem na zrobienie tego jest zrobienie tego sam prawda?

Wsparcie techniczne dla czegoś, czego nie miałeś ręki przy opracowywaniu, wdrażaniu lub utrzymywaniu, a także nie odbyłeś szkolenia i nie jesteś na bieżąco z ważnymi zmianami. Część mojej pracy polegała na odbiorze telefonu dla klientów dzwoniących z pytaniem, dlaczego ich internet nie działa. Nie zajmuję się tą połową biznesu, więc nie mogę im powiedzieć nic na temat pożytku.

Nie ma potrzeby korzystania z pomocy technicznej, z którą nie ma problemu. To bycie sekretarką / wsparciem technicznym podczas prób rozwoju.

To dość obciążające, że trzeba słuchać ludzi narzekających przez cały dzień i nie być w stanie im nic powiedzieć. Radzę unikać tego za wszelką cenę.

Sprzedaży .

Niektóre biedne robale muszą to zrobić, ale na pewno nie powinni to być deweloperzy.

W miarę, jak się starzeję, zdałem sobie sprawę, że jest to najlepsze, jeśli programiści nie wykonują własnych wdrożeń (walczyłem z tym jednym zębem i paznokciami). Nie powinni mieć żadnych praw do produkcyjnej bazy danych oprócz praw do wyboru. Nasz kod ma dużo mniej błędów (i to samo nie pojawiło się wiele razy, ponieważ zmiana została wprowadzona tylko w prod, a późniejsze wdrożenie dev nadpisało go ponownie, a następnie naprawiono tylko w prod w pośpiechu, płukaniu i powtórzeniu), kiedy musiał zacząć przekazywać go innym osobom do wdrożenia, a nie wolno im wprowadzać szybkich zmian produkcyjnych, ponieważ wdrożenie nie było w porządku. Ponadto przestaliśmy mieć te przypadkowe „aktualizacje bez wyróżnienia klauzuli where, które zmieniały każdy problem w tabeli”.

Artysta i projektant interfejsu użytkownika .

Większość programistów jest bardzo słaba w grafice, ale firmy nie zadają sobie trudu, aby artysta rysował obrazy i ikony dla swoich produktów, a jedynie używa „sztuki programisty” - z ohydnymi rezultatami. (Do Windows Vista był to najbardziej oczywisty czynnik odróżniający komputery Mac od komputerów PC - komputery Mac wyglądały pięknie i przyjaźnie, komputery PC były odrażające)

Podobnie wielu programistów nie interesuje się interfejsem użytkownika - zależy im przede wszystkim na kodzie. Po prostu eksponują zawartość swoich zmiennych składowych bezpośrednio w niektórych polach edytowalnych, często nie dbając o to, gdzie umieszczają przyciski i pola w swoich formularzach i zakładają, że jest to wystarczające, co powoduje, że oprogramowanie nie nadaje się do użytku. (Cała branża telefonii komórkowej była tego bardzo winna, dopóki nie pojawił się iPhone, aby pokazać im, że możesz stworzyć interfejs telefonu, który byłby przyjemny w użyciu)

Lotus Notes jest świetnym przykładem tego, jak złe mogą być obie te rzeczy, jeśli nie otrzymasz profesjonalnego projektanta, który pomógłby programistom.

Pisanie ogólnych testów i planów testów. Poważnie, chłopaki, mogę pisać własne plany testowe, ale to oznacza pieczenie w produkcie wszelkich nieporozumień, fałszywych założeń i błędów poznawczych, które popełniłem podczas pisania tego materiału. To była jedyna rzecz, której nienawidziłem w jednej firmie, w której pracowałem; gdzie jestem teraz, mamy przynajmniej recenzje kodu, które prawdopodobnie złapią to.

Nigdy nie noś więcej „czapek”, niż możesz sobie z nimi poradzić i czujesz się swobodnie, próbując zaszufladkować twórców dziur, mówiąc, że nie powinni robić A lub B, oznacza, że ​​świetny projektant interfejsu użytkownika może pozostać niezauważony, ponieważ ktoś uważa, że ​​programiści powinni trzymać się z dala od interfejs użytkownika.

Pod koniec dnia każdy będzie miał różne mocne i słabe strony, a dobry menedżer / przełożony / lider zespołu powinien wiedzieć, jak najlepiej kierować ludźmi, którzy dla nich pracują, aby zapewnić odpowiednie wykorzystanie talentów. Podobnie, jeśli nie czujesz się komfortowo w projektowaniu interfejsów użytkownika lub kontaktach z użytkownikami końcowymi, daj znać zespołowi, abyś mógł zminimalizować swoją rolę w tym obszarze. Jednak powinieneś być przygotowany na podjęcie dodatkowej pracy w innym obszarze.

Ponadto, jeśli nosisz zbyt wiele czapek (np. Programista, projektant interfejsu użytkownika, tester, analityk biznesowy itp.), To albo będziesz źle sobie radził na niektórych z nich, albo się wypalisz. Upewnij się, że wiesz, ile czapek możesz obsłużyć, i staraj się utrzymać obciążenie na tym poziomie.

Poza tym tak naprawdę nie ma „czapek”, których twórca nie powinien nosić, jeśli mają umiejętności, które pozwolą mu odnieść sukces w tej roli.

Zwykle podejmuję się każdej pracy, która jest mi rzucana, jeśli i tylko wtedy, gdy:

• Ostrzegam z wyprzedzeniem o moim poziomie umiejętności i możliwych implikacjach, a mój szef decyduje, że jest to akceptowalne
• Jest osoba na poziomie guru, która może (i prawdopodobnie na pewnym etapie) pomoże mi poradzić sobie z czymś nieoczekiwanym
• Przeczytaj dokumentację, zadawane pytania online itp.

W ten sposób jestem w większości ubezpieczony od mojego szefa, a jeśli ktoś się pomyli, można to przynajmniej naprawić.

Deweloperzy są zainteresowanymi stronami (takimi jak klienci, właściciele itp.), Więc mają prawo oczekiwać znaczącej pracy. Moim zdaniem oznacza to możliwość pracy ze swoimi mocnymi stronami .

Deweloper nie powinien więc nosić czapki, która nie energetyzuje, nie przyczynia się do rozwoju osobistego i prowadzi do szczytowej wydajności - i kradnie czas „czapkom”, które robią te rzeczy za nich.

Poza tym, że nie jest jedynym, który testuje własny kod, myślę, że każdy „kapelusz” jest w porządku, jeśli ma znaczącą pracę dla dewelopera noszącego ten kapelusz.

„Projektant” lub „kreatywny facet”. Przejdziesz od niewinnego tworzenia makiety interfejsu aplikacji do pisania tekstu marketingowego do następnej internetowej kampanii reklamowej lub niekończących się dyskusji na temat „właściwego” odcienia niebieskiego, zanim się zorientujesz x_x.

ten kapelusz z puszkami piwa z boku ze słomką. zły pomysł, jeśli zostaniesz złapany.

edytować:

Oto kapelusz, którego nienawidzę, ale ma wielką nagrodę - to wielki znak dla mnie, który mówi, że jeśli to się zepsuje, to wszystko z Twojej winy ... ah, ale jeśli to dobrze, to ty, mój syn, jesteś dobrym chłopcem, którego wszyscy znamy są - teraz wróć do piwnicy ... dobry chłopak ... to wszystko.

Wina czapka.