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

12

Jakie rzeczy spowalniają programistę?

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

Tom Wijsman
źródło
@Mark Trapp: Huh ?! To wcale nie jest duplikat ...: -S
Tamara Wijsman,
1
Jeśli pytanie nie okaże się przydatne, usunę je w najbliższej przyszłości, ludzie wymieniają rozrywki, które są już objęte innym pytaniem ode mnie. Staram się więc szukać rzeczy nie rozpraszających uwagi ... TheLQ i Bill są dobrymi przykładowymi odpowiedziami.
Tamara Wijsman,
Huh, adres URL został zniekształcony. Duplikat brzmi: jakie zakłócenia mogą się zdarzyć podczas programowania?
Postanowiłem pozostawić pytanie otwarte, ponieważ dotyczy rzeczy, które nie są rozrywkami ...
Tamara Wijsman
11
Stackoverflow, SuperUser, programiści ... tak, w zasadzie takie strony :)
bedwyr

Odpowiedzi:

49

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.
pszenica
źródło
4
w skrócie: zarządzanie? ; o)
n1ckp
11
@ n1ck Nie, nie. Dobre zarządzanie może przyspieszyć programistę. Złe planowanie czasów programisty (tj. Jeden aspekt bycia menedżerem) może naprawdę spowolnić rozwój.
pszenicy
3
zabija mnie to, gdy moja firma to robi: Spotkania, Więcej Spotkań, Spotkania o ostatnim Spotkaniu, Spotkanie w celu przygotowania, Spotkanie w celu omówienia, dlaczego nie możemy osiągnąć niczego. Dlaczego nie możemy niczego osiągnąć? Czterdzieści deweloperów siedzi w pokoju i słucha ciebie !!
Mike M.
2
Pamiętaj, że ta odpowiedź prawie pasuje do slajdu Powerpoint.
44

Wolny komputer

TheLQ
źródło
Ten sam problem tutaj
pramodc84
1
Jak najszybciej kupiłbym sobie laptopa i pracowałbym nad tym, gdybym był w takiej sytuacji, zakładając, że firma na to pozwala.
adamk
Powolne komputery są zwykle przyczyną rozproszenia uwagi. Za każdym razem, gdy programista czeka, może wejść w tryb rozproszenia uwagi i nie wróci do programu aż do pewnego czasu.
edA-qa mort-ora-y
Wymienili mój komputer kilka tygodni temu. Jest mniej wydajny niż 4-letni, który zastępuje. Ładny.
MetalMikester
25

StackOverflow, programmers.stackexchange.com itp. :)

Ryan Rinaldi
źródło
4
Nie zgadzać się! StackOverflow pomaga rozwiązywać problemy, więc przyspiesza rozwój!
Wizard
3
Obraźliwa głupota. Za każdą minutę, którą „zmarnowałem” na SO, odkupuje mnie 20.
MIA
11
+1. wcale nie obraźliwe. SO jest bardzo dobry do zwlekania. To mój nowy facebook. :)
back2dos,
@ back2dos Proszę nie porównywać wspaniałości SO z kawałkiem ... czyli facebook.
adamk
17

Powiedziałbym, że wypalenie zawodowe.

Maniero
źródło
15

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.

Rachunek
źródło
13

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.

Chris Buckett
źródło
9

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ć.

Andy Lester
źródło
Czasem robi się za cicho tam, gdzie jestem. Zaczynam skupiać się na kliknięciach myszy i ciężkim oddechu ludzi itp. To tak, jakby leżeć w łóżku i słyszeć krykieta.
kirk.burleson
8

Pisanie zbyt wielu linii kodu bez odpowiednich testów.

Fortyrunner
źródło
To jest główna przyczyna zatrzymywania się rzeczy w moim doświadczeniu.
Paddyslacker,
1
@Paddyslacker: więcej testów = bardziej produktywny? Co? Tylko dla osób, które nie powinny zajmować się programowaniem. Test może być przydatny, ale „najważniejsza przyczyna zatrzymywania się rzeczy”? Mówisz poważnie?
n1ckp
1
@ n1ck: Tak, mówię poważnie. Kod przechodzi w stan niemożliwy do utrzymania, a brak testów i możliwości testowania podstawy kodu oznacza, że ​​każda nowa funkcja staje się coraz trudniejsza do dodania. To zabawne, że uważasz, że ludzie, którzy piszą więcej testów „nie powinni zajmować się programowaniem”. Więc Roy Osherove, Michael Feathers, Wujek Bob, Kent Beck itp. Nie powinni być wtedy programistami?
Paddyslacker
@Paddyslacker: Nie wiem. Nigdy nie widziałem ich kodu. Może powinny być lepsze w zarządzaniu od twojego opisu? I dlaczego kod staje się nieusuwalny z powodu braku testu? Test może sprawić, że słaby kod będzie świetny dzięki magii?
n1ckp
1
@ n1ck, testy nie przydają się przy pisaniu kodu na początku, ale robi ogromną różnicę, gdy trzeba zachować kod później.
5

Brak wysokiej jakości kawy.

Robert Harvey
źródło
Lub brak dobrej sody. Tęsknię za tak bezkofeinową dietetyczną colą wiśniową! W moim kraju mogę dostać tylko dietetyczną colę lub bezkofeinową colę, a wcale nie kokę wiśniową :-(
Wizard
1
@Wizard - Pracuję dla firmy, która dostarczyła dietetyczną colę. Nie jestem pewien, dlaczego odszedłem. Jeśli poczujesz swój ból.
JeffO
2
@Wizard: po prostu kup słoik wiśni maraschino i dodaj trochę syropu do swojego drinka. Teraz możesz sprawić, by był tak mocny, jak chcesz ... (ta sama sztuczka dla wanilii: prawdziwa waniliowa koks jest znacznie lepsza niż wstępnie zmieszane)
Shog9
@Pan. C: Problem polega na tym, że potrzebuję diety + koksu bezkofeinowego, kombinacji, która nie jest dostępna w moim kraju.
Wizard
5

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

MetaGuru
źródło
Jeśli często się w to wpadasz, proponuję poświęcić trochę nietrywialnego czasu na studiowanie szacunków. Następnie możesz odpowiedzieć „jeśli jest to szacunek, to z definicji nie tyle czasu, ile faktycznie zajmie”.
MIA
och, już go użyłem, odpowiedź jest zawsze taka, że ​​źle oceniam, jeśli nie da się go podzielić na widoczne 2-4 godzinne zadania, to najwyraźniej robię to źle
MetaGuru
5

Naprawianie zepsutej kompilacji innej osoby

rwong
źródło
brzmi, jakby ktoś źle doradzał swojemu współpracownikowi.
Nazwa wyświetlana
@bold: może się zdarzyć naturalnie z powodu asynchroniczności. Załóżmy, że dzienny czas zakończenia kompilacji to 5 rano, a najnowsza wersja jest dostępna o 9 rano. (Innymi słowy, nie można powstrzymać ludzi przed przyjściem do pracy wcześniej).
rwong
4

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.

ist_lion
źródło
Powiązanie ze spotkaniem bez porządku dziennego jest porywaczem spotkania. Wiesz ... umieściłeś go w kalendarzu na godzinę, ale nawet jeśli temat zostanie zamknięty w 20 minut, tamten facet szuka innych tematów, aby wypełnić te 20 minut. Głosowałbym za tobą, ale potem musiałbym zagłosować za „brakiem drugiego monitora” jako spowolnienie. Jest to wygodne, ale nie posiadanie go od czasu do czasu mnie nie spowolniło.
MIA
4

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 ...

nanda
źródło
4

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.

GmonC
źródło
3

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

JeffO
źródło
„Chodzenie po wodzie i tworzenie oprogramowania ze specyfikacji jest łatwe, jeśli oba są zamrożone”
back2dos 22.10.10
1
Głupi cytat. Chodzenie po lodzie nie zawsze jest łatwe.
Peter Boughton
1
@Peter Boughton: Jeśli wybierzemy skalę, w której tworzenie oprogramowania na podstawie zmieniających się specyfikacji jest trudne, a na zamrożonych - łatwe, chodzenie po lodzie jest zawsze łatwe. Możesz tego nauczyć 6-latka. Ale przypuszczam, że o tym wiesz, po prostu czerpiesz przyjemność z inteligentnego tyłka.
back2dos
Możesz także nauczyć sześciolatka, aby pracował ze zmieniających się specyfikacji. To nie jest mądra ocena, to irytacja nadużywaniem takich cytatów, które nie są pomocne. Zamrożone specyfikacje nie są łatwe do opracowania, jeśli są błędne (ponieważ nie można ich naprawić), a zmienianie specyfikacji jest w porządku, jeśli wiesz z góry, które części są zmienne (jak możesz to załatwić).
Peter Boughton
3

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ć.

n1ckp
źródło
2

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.

...

Tamara Wijsman
źródło
+1: Świetna odpowiedź. Zostawiłem pracę, ponieważ firma nie chciała poświęcać czasu na redukcję długu technicznego. Programiści byli zmuszeni do „powtarzania podstawowych funkcji na poziomie infrastruktury w kółko”.
Jim G.
2

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.

HLGEM
źródło
1
Wygląda na to, że mówisz o wąskich gardłach spowodowanych zbyt cienkim rozłożeniem pracy między członków zespołu.
MIA
1
Zespół nie jest tak rozproszony, ale zarząd nie pomyślał o zależnościach w przydzielaniu projektów. A rzeczy, które zakładano, że były gotowe w momencie, w którym inny człowiek został przydzielony do projektu, nie były, gdy ludzie próbowali ich faktycznie użyć.
HLGEM,
2

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

tactoth
źródło
Możesz więc rozważyć poprawę umiejętności pisania dotykowego.
2

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ę.

użytkownik6061
źródło
2
  • 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.

Alan Pearce
źródło
Wygląda na to, że musisz się stamtąd wydostać!
adamk
2
  • 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?
soran awla
źródło
1

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.

MIA
źródło
0

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.

Ilia K.
źródło
0
  • 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ń

JohnL
źródło
0

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.

Mamrocze
źródło
0

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.

Homde
źródło
-1 Rozumiem twoje myślenie, ale celem etapu projektowania jest ograniczenie potrzeby refaktoryzacji. Ułatwia także testowanie jednostek, co jest świetne przez cały czas, aby upewnić się, że coś, co działało, nie zostanie zepsute i zwolnione. Jeśli nie dokonasz żadnego planowania, sprawisz, że wszyscy będą trudniejsi, gdy będą musieli zachować coś, co nieuchronnie będzie słabo skonstruowanym kodem.
adamk
Kto powiedział, że będzie źle skonstruowany? Mówię tylko, że nie chcesz nadmiernej fazy projektowania i musisz przeprowadzić wiele refaktoryzacji i ponownej architektury podczas projektu, aby uzyskać kod jakości. Z drugiej strony, aby to zadziałało, musisz mieć wyraźnie określone obowiązki związane z kodem, gdy różni ludzie nie chowają się nawzajem w kodzie.
Homde
Doświadczenie mówi, że będzie miał słabą architekturę. Latanie przy siedzeniu spodni i kodowanie kowboja to prawdopodobnie najgorsze rzeczy, które możesz zrobić podczas projektowania. Posiadanie fazy projektowania, która potrwa tydzień, pozwoli ci zaoszczędzić miesięcy programowania i doprowadzi do kodu, który robi to, co powinien za pierwszym razem. Idea TDD polega na tym, że nie zmieniasz testów. Testy te mają na celu naśladowanie użyteczności w świecie rzeczywistym, a jeśli kod nie może ukończyć testu, oznacza to, że kod jest nieprawidłowy.
Mike S
Moje doświadczenie mówi inaczej, ale myślę, że to zależy od kowboja i zespołu :) Nauczyłem się więcej przez tydzień kodowania i zrobiłem trochę kodu, aby to pokazać. Oczywiście będziesz miał słabą architekturę, jeśli nie przeprowadzisz ekstremalnego i ciągłego refaktoryzacji i będziesz miał wystarczająco zwinny zespół / kowboj, aby nadążyć. Myśl, że możesz zrobić „fazę projektowania”, nauczyć się wszystkiego i zrobić to dobrze za pierwszym razem, jest po prostu naiwna. Prawdziwą wartością prototypu są lekcje, których się uczysz, wyrzucasz go i robisz to dobrze. Zrób to wiele razy i szybko :)
Homde
0

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

Ciemności
źródło