Vyžadují dobré IT firmy po svých programátorech přesčasy?

[PJ]

Ano, aj dobre firmy niekedy vyzaduju nadcasy.

Ked nasa firma kvoli nefunkcnosti stracala miliony, tak nam riaditel naznacil, ze by bolo dobre to riesit, nehrat hry a nejst po 8 hodinach domov. Nikto nebol nuteny, ale kazdy to pochopil a zostal o hodinku dlhsie. Keby to ziadal kazdy tyzden, tak by to bolo o inom.

[Reklama]

[javaman ()]

Tak jste pěkné lopaty. Více hodin se nerovná více práce. Vlastně ve skladu jo...

[JS]

Všichni programátoři, které znám, včetně těch nejlepších, dělají (kromě vymýšlení jak daný problém vyřešit co nejefektivněji) taky spoustu rutiny.Taky řeší spoustu problémů, které už byly dávno vyřešeny, takže jenom aplikují už osvědčené řešení.

Pouzivas skryte dve ruzne definice rutiny, a z toho vyplyva tvuj omyl. Rutina (pro cloveka) je neco, co delal uz treba 100x, ma to proste v mechanicke pameti, a nemusi u toho moc premyslet. Takze treba moje mamka muze soucasne plest kosik (rutina) a pritom koukat na televizi (nerutina). Ale uz jenom treba cteni knihy neni rutina, takze nikdo nedokaze rozumne cist knihu a soucasne se divat na televizi.

Ale rutinni prace (pro spolecnost) je neco jineho, je to prace, ktera je uz vseobecne dobre popsana a je jasne, jak ji udelat. Napr. rizeni auta nebo jazykova korektura je rutinni prace. Ale ze je neco rutinni prace, jeste neznamena, ze se sestava jen z rutiny. Neznamena to, ze treba ridic nebo korektor muze jeste pri praci sledovat televizi.

Takze, nektere cinnosti v programovani mohou byt rutinni praci, ale to neznamena, ze jsou rutinou, kterou muze efektivne delat clovek, ktery je unaveny a nedovede se poradne soustredit.

To co teď napíši, je možná jenom moje pracovní metoda a vy jistě používáte lepší - ale mě když to nemyslí a nevím, jak na to, tak to prostě začnu řešit blbě. A protože implementace je ta nejlepší analýza, tak právě přitom uvidím, že to dělám blbě a napadne mě, jak to dělat správně. Většinou :-) Nakonec sice zahodím třeba hodně hodin práce, ale pořád lepší než ty hodiny jenom koukat z okna a smutnit se na šéfa, že dneska nic, že dneska mi to nepálí.

Bylo by zajimave zjistit, jestli je tvoje metoda skutecne efektivnejsi. Hodne lidi, stejne anekdoticky, tvrdi, ze neni, a i ja o tom mam pochybnosti.

Fakt si myslíš, že programátoři dělají přesčasy všude na světě i když to vůbec nemá smysl (když nevyrábí rotační uňuchadla)?

Ano, v realnem svete je spousta lidi, kteri delaji cinnosti, ktere nemaji zadny smysl, ci jim samotnym dokonce skodi, protoze musi. Typicky je to proto, ze nejakemu psychopatovi u moci je proste lhostejne, ze to tak je. Z jeho hlediska je nenulova sance (a tudiz pozitivni zisk), ze to je pro nej vyhodne, vyvazena nulovou cenou (treba vysokym negativnim nasledkem pro nekoho jineho).

[JS]

Ked nasa firma kvoli nefunkcnosti stracala miliony, tak nam riaditel naznacil, ze by bolo dobre to riesit, nehrat hry a nejst po 8 hodinach domov. Nikto nebol nuteny, ale kazdy to pochopil a zostal o hodinku dlhsie. Keby to ziadal kazdy tyzden, tak by to bolo o inom.

Takze 5 hodin navic od kazdeho zamestnance zachranilo firme miliony? A dostali jste je zaplacene? V takove firme bych si asi skutecne na prescasy nestezoval...

[Lama]

Nařízené přesčasy mají IMHO smysl u pracovníků co místo osmi rotačních uňuchadel za 8 hodin práce jich vyrobí devět, když budou dělat o hodinu víc. Ale pokud to zrovna duševnímu pracovníkovi ten den (výjimečně) moc nemyslí, jaký význam bude mít, když bude zahřívat židli o hodinu déle, aby vyhověl šéfstvu?

Fakt si to myslíš? Opravdu jsi takový génius, že tvoje práce spočívá pouze ve vymýšlení nových věcí? Všichni programátoři, které znám, včetně těch nejlepších, dělají (kromě vymýšlení jak daný problém vyřešit co nejefektivněji) taky spoustu rutiny.
Taky řeší spoustu problémů, které už byly dávno vyřešeny, takže jenom aplikují už osvědčené řešení.
Jsem si jist, že každý, i když mu to ten den nepálí na vymýšlení nového, může udělat spoustu práce i kdyby ho šéf donutil ke 3 hodinám přesčasů. Ano samozřejmě sem hned každý napište svou historku, jak vás šéf nutil k přesčasu i když jste ještě neměli zadání od zákazníka tak jste opravdu neměli co dělat.

Ty si fakt myslíš, že rutina neunavuje a že v rutinní práci nelze dělat chyby zvláště, když je dotyčný unavený?

[Reklama]

[JS]

Realita je ta, že u IT projektů se časová náročnost odhaduje velmi blbě. Hůře než v jiných oborech - a to i v případě, že by ten projekt měl použít řešení, která už všechna byla použita jinde.
Pokud budete řešit něco nového, něco co jste ještě nedělali (nebo nedejbože to nedělal zatím nikdo), tak jediná správná odpověď na časovou náročnost projektu je "fakt nevím". Nějaké hodiny se samozřejmě nacenit musí, takže se tam něco napíše a nějaký termín se stanoví. Ale že se to potom do těch hodin a termínu nevejde je běžná věc.
Pokud někdo (tedy kromě javamana) umí třeba odhadnout, za jak dlouho by se dal naprogramovat systém, který bude řídit hejno dronů (nebo letadel) tak, jak funguje hejno živých ptáků, tak by mu bylo mnoho týmů po světě dost vděčno :-) Ale nemusíme chodit až k tak hi-tech projektům. Ono často stačí, že chcete prohnat data přes nějaký framework a zjistíte, že v aktuální verzi toho frameworku je chyba (a autor frameworku vám neudělá hotfix, bude se čekat na release, který bude za pár měsíců). A bum - to co mělo být za 3 dny hotové budete ohýbat přes jinou funkcionalitu a bude to trvat 3 týdny.

Tak ono by to IMHO celkem dobre slo odhadovat, kdyby se dusledne pouzivalo ciste funkcionalni programovani s korektnim rizenim vedlejsich efektu. V takove situace muzeme cely program, ktery je potreba upravit, rozdelit na dve casti - na cast, kterou zcela jiste potreba upravit neni, protoze typova signatura (a tedy i semantika zustala totozna), a na cast, kterou potencialne potreba upravit je. Pak horni odhad celkove doby upravy te potencialni odpovida casu, ktery byl potrebny k jejimu napsani (tedy, "v nejhorsim to muzeme cele prepsat"). (Lze vznest ruzne namitky, ktere nebudu adresovat pro omezene mnozstvi prostoru, ktery k tomu zde je.)

Duraz na FP totiz dava konecne zpusob nakladat s programem jako nakladame s objekty realneho prostoru - vime, ze treba postavit vilu nebude trvat dele, nez postavit mrakodrap, protoze proste vila ma mensi objem. To dava pevnou, neprekrocitelnou hranici odhadu.

Casem se to tak IMHO bude delat, ale zatim je to jen budoucnost, bohuzel.

[javaman ()]

WTF, co je to za blbost? Když chce zákazník něco, co neexistuje, tak asi těžko mi FP nějak pomůže

Nikdo neví, jak to implementovat, ale FP přiletí a vyřeší to.

[Polymath]

Realita je ta, že u IT projektů se časová náročnost odhaduje velmi blbě. Hůře než v jiných oborech - a to i v případě, že by ten projekt měl použít řešení, která už všechna byla použita jinde.
Pokud budete řešit něco nového, něco co jste ještě nedělali (nebo nedejbože to nedělal zatím nikdo), tak jediná správná odpověď na časovou náročnost projektu je "fakt nevím". Nějaké hodiny se samozřejmě nacenit musí, takže se tam něco napíše a nějaký termín se stanoví. Ale že se to potom do těch hodin a termínu nevejde je běžná věc.
Pokud někdo (tedy kromě javamana) umí třeba odhadnout, za jak dlouho by se dal naprogramovat systém, který bude řídit hejno dronů (nebo letadel) tak, jak funguje hejno živých ptáků, tak by mu bylo mnoho týmů po světě dost vděčno :-) Ale nemusíme chodit až k tak hi-tech projektům. Ono často stačí, že chcete prohnat data přes nějaký framework a zjistíte, že v aktuální verzi toho frameworku je chyba (a autor frameworku vám neudělá hotfix, bude se čekat na release, který bude za pár měsíců). A bum - to co mělo být za 3 dny hotové budete ohýbat přes jinou funkcionalitu a bude to trvat 3 týdny.

Tak ono by to IMHO celkem dobre slo odhadovat, kdyby se dusledne pouzivalo ciste funkcionalni programovani s korektnim rizenim vedlejsich efektu. V takove situace muzeme cely program, ktery je potreba upravit, rozdelit na dve casti - na cast, kterou zcela jiste potreba upravit neni, protoze typova signatura (a tedy i semantika zustala totozna), a na cast, kterou potencialne potreba upravit je. Pak horni odhad celkove doby upravy te potencialni odpovida casu, ktery byl potrebny k jejimu napsani (tedy, "v nejhorsim to muzeme cele prepsat"). (Lze vznest ruzne namitky, ktere nebudu adresovat pro omezene mnozstvi prostoru, ktery k tomu zde je.)

Duraz na FP totiz dava konecne zpusob nakladat s programem jako nakladame s objekty realneho prostoru - vime, ze treba postavit vilu nebude trvat dele, nez postavit mrakodrap, protoze proste vila ma mensi objem. To dava pevnou, neprekrocitelnou hranici odhadu.

Casem se to tak IMHO bude delat, ale zatim je to jen budoucnost, bohuzel.

Jenže FP je mnohem abstraktnější a po průměrném javistovi, jehož intelekt končí u trojčlenky, nemůžeme chtít pochopení monád. A bez nich není FP...

[TVL]

Všichni programátoři, které znám, včetně těch nejlepších, dělají (kromě vymýšlení jak daný problém vyřešit co nejefektivněji) taky spoustu rutiny.Taky řeší spoustu problémů, které už byly dávno vyřešeny, takže jenom aplikují už osvědčené řešení.

Pouzivas skryte dve ruzne definice rutiny, a z toho vyplyva tvuj omyl. Rutina (pro cloveka) je neco, co delal uz treba 100x, ma to proste v mechanicke pameti, a nemusi u toho moc premyslet. Takze treba moje mamka muze soucasne plest kosik (rutina) a pritom koukat na televizi (nerutina). Ale uz jenom treba cteni knihy neni rutina, takze nikdo nedokaze rozumne cist knihu a soucasne se divat na televizi.

Ale rutinni prace (pro spolecnost) je neco jineho, je to prace, ktera je uz vseobecne dobre popsana a je jasne, jak ji udelat. Napr. rizeni auta nebo jazykova korektura je rutinni prace. Ale ze je neco rutinni prace, jeste neznamena, ze se sestava jen z rutiny. Neznamena to, ze treba ridic nebo korektor muze jeste pri praci sledovat televizi.

Takze, nektere cinnosti v programovani mohou byt rutinni praci, ale to neznamena, ze jsou rutinou, kterou muze efektivne delat clovek, ktery je unaveny a nedovede se poradne soustredit.

A pointa toho celého je jaká?
Moje pointa je, že přesčasy u programátorů mají smysl. A že mají smysl i když programátor zrovna nemá "vymýšlecí den". Rozhodně to tvrdím pro přesčasy z kategorií 1-3, tak jak jsem je dříve definoval. U kategorie 4 už bych to netvrdil vždycky a pro všechny, ale podstata sporu s Yardou byla jinde.

To co teď napíši, je možná jenom moje pracovní metoda a vy jistě používáte lepší - ale mě když to nemyslí a nevím, jak na to, tak to prostě začnu řešit blbě. A protože implementace je ta nejlepší analýza, tak právě přitom uvidím, že to dělám blbě a napadne mě, jak to dělat správně. Většinou :-) Nakonec sice zahodím třeba hodně hodin práce, ale pořád lepší než ty hodiny jenom koukat z okna a smutnit se na šéfa, že dneska nic, že dneska mi to nepálí.

Bylo by zajimave zjistit, jestli je tvoje metoda skutecne efektivnejsi. Hodne lidi, stejne anekdoticky, tvrdi, ze neni, a i ja o tom mam pochybnosti.

Mě ta metoda vyhovuje - dobře se mi tak přemýšlí o problému. Já potřebuji si buď malovat, nebo psát kód, kdyby mi někdo svázal ruce, tak nevymyslím nic. Výhodou je, že když mě nic nenapadne, tak mám v kupě aspoň špatné řešení (které se dá později předělat), ale teď to neblokuje termín.

Fakt si myslíš, že programátoři dělají přesčasy všude na světě i když to vůbec nemá smysl (když nevyrábí rotační uňuchadla)?

Ano, v realnem svete je spousta lidi, kteri delaji cinnosti, ktere nemaji zadny smysl, ci jim samotnym dokonce skodi, protoze musi. Typicky je to proto, ze nejakemu psychopatovi u moci je proste lhostejne, ze to tak je. Z jeho hlediska je nenulova sance (a tudiz pozitivni zisk), ze to je pro nej vyhodne, vyvazena nulovou cenou (treba vysokym negativnim nasledkem pro nekoho jineho).

Na světě existuje obrovské množství SW firem a všeobecným rozhledem po různých programátorských diskuzích jsem pochopil, že přesčasy se dělají v naprosté většině firem, kde je rozhodující dodat produkt včas.
Málo se dělají ve firmách, co si vyvíjí vlastní SW a samy jsou svým zákazníkem. A možná se méně dělají v Německu, kde panuje na pracovním trhu slušný socialismus a volno je tam posvátné a za práci ve státní svátek je tam trest smrti.
A ty všechny firmy to dělají špatně. Nikdo nepřišel na to, že přesčasy jsou velká chyba, nepřišly na to ani ty pružné malé firmy (včetně těch malých, které pořád řídí vývojář, který je založil)?
Já měl pocit, že právě většina startupistů dělá přesčasy, jaké si korporátníci řízení psychopatem ani nedovedou představit.
A nikdo nepřišel na to, že by byli lepší a více vydělali, kdyby přesčasy nedělali? Tomu prostě nevěřím :-)

[TVL]

Nařízené přesčasy mají IMHO smysl u pracovníků co místo osmi rotačních uňuchadel za 8 hodin práce jich vyrobí devět, když budou dělat o hodinu víc. Ale pokud to zrovna duševnímu pracovníkovi ten den (výjimečně) moc nemyslí, jaký význam bude mít, když bude zahřívat židli o hodinu déle, aby vyhověl šéfstvu?

Fakt si to myslíš? Opravdu jsi takový génius, že tvoje práce spočívá pouze ve vymýšlení nových věcí? Všichni programátoři, které znám, včetně těch nejlepších, dělají (kromě vymýšlení jak daný problém vyřešit co nejefektivněji) taky spoustu rutiny.
Taky řeší spoustu problémů, které už byly dávno vyřešeny, takže jenom aplikují už osvědčené řešení.
Jsem si jist, že každý, i když mu to ten den nepálí na vymýšlení nového, může udělat spoustu práce i kdyby ho šéf donutil ke 3 hodinám přesčasů. Ano samozřejmě sem hned každý napište svou historku, jak vás šéf nutil k přesčasu i když jste ještě neměli zadání od zákazníka tak jste opravdu neměli co dělat.

Ty si fakt myslíš, že rutina neunavuje a že v rutinní práci nelze dělat chyby zvláště, když je dotyčný unavený?

To má být pokus o straw mana? Nic takového netvrdím. Práce přesčas unavuje celkově. Příliš unaveného programátora je někdy potřeba z práce vyhnat klackem (zejména pokud pracuje na něčem co má fyzický výstup). Ale to už je otázka nalezení vhodné míry přesčasů. To tu zatím do hloubky nikdo neřeší.

[TVL]

Realita je ta, že u IT projektů se časová náročnost odhaduje velmi blbě. Hůře než v jiných oborech - a to i v případě, že by ten projekt měl použít řešení, která už všechna byla použita jinde.
Pokud budete řešit něco nového, něco co jste ještě nedělali (nebo nedejbože to nedělal zatím nikdo), tak jediná správná odpověď na časovou náročnost projektu je "fakt nevím". Nějaké hodiny se samozřejmě nacenit musí, takže se tam něco napíše a nějaký termín se stanoví. Ale že se to potom do těch hodin a termínu nevejde je běžná věc.
Pokud někdo (tedy kromě javamana) umí třeba odhadnout, za jak dlouho by se dal naprogramovat systém, který bude řídit hejno dronů (nebo letadel) tak, jak funguje hejno živých ptáků, tak by mu bylo mnoho týmů po světě dost vděčno :-) Ale nemusíme chodit až k tak hi-tech projektům. Ono často stačí, že chcete prohnat data přes nějaký framework a zjistíte, že v aktuální verzi toho frameworku je chyba (a autor frameworku vám neudělá hotfix, bude se čekat na release, který bude za pár měsíců). A bum - to co mělo být za 3 dny hotové budete ohýbat přes jinou funkcionalitu a bude to trvat 3 týdny.

Tak ono by to IMHO celkem dobre slo odhadovat, kdyby se dusledne pouzivalo ciste funkcionalni programovani s korektnim rizenim vedlejsich efektu. V takove situace muzeme cely program, ktery je potreba upravit, rozdelit na dve casti - na cast, kterou zcela jiste potreba upravit neni, protoze typova signatura (a tedy i semantika zustala totozna), a na cast, kterou potencialne potreba upravit je. Pak horni odhad celkove doby upravy te potencialni odpovida casu, ktery byl potrebny k jejimu napsani (tedy, "v nejhorsim to muzeme cele prepsat"). (Lze vznest ruzne namitky, ktere nebudu adresovat pro omezene mnozstvi prostoru, ktery k tomu zde je.)

Duraz na FP totiz dava konecne zpusob nakladat s programem jako nakladame s objekty realneho prostoru - vime, ze treba postavit vilu nebude trvat dele, nez postavit mrakodrap, protoze proste vila ma mensi objem. To dava pevnou, neprekrocitelnou hranici odhadu.

Casem se to tak IMHO bude delat, ale zatim je to jen budoucnost, bohuzel.

Takže všechny problémy SW inženýrství se kterými se obor potýká prakticky od začátku (no dobře, tak ne všechny, ale jeden z hlavních) vyřeší nová zázračná věc.
Skvělé.
A pro těchto pár let je do té role vybráno.... chvíle pro napětí... FUNKCIONÁLNÍ.....začátek aplausu..... PROGRAMOVÁNÍ..... aplaus pokračuje.

[davkol]

Nová věc od asi šedesátých let.

[TVL]

Mezi délkou pracovní doby a produktivitou práce je nepřímá úměra.

Tvrdí kdo? Nepochybuji, že to tak NĚKDY bude. Ale opravdu je to TYPICKÉ?

https://cs.stanford.edu/people/eroberts/cs201/projects/crunchmode/econ-hours-productivity.html

Tohle je sice na stránce slovutné univerzity, ale není to absolutně ozdrojované, jak se k tomu přišlo.
Kdyby tam pracovali s tím, že ti, co dlouhodobě pracují 60 hodin týdně udělají méně práce než ti 40hodinoví, tak bych si řekl - možná, jak kdy.
Ale tam se přímo píše, že když 40hodinové pracovníky donutili dělat 60 hodin týdně, takže celkový výkon poklesl? Takže někdo, kdo je dlouhodobě dobře odpočatý je donucen dočasně dělat přesčasy a to způsobí, že bude celkově horší?
Nezlobte se, ale to je v rozporu s mým empirickým pozorováním světa.

http://www.economist.com/blogs/freeexchange/2013/09/working-hours

A tohle je akorát solidní blábol. Evidentně si pletou příčinu a důsledek (málo hodin práce přece nečiní společnost efektivní, to spíše přesně naopak, že společnosti, které z nějakého důvodu efektivní jsou si mohou dovolit a také dovolují pracovat málo hodin).
Korunu tomu nasazuje jmenovité zmínění Řecka, kde se odpracuje rekordní množství hodin. Jenomže každý, kdo se o situaci zběžně zajímal ví, jak to v Řecku funguje. Že mnoho těch hodin je buď fiktivních, nebo proflákaných. Jak má mnoho řeckých učitelů dva úvazky, ale oba mizerně placené a v obou toho moc neodučí, takže ještě dělají soukromé doučování. Takže pak má 80 hodin týdně jako fík. Že doopravdy odpracoval třeba 20, to už statistika netuší...
V grafu se snaží přepočítávat HDP na kupní sílu, což ale stejně nepotlačuje to, že bohaté země z toho vycházejí lépe.

[javaman ()]

OMG, on to asi nemyslel tak, že je to nové.

A zároveň to říká, jak je FP super, když se tolik rozšířilo za tu dobu. Ale za to můžou určitě ilumináti, protože ten zázrak drží pod pokličkou.

[javaman ()]

Prostě mícháte hloupé dělníky, kde čas navíc pomůže s opravdovými vývojáři, kde HO je standard a 8 hodin nepracuje ani jeden. Ono pokud za tři hodiny uděláš řešení, které tvoje lopaty za měsíc, tak se není co divit. To je efektivita.