Co może spowolnić programistę? [Zamknięte]

Jakie rzeczy spowalniają programistę?

Spróbuj powstrzymać się od publikowania odpowiedzi, które:

• są teraz wolne, ale przydatne w tej funkcji. (TDD, Refaktoryzacja, ...)
• wymienić rozproszenie .

Och, te łatwe:

1. Spotkania
2. Więcej spotkań
3. Spotkania na temat ostatniego spotkania
4. Spotkania mające na celu przygotowanie się do nadchodzącego spotkania
5. Opracowanie prezentacji Power Point na spotkanie
6. Opracowanie prezentacji Power Point na spotkanie omawiające funkcje, które nie zostały zaimplementowane, nie powinno zostać zaimplementowane i bez względu na powód, dla którego facet ze sprzedaży przeskoczy wszystko. Nie mogę przewidzieć, jaki dokument chcesz wyświetlić w aplikacji na podstawie bieżącej lokalizacji bez połączenia z Internetem lub dostępu do dysku twardego. Nie, po prostu zrezygnuj z proszenia o to.

Wolny komputer

Wszystko, co powoduje przełączanie kontekstu .

StackOverflow, programmers.stackexchange.com itp. :)

Powiedziałbym, że wypalenie zawodowe.

Każda próba wykonania procesu, który nie jest odpowiedni do danego zadania.

Mogą to być różnego rodzaju rzeczy, ale najczęściej spotykane to:

• metodologie testowania, które nie pasują do testowanego kodu
• procesy, które są radykalnie bardziej zwinne lub tradycyjne niż gwarantują produkty
• wytyczne, które są przeznaczone dla innego zestawu narzędzi niż wybrany zestaw narzędzi
• zasady projektowania, które są poza skalą w stosunku do potrzeb projektu
• za pomocą zestawu narzędzi, który nie jest odpowiedni do zadania

Wszystkie te rzeczy mogą być niezwykle cenne w niektórych projektach lub w niektórych sytuacjach, ale niektóre organizacje starają się zrobić wszystko w jedną stronę, co prowadzi do słabego dopasowania do innych projektów, które często są przyczyną śmierci produktywności.

Polityka

np. gdy więcej niż jedna osoba posiada wymagania (lub, co gorsza, dwa różne interesy własne) i wprowadzają one konkurencyjne i sprzeczne zmiany w wymaganiach w trakcie opracowywania.

Rozmowy z innymi osobami

i ogólnie hałas

Wiele odpowiedzi mówi o zmianie kontekstu i wydostaniu się ze strefy, a hałas, zwłaszcza rozmowa, jest dla mnie jedną z tych rzeczy.

W moim świecie otaczają mnie hałasy i rozmowy ze wszystkich stron. W jednym rzędzie zespół mainframe organizuje ciągłe spotkania planistyczne w rzędzie sześcianów. Czasami spotykają się z konsultantami w biurze wzdłuż ściany, co prowadzi do głośnego syczenia, wykrzykiwania i śmiechu, a ja muszę podejść i poprosić ich o zamknięcie drzwi.

Z drugiej strony stół konferencyjny zespołu internetowego znajduje się po drugiej stronie mojej zachodniej ściany sześcianu, więc jestem częścią każdego spotkania, czy mu się to podoba, czy nie. Po drugiej stronie południowej ściany sześcianu znajduje się również drukarka, i to zawsze dobrze nadaje się do rozmów z ludźmi, którzy czekają na swoje wydruki.

Natychmiastowa i oczywista odpowiedź „ Nie możesz po prostu dostać słuchawek z redukcją szumów” nie pomaga, gdy chcesz ciszy.

Czasami w celu recenzji kodu zabieram stos papierów do jadalni (oczywiście poza godzinami obiadowymi), ale jest tam telewizor, który zwykle się rozrywa. Wyłączę to, jeśli nikt nie patrzy. W przeciwnym razie znajdę pustą kostkę w innym dziale w innej części budynku.

Jeśli chcesz, aby programiści wykonali pracę, którą muszą wykonać, czyli przede wszystkim myśleć, rozważać i rozważać, potrzebują środowiska, w którym mogą to zrobić.

Pisanie zbyt wielu linii kodu bez odpowiednich testów.

Brak wysokiej jakości kawy.

konieczność dokładnego oszacowania, od którego nie można się wycofać po rozpoczęciu rozwoju, to moim zdaniem scenariusz z jajkiem kurzym

Naprawianie zepsutej kompilacji innej osoby

Spotkania bez porządku obrad.

Wolna maszyna.

Brak drugiego monitora.

Stara mysz, która ma piłkę zamiast ładnych nowych.

Brak dostępu do Internetu na maszynie, co sprawia, że ​​zapytania MSDN / stackoverflow / itp. Są trochę uciążliwe.

Spędziłem zbyt dużo czasu na programowaniu

Nawet jeśli naprawdę lubisz programować, zbyt wiele czasu spędzonego na nim w końcu cię wypali ...

Unikaj wszystkiego, co wyciąga cię z „strefy”. Oznacza to twoją skrzynkę odbiorczą, wyskakujące okienko twittera, czat korporacyjny itp.

Posiadanie cicho pracujące warunek oznacza unikanie że pulpit hałas zbyt.

Każde żądanie zmiany, które byłoby łatwiejsze do zrealizowania, gdybyś wiedział o tym wcześniej.

Zły kod.

Konieczność przepisania części innej osoby, która mogłaby wykonać tę pracę w pierwszej kolejności, to największy czas, jaki mogę sobie wyobrazić.

The Much That Slowows Down to dobry post na blogu.

...

Wiele projektów wielokrotnie powtarza podstawowe funkcje na poziomie infrastruktury, spowalniając tę ​​działalność, dostarczając funkcje, które odróżniają ją od konkurencji.

...

Jest nieuniknione, że produkty i innowacje pomogą skrócić czas, jaki programiści poświęcają na zadania niezróżnicujące. Pytanie brzmi, jaką formę przyjmą te usługi i narzędzia.

...

Ostatnio największe spowolnienie wynika z faktu, że opracowujemy kilka rzeczy jednocześnie, które należało zrobić w określonej kolejności. Czekam więc, aż (nazwiska zostaną zmienione w celu ochrony niewinnych) John dokończy swój komponent, którego potrzebuję do mojego pakietu SSIS, a Harry zwolni, czekając na mnie, aby zaimportować rekordy, ponieważ potrzebuje on pewnych danych, aby sprawdzić jego eksport (kiedykolwiek spróbuj napisać skomplikowany raport eksportowy, gdy nie ma danych w żadnej z tabel?) i wszyscy są spowolnieni, ponieważ projektowanie nie zostało ukończone, a tabele bazy danych, które musimy wykonać, nie zostały jeszcze utworzone, a nawet się nie kończą będąc tym, co powiedzieli, że będą, itd.

Odpowiadanie na pytania na stackexchange.com, takie jak to.

Nawet jeśli poprosiłeś, aby nie wymieniać rozrywek, mogą one być dużym czynnikiem. Spójrz na ich środowisko pracy, sprawdź, czy są często przerywane lub proszeni o zrobienie innych rzeczy, które nie są związane z projektem.

Czasami programista może utknąć, ponieważ robią coś, czego nigdy wcześniej nie robili i nie wiedzą, gdzie szukać pomocy. Jeśli jest to mały zespół lub osoba, może być jeszcze trudniejszy. Zwykle jesteśmy nieco dumni i nie lubimy przyznawać się, kiedy nie wiemy, jak to robić. Nie lubimy też prosić innych o pomoc. Nie ma łatwego sposobu, aby poprosić programistę, by się do tego przyznał, poza pytaniem, czy może dotrzymać terminu lub czego potrzebuje, aby dotrzymać terminu, i mieć nadzieję, że będą uczciwi. Może być konieczne zaoferowanie innej pomocy lub znalezienie kogoś, kto może jej pomóc.

Brak jasno określonych wymagań, co powoduje, że muszą oni coś wymyślić lub podjąć decyzję.

• Poczekaj około 15 minut na uruchomienie komputera
• Oczekiwanie, aż komputer przełączy aplikacje
• Będąc jedyną osobą w biurze, która musi zrobić własną herbatę / kawę.
• Zepsuta klawiatura (naprawiona!)
• Praca poza biurem dyrektora zarządzającego (dyrektora generalnego USA) (a także nie w biurze), tylko pomiędzy partycjami (szczególnie gdy odbywa się spotkanie)
• Do bossa można się dostać tylko przez e-mail, ale wszyscy inni są w budynku
• Nie wolno mi używać VCS - najwyraźniej powinno to być w moim mózgu
• Mały ekran
• Brak czasu na przerwy inne niż obiad
• Konieczność wykonywania kopii zapasowych na serwerze zdalnym pomimo posiadania sysadmin w budynku
• Nakazanie ręcznego wykonywania wspomnianych kopii zapasowych.
• Będąc zmuszonym do używania głupiego systemu zarządzania czasem, który jest niepotrzebnie skomplikowany
• Dopiero co dostałem niejasne wyobrażenie o wymaganiach dwa miesiące po rozpoczęciu pracy

Mógłbym kontynuować, ale jest piątek i chcę zapomnieć o pracy.

• Brak dokumentacji (system, firma itp.)
• Brak skomentowanego kodu
• Niekompletne zrozumienie systemu
• Polityka (tj. Niepotrzebne spotkania, formalności, przeszkody ze strony kierownictwa ...)
• Niekompletna dokumentacja wymagań
• Facebook!
• Za dużo snu?

Zbyt wiele osób biorących udział w projekcie.

Widziałem to kilkakrotnie, gdy kierownictwo decyduje na podstawie żadnych rzeczywistych danych, że muszą dodać więcej osób do projektu. To kończy się na tym, że ppl, którzy wiedzą, co się dzieje, muszą zatrzymać wszystko, aby trzymać ręce ludzi, którzy niewiele wiedzą o tym, co się dzieje. Widziałem więcej niż jednego projektu grzyba, a potem szybko stamtąd wchodził do toalety, podczas gdy wcześniej szło dobrze, chociaż może trochę wolno.

Więc zaczynasz od spóźnienia o miesiąc z powodu zbyt małej prędkości / zbyt wiele do zrobienia, aby w ogóle nie dostarczać, ponieważ całkowicie wydałeś budżet na wszystkie te dodatkowe osoby.

Oprócz rzeczy wspomnianych przez innych, długa droga od podjęcia decyzji o kompilacji i uruchomieniu kodu do uzyskania wyniku pozytywnego / negatywnego . Idealnie, ten RTT byłby tylko sekundą, ale widziałem przykład godzin. Przy okazji, testy jednostkowe próbują poradzić sobie z tym problemem.

Innym związanym z tym jest ogólne opóźnienie środowiska pracy. Wyobraź sobie, że musisz pracować nad połączeniem pulpitu zdalnego z komputerem po drugiej stronie świata, za pomocą przerażającego połączenia. Byłem tam. Nienawidziłem tego.

• Nadmiar dokumentów

• Uzależnienie od kogoś, kogo nigdy nie ma w pobliżu (takiego jak twój szef - jeśli musisz zadać pytanie, ale on zawsze jest na spotkaniu)

• Nieodpowiednie narzędzia i wyposażenie.

• Ludzie wpychają wiosło bez powodu (każda zmiana widoczna w interfejsie użytkownika podlega temu) lub po prostu kłócą się o bzdury.

• Zepsuty ekspres do kawy

• Otrzymywanie niewłaściwych zadań

Klimatyzacja nie działa.

Tak więc temperatura w biurze dochodzi do 40 stopni w lecie -5 w zimie.

-5 nie nadaje się do pisania, ponieważ nie mogę nosić rękawiczek i pisać. 40, po prostu spowalnia moje myślenie.

Jest to bardzo osobista i być może kontrowersyjna opinia, ale planowanie i nadmierne myślenie o projektowaniu z góry lub pisanie „jakościowego” kodu przez cały czas. Jest takie powiedzenie, że „tygodnie kodowania mogą zaoszczędzić wiele godzin planowania”, co może być prawdą w niektórych przypadkach.

Jednak często widzę, że programiści próbują naszkicować dobry projekt przed rozpoczęciem kodowania. Uważam, że łatwiej jest po prostu „zacząć”, ponieważ podczas programowania dowiesz się więcej o swoim problemie i rozwiązaniu, które pozwoli ci szybko przekształcić swoje rozwiązanie w dobry projekt. Większość pojawiających się problemów jest prawie niepoznawalna na początku kodowania (przynajmniej dla mojego słabego umysłu), więc marnowanie czasu na projektowanie to tylko strata czasu.

Dlatego też nie lubię TDD, marnujesz zbyt dużo czasu na pisanie testów, co zmniejsza prawdopodobieństwo refaktoryzacji lub zajmuje dużo czasu na przepisanie testów. Testy jednostkowe są świetne w niektórych przypadkach i na niektórych etapach projektu, ale początek jednego z nich nie jest jednym z nich IMHO :)

Uzyskaj coś działającego szybko i popraw go.

Blok programisty : W przeciwieństwie do innych spowolnień, ten jest trudniejszy do rozwiązania.