Takie pytanie w związku z tym, że większość/wszyscy z was siedzi na remote:
Ile godzin dziennie szacunkowo tracicie na context switching?
0
6
W sensie na przełączanie się między pracą, a forum 4p? W pesymistycznym przypadku kilkanaście godzin :P
0
niekoniecznie tylko forum bo np. bachory czy przełączanie się "na chwile" pomiędzy projektami bo coś lub super-ważny-nagły-krótki meeting itd. też
no generalnie wszystko to, co przerywa/rozprasza.
1
A w jaki sposób to zmierzyć?
1
Jeżeli jest godzina 14 i uznajesz, że chociaż wypadałoby odpalić IDE i napisać 1 LoC, to tak czynisz i zaczynasz analizować kod. Po chwili wpada listonosz wręczyć Ci karty do głosowania, oddajesz głos na PiS, oddajesz kartę, zaczynasz znów analizować kod i zerkając na zegar widzisz że jest już 15:05 i trzeba kończyć bo nadgodziny lecą
to dodajesz sobie 1h do straconych przez context switchin' (jesteś zdecydowany w swoich poglądach politycznych, więc obowiązek wykonałeś w 5min)
9
Ja odkrylem u siebie ciekawa zaleznosc -> ze stanu skupienia nad praca do totalnego rozproszenia potrafie przejsc w ulamku sekundy, a wdruga strone nie.
4
Mało, to kwestia dobrej organizacji pracy. Czyli np. pracujesz w nocy a w dzień siedzisz na 4p.
4
Nie tracę, bo mam tylko meetingi. Niech żyje scrum!
1
Remote to się pracuje jak w bajce.
Najgorzej pracuje się na open space, gdzie co chwilę standup, meeting, który kończy się w sposób - aaa weź wyślij mi maila, pytanko, zaraz kolejne pytanko, zaraz kółko różańcowe się zbiera koło menadżera, bo ktoś wstawił na produkcję zły kod i wszystko się sypie i hałas jak na trybunach.
No i standardowo, nawet jak założycie słuchawki, to i tak zaraz ktoś będzie was klepał po ramieniu z pytaniem w stylu, którą ręką się podcierać. Brrrr.
7
Zależy. Jak bardzo jasne mam zadania. Nie mam i dawno nie miałem meetingów przeszkadzajek - scrum ubity w zarodku.
Mam rzeczy, które mnie wytrącają z równowagi - głównie to np. zwisy buildu gradle z powodu rozłączenia vpn. Jak wywali się w trakcie reimportu to muszę ubić intellij i zanim poukładam sobie te moje 6 projektów w odpowiednie desktopy to już nie pamiętam co robiłem. Jest więcej takich technicznych przeszkadzajek i one mnie najbardziej demotywują, powodują, że czas mi gdzieś ucieka.
4programmers i twittera troche limituje - nie ma dnia, żebym nie powstrzymał się od wejścia w jakiś flame ... :-)
Swego czasu - w open space - całą chęć do pracy odbierało mi mimowolne słuchanie i patrzenie jak sąsiedni team robi stand up meeting - na siedząco, po 2- 2.5 godziny spowiedzi do słuchawek.
4
Ja potrafię całkiem szybko wejść w taki stan pod warunkiem, że wiem, że będzie długo trwał. Jak mam dzień w dzień 6h spotkań i dwie przerwy po godzinę (czyli mitingowe poniedziałeczki) to nawet nie zaczynam w tym czasie niczego robić bo wiem, że to nie ma sensu.
3
Rozważania na ten temat opierają się na uproszczonym rozumowaniu.
Pracujesz w IDE - jesteś produktywny. Przełączasz się, żeby przejrzeć powiadomienia albo np. pyknąć w Tetrisa - obijasz się.
Oczywiście zachodzi tu korelacja, ale niezupełna.
Sednem naszej pracy jest (albo powinno być) myślenie.
To nie jest dokręcanie słoików z majonezem ani rąbanie drewna, że kiedy nie naparzasz w klawiaturę, to fabryka stoi.
Czasami trzeba przerzucić pracę na "wątek tła".
Rozmaite rozpraszacze, jak np. szybka partyjka w szachy, nie angażują całej mojej uwagi.
To coś, czym zajmuję się niejako na autopilocie. Taka forma medytacji.
W tym czasie jakaś część mózgu dalej rozmyśla np. nad refaktoryzacją, którą właśnie robię.
Z drugiej zaś strony można karnie siedzieć w kodzie, a i tak prokrastynować.
Jest to tym łatwiejsze, że mamy żelazne alibi - bo przecież kodujemy.
Struganiem i polerowaniem obiektów oraz rozmaitego boilerplate'u można łatwo stworzyć wrażenie, że właśnie robimy jakiś postęp. Jesteśmy "busy".
Czasem można kicać tak za własnym ogonem godzinami, a nic tak naprawdę nie zrobić.
Programista to przede wszystkim zawód piszący. To oczywiście prawda (powtarzana jak mantra), że znacznie więcej czasu spędzamy na czytaniu kodu. Ale tak samo jest u pisarzy: na każdą napisaną książkę wypadałoby z dziesięć czy dwadzieścia przeczytać.
Nie zwiastuje niczego dobrego, jeśli się napisało więcej, niż samemu przeczytało.
I nam też nie płaci się jednak za samo czytanie, tylko za zwieńczenie tego procesu, czyli obkodowanie czegoś konkretnego.
Dlatego możemy inspirować się lepiej znanym i starszym problemem, znanym jako blok pisarski (writer's block). Problem jest dobrze rozpoznany i wymyślono różne rozwiązania.
Jak wiadomo, najciężej zacząć i się rozpędzić. Hemingway miał taką zasadę, że przerywał pisanie w połowie zdania. To nie jest naturalny moment, żeby przerwać pracę; miło jest skończyć akapit albo chociaż postawić kropkę. Ale miało to świetny atut. Kiedy siadał do pracy następnego dnia - nie musiał szukać dobrego punktu wejścia, żeby podjąć to, co przerwał. Wskakiwał w połowę zdania (które podświadomie miał już skończone). Dopisywał zatem dalszy ciąg, stawiał pierwszą kropkę (jakkolwiek podejrzanie by to nie brzmiało), i od razu był rozpędzony.
Od kiedy zacząłem stosować ten patent Hemingway'a, wejście w rytm wychodzi mi znacznie lepiej.
A odpowiadając na pytanie dosłownie, czyli "ile godzin dziennie tracicie".... z definicji tracę 8 godzin minus godziny spędzone rzeczywiście na pracy. A ile spędzam na pracy? Tak naprawdę mało. Ale w naszym fachu to norma. Tylko żyjemy złudzeniem, że jesteśmy wyjątkami, a wszyscy inni mają inaczej :)
What drives me crazy is that ever since my first job I’ve realized that as a developer, I usually average about two or three hours a day of productive coding. When I had a summer internship at Microsoft, a fellow intern told me he was actually only going into work from 12 to 5 every day. Five hours, minus lunch, and his team loved him because he still managed to get a lot more done than average. I’ve found the same thing to be true. I feel a little bit guilty when I see how hard everybody else seems to be working, and I get about two or three quality hours in a day, and still I’ve always been one of the most productive members of the team. [...]
But it’s not the days when I “only” get two hours of work done that worry me. It’s the days when I can’t do anything.
[...] Many of my days go like this: (1) get into work (2) check email, read the web, etc. (3) decide that I might as well have lunch before getting to work (4) get back from lunch (5) check email, read the web, etc. (6) finally decide that I’ve got to get started (7) check email, read the web, etc. (8) decide again that I really have to get started (9) launch the damn editor and (10) write code nonstop until I don’t realize that it’s already 7:30 pm.