Přejít k navigační liště

Zdroják » Různé » Vývojář si jen s programováním nevystačí

Vývojář si jen s programováním nevystačí

Články Různé

Programátor, který umí jen přepisovat algoritmy do programovacího jazyka, dnes ztrácí aureolu vysoce kvalifikovaného odborníka, a jeho cena na pracovním trhu neklesá, ale přímo padá. Pojďme se společně podívat, jaké základní schopnosti jsou nutné k tomu, aby se z tuctového „ťukače kódu“ stal Vývojář.

Začneme aktuálním citátem:

Také samotné IT profese se mění – IT odborníci se transformují do kombinace IT specialisty a byznys konzultanta. Například systémový specialista se stává spíše IT architektem. Programátor se transformuje do analytika, který umí programovat. Případně musí odborníci zvládat více technologií najednou, takže jsou schopni nabídnout balíček řešení. Firmy očekávají, že za své peníze získají všestranného a velmi užitečného zaměstnance. – Petr Krčmář, Kde a jak získat IT práci i v nejisté době – Root.cz

Je to tak. Bývaly doby, kdy se člověk naučil základům algoritmizace, k tomu jeden či dva programovací jazyky, a s referenční příručkou v ruce mohl zaťukat na libovolné dveře v libovolné IT firmě, tvrdit, že je programátor – a byl přijat! Jenže heroické časy solitérních tvůrců pominuly a tvorba software se stala postupně průmyslem se vším, co k průmyslové výrobě patří: s normalizovanými technologickými postupy, s ověřenými a opakovatelnými modely vývoje, postavenými nikoli na nejistých záblescích osvícení geniálního tvůrce, ale na hrubé síle mnoha průměrných…

Webový vývoj má za vývojem software obecně několik let zpoždění – a to nejen co do nástrojů a možností, ale i co do organizace práce. Ještě před deseti lety byla významná část úspěšných webů tvořena solitéry, popř. malými týmy kolem výrazného tvůrce. Během posledních let se i „webová vývojařina“ proměnila a stále víc se prosazuje týmová práce, standardizace a „zprůmyslnění“ celého odvětví.

PHP code ilustrace

Velkému množství webových vývojářů připadá, že jim stačí znát PHP (nebo Javu nebo ASP.NET), SQL, JavaScript, HTML a CSS – a mají vystaráno a jsou profesionálové, schopní tvořit jakékoli weby. Pokud náhodou umí všechny tři programovací jazyky, mají absolvovaný předmět „Algoritmy a datové struktury II“ a opravdu umí programovat, mohou se snadno považovat za programátorské mistry. Jenže ani znalost tří jazyků v praxi pomalu nestačí.

Dobrý vývojář musí totiž znát (kromě programování) spoustu věcí, které ho ve škole nikdo nenaučí a které z manuálů, referenčních příruček a učebnic programování nevyčte. Namátkou: Řešení obchodních záležitostí. Zákonitosti návrhu uživatelského rozhraní. Reálná práce s týmovými nástroji. Analýza reálných zadání. Komunikace s ostatními členy týmu, s lidmi v reálné firmě (např. s manažerem, s obchodníky či oddělením marketingu), se zákazníkem…

Pokud nepřemýšlíte pečlivě, můžete dospět k názoru, že programování spočívá v psaní příkazů programovacího jazyka. (Ward Cunningham)

Samosebou, každý má možnost říct: Já jsem přeci PROGRAMÁTOR, tyhle věci za mne má řešit někdo jiný, já jsem od toho, abych programoval… Ano, ale takový „programátor“ je něco jako dělník u pásu – ráno přijde do práce, osm hodin dělá to, co má v pracovní návodce, a pak jde domů. Je dobré si takovou praxí projít, to ano, ale zůstat na této úrovni znamená, že budete pro trh práce čím dál tím méně použitelní – na vaše místo se tlačí spousta čerstvých absolventů s minimálními finančními nároky, a vaši „praxi v oboru“ bude jen stěží někdo ochoten zaplatit.

Co by měl vývojář umět?

Schopnost přesáhnout úzce vymezené hranice oboru a komunikovat i s dalšími lidmi v týmu i mimo něj se ukazuje při tvorbě webů (a software obecně) jako mnohem důležitější než to, aby PHP programátor uměl dělat webdesign, webdesignér uměl psát HTML kód a kodér znal SQL. Je fajn umět jednu disciplínu perfektně a v dalších se alespoň orientovat. Je úžasné, když je někdo perfektní hned v několika disciplínách. Ale pokud se naše schopnosti omezují jen na obory spojené s „ťukáním do klávesnice“, brzy zjistíme, že nám cosi důležitého chybí.

Schopnost organizovat práci

Pravděpodobně základní netechnická schopnost každého vývojáře. Ačkoli se hardcore programátorům může zdát, že jde o kravaťáckou disciplínu, je dobré se alespoň zorientovat v metodikách organizace práce, používaných při vývoji. Využijeme je totiž nejen při řízení týmu, ale i při uspořádání své vlastní práce.

Při učení této schopnosti můžeme začít u GTD (např. tímto blogpostem o GTD na Rootu) a u Agilních metod a technik (viz též miniseriál na Zdrojáku o agilních metodách). Lze si prostudovat materiály o metodě Getting Real (Agilní vývoj: Getting Real). Metod pro organizování práce je mnohem víc, ale tyto patří mezi nejznámější a při vývoji software asi nejpoužívanější. Existují i nástroje, které pomáhají v dodržování výše zmíněných metod.

Stejně jako v jiných oblastech platí i zde: Je lépe pochopit a upravit si metodiku podle svých potřeb, než bez pochopení principů pouze mechanicky aplikovat naučené poučky.

Schopnost týmové práce

team spolupráce ruce

Je to tak – doba geniálních všeumělů, co zvládli udělat všechno sami, pominula. Jste-li geniální všeuměl, smiřte se s tím, že v reálném světě nikdo nedokáže postavit rozumný byznysplán na tom, že vás osvítí múza. Nikdo vám neupírá právo ani schopnost přijít s něčím převratným, ale tahle schopnost je pro průmysl (a tudíž i pro trh práce) stěží využitelná, protože není předvídatelná. Pokud se s vaším géniem snoubí zároveň talent s nikým nevyjít, jste pro moderní vývoj téměř nepoužitelní.

Je to možná smutné, mnozí (včetně mne – pozn.aut.) to považují za konec romantických a báječných časů velkých hrdinských skutků, ale taková je realita.

Schopnost týmové práce se nedá naučit z žádné metodiky ani z knih. Jedinou použitelnou radou je: Buďte členy týmů co nejčastěji. Ať už jako ti nejlepší, nebo jako ti nejslabší. Když jste v týmu nejlepší, učíte se vést a inspirovat; když jste ten nejslabší, máte příležitost naučit se od lepších.

Schopnost obchodního myšlení

Není potřeba studovat ekonomii do hloubky, vystačíme si do jisté míry se „selskou logikou“ a „kupeckými počty“. Důležité je připustit si, že programování a vývoj SW není umělecká disciplína ani magie, ale řemeslo, a to řemeslo by nás mělo uživit. Spousta programátorů jako by žila v zajetí představ, které vznikly kdysi v 60. letech a které se dodnes drží v některých oblastech – totiž (s trochou nadsázky) že komerce je sprosté slovo, neslučitelné se vznešeným posláním programátora, a že programátor by měl pracovat bez nároku na odměnu a svou práci dávat k dispozici zdarma pro blaho všeho lidu (nebo alespoň komunity). Jenže obchodní myšlení využijeme velmi dobře i při vývoji open source a freeware, protože v něm nejde zdaleka jen o peníze, ale především o smysluplnost konání – tedy především o to, aby směřovalo k nějakému efektivnímu uspokojení potřeb.

kalkulačka

Jak se tedy naučit obchodnímu uvažování? Stačí si pro začátek nahradit ošklivé a komercí zavánějící slovo „byznysplán“ nějakým neutrálnějším výrazem – řekněme „plán rozvoje a rozšiřování vašeho webu pro následujících pět let“. Kolik času chceme webu věnovat? Kolik to je v průměru na jeden den? Co je naším cílem? Jak budeme vyhodnocovat, zda se nám daří nebo ne? Jak budeme web propagovat? Kolik nám propagace zabere času? Co budeme dělat v případě, že se bude dařit? Co v případě, že se dařit nebude? Zkrátka takový jednostránkový soupis důležitých bodů, itinerář, kterého se při vývoji a provozování budeme držet. Ačkoli se v něm neobjeví ani jednou slovo „peníze“, jistě změní náš pohled na to, co děláme a jak – místo okouzlení možnostmi software a hardware začneme uvažovat nad efektivitou, nad smyslem a hodnotou práce, nad hodnotou času…

V zásadě jde o to uvědomit si, že psaní software není pro profesionála nějaká „vnitřní nutnost“, ale konání, které má nějaký účel, nějaký cíl, smysl, … a že tyto faktory nevisí ve vzduchoprázdnu, ale musí zapadat do požadavků a potřeb reálného světa. Až na výjimky totiž platí, že zákazník (nebo okolní svět) má nějaké potřeby, které chce vývojář naplnit svým konáním, a vice versa… Obchod a peníze jsou jen univerzálně dohodnutou abstrakcí pro vyjádření těchto vztahů.

Schopnost porozumět potřebám okolního světa, porozumět jazyku, kterým okolní svět o těchto potřebách promlouvá a domluvit se s ním je pro dobrého vývojáře kruciální, ať už pracuje na jakékoli pozici – podle pozice je jeho „okolním světem“ vedoucí týmu, vedení divize, vedení firmy, obchodní oddělení nebo zákazník, ale princip zůstává stejný.

… a hlavně by měl umět programovat!

Ano, to by programátor měl umět především. Ale neměl by spoléhat na to, že si vystačí jen s tím, že umí převést problém do algoritmů a zapsat je v nějakém programovacím jazyce. Pro programátora je umět programovat nezbytné minimum a samozřejmost, asi jako je pro rybu nezbytné minimum umět plavat – s trochou zdravé provokace se dá říct, že programátor, který umí jen programovat, vlastně neumí nic. Že je často problém sehnat programátora, který opravdu umí programovat a ne jen psát kód, je jiná věc, a je smutnou realitou, že u webového vývoje to platí dvojnásob.

Schopnosti vývojáře SW se totiž dnes pomalu začínají počítat až za hranicí práce s počítačem. Výše uvedené dovednosti zvyšují naši hodnotu na trhu práce – a tím i šanci, že budeme dělat to, co nás baví, a budeme za to slušně placeni. Znalost obchodu, organizace, komunikace, trhu či managementu, tedy oborů, které se netýkají přímo programování, ale s vývojem souvisí, zvýší náš náskok před ostatními mnohem víc, než znalost dalšího programovacího jazyka.

Závěrečné pravidlo, které shrnuje a doplňuje vše, co bylo výše řečeno, by se dalo vyjádřit zhruba takto: Je důležité mít na paměti, že software (nebo v našem případě web) není sám o sobě konečným cílem, ale prostředkem – a tomu přizpůsobit svoje chování a uvažování.

Komentáře

Subscribe
Upozornit na
guest
157 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
peter

Keby pri clanku nebol uvedeny autor, bol by som ochotny stavit sa, ze to pisal Vojtěch Bednář.

balki

Je pravda, ze skola je len takym zahrievacim kolom na prax, ale napisat toto:

<i>
rý vývojář musí totiž znát (kromě programování) spoustu věcí, které ho ve škole nikdo nenaučí a které z manuálů, referenčních příruček a učebnic programování nevyčte.
Namátkou: Řešení obchodních záležitostí. Zákonitosti návrhu uživatelského rozhraní. Reálná práce s týmovými nástroji. Analýza reálných zadání. Komunikace s ostatními členy týmu, s lidmi v reálné firmě (např. s manažerem, s obchodníky či oddělením marketingu), se zákazníkem… </i>

Na aku skolu to autor chodil 8-O ? Toto je prave obsahom uciva informatickej vys­ky.

balki

Ospravedlnujem sa za tie tagy :) Ale toto je hanba, nie clanok.

Aleš Roubíček

A mohu se zeptat, na které škole konkrétně učí pohybovat se v reálném prostředí? Problémem akademické půdy je, že je akademická. Od prsu praxe odtržená… :)

Pokud zrovna studujete nějakou IT výšku, je vaše reakce zcela přirozená, ale zkuste si o tom ještě chvíli přemýšlet…

pas2007

No třeba na informatice na VŠE (tam je možná spíš problém, že to samotné hard core programování se člověk musí doučit zase jinde. ;-))

Aleš Roubíček

Programování se moc naučit nedá, možná tak syntaxe programovacího jazyka. Buďto umíte logicky uvažovat a máte představivost, nebo ne. Tyto dovednosti se dají cvičit a zdokonalovat, ale nedají se naučit.

Pavel Šimek

Ano. Možná se spíš dají naučit ty věci okolo managementu projektu. Nebo se každopádně dají vyučovat. :)

uf

Ono se totiz uci jen jazyk, ale uz ne metodika navrhu programu ve velkem a v malem.

Aleš Roubíček

Co dělá program malým? :)

balki

Ked clovek pouzije zname techniky na analyzu systemu, vie si zistit, kolko modulov/syste­mov/subsystemov/roz­hrani potrebuje. Ked toho potrebuje malo, tak to zrejme nebude nic velke.

Aleš Roubíček

To pouze v ideálních podmínkách, kdy se zadání a požadavky nemění. BTW kde přesně probíhá hranice mezi velkým a malým? A podle jaké metriky se velikost projektu měří?

Hejty

Napriklad jednoducha kalkulace ( plus, minus, krat, deleno ) je mala aplikace.
A MatLab je velka aplikace :)

Radovan

To platí pro tebe, ale co když se na to podíváš z jiného úhlu?

MatLab je malá aplikace,
systém řízení raketoplánu je velká aplikace ;-)

balki

To ze sa lieta na miliardovych strojoch este neznamena, ze aplikacia je „velka“. Skratka rozsah tu sa mysli zrejme rozsah.

Co sa tyka softveroveho inzinierstva, je potrebne mat jednotnu terminologiu, lebo potom podobne myslienkove postupy vedu k nepochopeniu.

Radovan

Systémem řízení raketoplánu je myšlen kompletní software, který se na něm podílí, tedy především ten v pozemních počítačích, ne těch pár prográmků v jejich pěti palubních AP-101, odvozených z IBM System/360. Udávalo se, že je to počtem řádků vůbec nejrozsáhlejší software na světě, i když myslím že Windows jehoVista ho už předběhl :-P
Přece jen Space Shuttle byla špičková technologie sedmdesátých let, zajímalo by mě jak velký byl soft pro palubní (super)počítač o dekádu modernějšího Buranu, který měl 74 procesory.

balki

Ale ano, ok beriem spat, nepoznal som to. To je ako ked poviem, ze mam velky penis. Vsetko je relativne. Ale ak by som sa pohrabal, nasiel by som klasifikaciu podla zauzivanych metrik. Respektive by som nasiel mieru „ozrutnosti“ software podla prirovnania k znamym projektom.

(Medzi nami dievcatami, pocet riadkov kodu nie je prave najlepsia metrika)

Radovan

To je fakt, počet řádků není úplně spolehlivé měřítko, ale museli se přece něčím vytahovat, k nejsložitějšímu stroji potřebovali i nejsložitější soft ;-)
Jen pro zajímavost k těm raketoplánům, srovnání ruské konstrukční školy a americké, vlevo je původní AP-101 feritovou pamětí, vpravo modernizovaný AP-101S, odlehčený na nějakých 45 kg.

Kiki

Velký penis je prostě velký. Ať už si o tom (svém) ITíci myslí, co chtějí a snaží se dokázat, že zase TAK malej není, že je to jen otázka použité metodiky – tak zkrátka mrňavý je mrňavý a velký je velký.
To nejde okecat.

bitsmith

To, ze sa este zmesti do MCU ATtiny12 so 2-mi kiB FLASH a 256 B RAM s tou podmienkou, ze nebudu nalinkovane kniznice, obzvlast nie libc, a ze bude napisane vsetok kod v asembleri s prihliadnutim na dostupne instrukcie, ktore umoznia pozadovanu funkcnost s vyuzitim FLASH na 98% ;-)

uf

To jste naplkali blbosti.

Na obecne reci jsem dost alergicky. Asi jako kdyz se mluvi o zakone, zacnou same ale …, da se zneuzit … . Nakonec zapomenou na podstatnou a zjevnou variantu.

Čermi

Další věc, která se dá procvičit na výšce je způsob abstraktního algoritmického nebo matematického myšlení – bez schopnosti abstrakce nad řešeným problémem často vzniká hrůzostrašný kód :)

balki

Studujem na FIIT v Ba. Mohol som to porovnavat s praxou. Na skole sa robili ozaj tie veci, co boli napokon aj v praxi potrebne. Dokonca sa dali aj identifikovat problemy v praxi, ktore boli sposobene neznalostou riadenia/ procesu analyzy problemov a niektore z nich ciastocne napravit. Niekedy sa „praktici“ dali aj presvedcit, ze veci robili nie celkom najlepsie a je priestor na zlepsovanie, niekedy zadubene trvali na svojom, no holt, co uz.

Co sa tyka realnosti, skolske problemy boli mensie co do rozsahu kodu, ale byrokraciou, problemami s komunikaciu, vrtochami „zakaznika“ sa to realnym problemom velmi priblizilo. (V praxi zakaznici trochu viac vymyslaju a je menej byrokracie ).

Skuste vy popremyslat. Obvykle sa najde vela ludi, ktori dokazu jednou vetou kazdeho zhodit, len preto ze maju o niecom mylny obraz. V skole samozrejme nevyrobia dokonaleho manazera/analytika, to prichadza az s praxou. Rozhodne vsak nemozem povedat, ze sa na skolach nic v tomto smere nerobi a ze sa tlacia studentom kaleraby do hlavy.

o

Nesouhlasim. V soucasne dobe, byt mozna jen 1 nebo 2 IT VS v Praze, jsou zalozene na nikoliv akademickem, ale spise korporativnim pristupu ke studentum. Vyucuji predevsim odbornici z praxe a veskere semestralni, seminarni a rocnikove prace se maximalne priblizuji realnym projektum.

Clanek je ale trefny a neni mu co vycitat. I pres moji reakci je praxe v realu vzdy uplne jina a nenahraditelna jakymkoliv ustavem ;)

ahl

Na takovou školu bych teda nešel. Proč bych měl ve škole dělat to samé co v praxi, když v praxi za to dostanu zaplaceno. Ve škole by se člověk neměl učit konkrétní znalosti, ale principy jak věci fungují, jejich teoretický základ a jak se má učit nebo kde hledat materiály ke studiu.

K článku si myslím, že autor píše spíš o samoucích, kteří žádnou školu nemají. Průměrný absolvent VŠ má dostatečné povědomí o všech těchto problémech a stát se opravdovým odborníkem v tom či onom trvá dlouho a rozhodně není cílem jakékoliv školy tohle dělat.

uf

Prumerny absolvent VS ma mit vseobecne povedomi o tematech a technologiich, ale v pripade IT je nutne mit nejakou praxi. U lekaru by to ani jinak neslo.

Jsou studenti, kteri uz ve druhaku delaji pro firmy, a jsou studenti, kteri vecer pred odevzdanim primitivniho programu v jave obtelefonovavaji zname a ptaji se, co to je ta java.

Michal Augustýn

S článkem vzásadě souhlasím, ale tenhle citovaný odstavec mi taky nepřijde moc aktuální. Nevím, jestli má třeba Martin na mysli nějakou konkrétní školu, ale takhle bych rozhodně negeneralizoval. Např. na ČVUT FEL jsou i manažersko-ekonomické předměty stejně jako předměty o návrhu GUI nebo o vedení projektů. A pokud člověk není ignorant, tak má dost času všechno konfrontovat s praxí…

Btw. za učebnici programování považuji i třeba i učebnici o agilních metodikách vývoje – tak snad mám správný směr :)

Aleš Roubíček

Asi jsme každý chodili na jiný FEL nebo jsem opravdový ignorant. :) Třeba takové Softwareové Inženýstrví mělo něco podobného v osnovách, ale výsledný efekt byl pro mne neuspokojivý.

Václav Novotný

To je asi subjektivní a otázka konkrétních lidí (cvičících). Mně třeba tenhle předmět pomohl zorientovat se v základech, a to jsem ani skoro nechodil na přednášky. Ještě dnes si občas vzpomenu, že jsem tam slyšel o tomhle a o tomhle. Důležitý IMHO není to, aby tě na škole naučili všechno, ale aby ti dali základ pro samotudium.

Michal Augustýn

Jo, Softwarové inženýrství s Doc. Rychtou byl jeden z nejhorších předmětů, jaký na FELu byl :)
Ale jakožto neignorantský student (to si fandim, co? :)) jsem se zajímal, proč se něco takového u nás učí, jaký to má smysl, a vyhledal si pořádnou literaturu o daném tématu (překvapivě z nejtěžšího gymplu v Praze). Takže ve výsledku mi jen přítomnost předmětu mezi povinnými hodně dala…

Obdobně byl na tom předmět Návrh uživatelského rozhraní – kdo chtěl, mohl jím projít nepoznamenán. Ale když se člověk začetl do slajdů a trošku pogůgloval, tak se dozvěděl spoustu zajímavých věcí. A praxe v Sunu (nebo IBM), praktické usability testy (i ve speciální laboratoři) – k nezaplacení!

Takže stále trvám na svém – neignorantský student se na kvalitní škole může dozvědět nejen programátorské, ale i vývojářské věci ;-)

Joey

Jako „neignorantský student“ bys mohl aspoň vědět, že se Karel jmenuje Richta :)

Michal Augustýn

Já jsem si to uvědomil hned při prvním čtení od publikace názoru ;-) Ale úprava komentářů tu není :(
O náhledu vím a používám.

Michal

Predstava, ze vylezu z vysky a jsem hotovy odbornik je IMHO zcestna, at se na te skole vyucuje cokoliv a jakkoliv. Podobne myslet si, ze me skola nauci tak, ze mi realna praxe nic neprinese, je IMHO blbost – a to mel dle meho nazoru autor clanku na mysli.

Michal Augustýn

„Predstava, ze vylezu z vysky a jsem hotovy odbornik je IMHO zcestna, at se na te skole vyucuje cokoliv a jakkoliv.“

IMHO není. Pokud je člověk jen trošku schopný, tak je možné při výšce pracovat a tím se znatelně přiblížit stavu „jsem odborník“.

prochor

Jeste pred par lety, tu zadna takova skola nebyla, tzn ze velka cast aktivnich zkusenych vyvojaru zadnou echt skolu nedelala, pac proste nemela moznost.

A to, na co autor poukazuje je opravdu rozsireny nesvar, psany a mluveny projev valne vetsiny vyvojaru/progra­matoru je neuveritelny, vetsinou poznate z prvnich nekolika slov, jestli ta komunikace nekam povede :)

Cim dal casteji se setkavam s velkou aroganci a nevychovanosti, zvlast u mladych lidi, nehlede na to, ze vetsina ani neumi psanym projevem vyjevit, co vlastne od vas chce. Casto jim chybi respekt uci ostatnim, proste bida.

Celkem me to stve, protoze jsem take vyvojar/progra­mator, relativne mlady a spatne svetlo pak pada na nas vsechny. Asocialni nekomunikovatelna hovada, tak se s nimi radsi nebavte, pac to nema cenu, tot vlatsni zkusenost…

Mozna to vidim moc cerne :)))

tomo19

balki je z fiitky to svedci za vsetko :) z vlastnej skusenosti mozem povedat z vlastnej skusenosti ze metalita studentov na balkiho skole asi taka, ze realne sa tam fakt neda naucit sa pohybovat v realnej praxi…mozno v nejakych pridruzenych obcianskych zdruzeniach ale ak si balki mysli ze ho toto skola nauci tak sa mali…jedine co stoji za zmienku ze je tam jedna profesorka ktora studentom pocas prednasky rozprava hocijake hinty z praxe vyvojara ale…to stale nieje prax…a citujem tu profeserku: „zamestnanci si nasich absolventov chvalia ze su dobry v praxe, ale co ich trapi ze su to taky busiaci informatici, ktory pridu do firmy, sadnu si za pocitac a zacnu busit do klavesnice. ale ak maju prezentovat svoj nazor alebo spravit firemnu prezentaciu tak nastava problem“ → takze na takejte skole len tazko mozete vediet co na vas caka v praxi kde su ozajstny vyvojari a nie socky z informatickej fakulty…takze balki nerob si srandu z ludi na tomto fore lebo som naozaj chodia odbornici a chod si svoje trapne pripomienky pisat na fiitkar.sk

martin

Zajime, me napadlo uplne to same:-)

dc

Dost nekonzistentny clanok.Na vyvoj akeho sw sa to vlastne vztahuje ? Na zaciatku je nieco o webovom vyvoji ale dalej ani ň.
Nehovoriac ze su uplne odlisne ak nie protichodne poziadavky pri malom teame a malom projekte oproti povedzme nejakemu rozsiahlemu projektu a teamu 20–50 ludi/programa­torov/vyvojarov. A to uz ani nehovorim ze urcite bude rozdiel pri programatorovy mikrokonrolerov vs. programator PL/SQL alebo nejakej desktop aplikacie. Mimochodom tvrdenie ze web development je pozadu za vyvojom obecneho sw je podla mna blbost. Web development neni pozadu ale je nieco medzi totalnou anarchiou (ktoru sa snazi zopar spolocnosti a organziacii riadit) a PR napadmi roznych vyvojarskych,re­klamnych a dalsich spolocnosti typu kupte si tento nastroj/technologiu a mate vystarane alebo ziadajte od svojho dodavatela webu tuto technologiu a budete in…
A tento postoj ze jeden programator alebo vyvojar ma byt multifunkcny robot ktory ovlada vsetko je uz uplna utopia. Maximalne moze ovladat velky pocet technologii ale bude to na povrchnej urovni. Vzhladom na to ako bobtnaju moderne frameworky, to nieje ani mozne, a to je bohuzial aj dalsi negativny vpliv tohto trendu. Mohutne frameworky, kopec rad nastrojov kde sa naklika vsetko mozne ale vysledok je otrasny.

Aleš Roubíček

Moc pěkný článek Martine, gratuluju. Sám jsem se něco podobného chystal blognout. :)

Z reakcí je jasně vidět, že jsi se trefil do bolavého místa našeho trhu.

tojefuk

+1

Pointa „konec doby geniálních všeumělů“ je v našich poměrech přesná.

norwi

Pro me je nejdulezitejsi jedina informace.

DOBA KDY STACILO UMET S PC a byl jste nejlepsi tady byla taky.

Ja s clankem souhlasim. Dnes uz je potreba umet vic nez jenom byt dobry ve svem oboru.

Cim dale vice zalezi na porozumeni zakaznikovi a ve spravnem case mu nabidnout samotny dalsi produkt. Po technicich ktery implementuji reseni se zada komunikace se zakaznikem a pripadne presvedceni zakaznika o dalsi spolupraci, nebo lepe nabidka dalsiho produktu. Jiz nestaci prijit, nainstalovat a odejit.

Co se tyka diskuze o skolach: Vzdy zalezi na konkretnim studentovi. Spatny kantor muze blbe ucit, ale dobry student to pochopi a vezme si s toho jen potrebne a mrkne se jinam.
Podle me se porozumeni k zakaznikovi neda naucit. Co clovek to preci unikat.

uf

Skola te taky muze otravit. Me treba znudil gympl, kde z nas delali chodici encyklopedie. Pametni uceni na me nebylo.

Uz jsem slysel i o pripadech, kdy lide vhodni pro onu profesi nechali skolu.

stej

Na mě to spíš působí, že je to napsáno pro programátory-živnostníky.

Sám pracuju ve firmě, kde máme pozice pevně rozdělený a opravdu se nedostanu ani pidikouskem do obchodních věcí. Je to záležitost obchodníků, kteří vlastně nejsou ani v našem městě (a zemi). Měl bych se o to zajímat?

Týmová spolupráce? Ta přece byla potřeba vždycky, pokud člověk pracoval v týmu.
Tady se přeci nic už docela dlouho nemění a vlastně měnit nebude. Když nejsi schopen pracovat v týmu, uděláme ti pápá..

Schopnost organizovat si práci. Ano, rozhodně důležité. Ale opět – změnilo se za posledních 10 let něco pro člověka, který pracoval ve firmě? Nic, pokud nejsi schopen pracovat s termíny (a jsou s tebou další problémy), zvážíme tvůj přínos a uvidíme. A pokud to firma tolerovala, protože člověk byl „odborník“, bude tolerovat i nadále.

Pro mě prostě tento článek žádný přínos neměl.

Equilibrix

+1

Naprosto souhlasím s tímto komentářem. Též pracuji ve firmě (40–50 zaměstnanců), kde je pracovní pozice pevně dána a je dokonce nežádoucí, abych se míchal do nějakých obchodních záležitostí. Bez schopnosti týmové spolupráce bych ve firmě již dávno nebyl a stejně tak pokud bych neplnil deadliny.

Pokud je článek opravdu psán pouze pro programátory-živnostníky, konkrétně tedy „webaře“, s pár výhradami bych se s ním ztotožnit mohl – jedním jsem také kdysi býval. Obecně je však neaplikovatelný na jakýkoliv větší vývojářský tým.

Aleš Roubíček

Slovem business v článku asi není míněm obchod, že. ;)

Equilibrix

To není, já však reagoval na podkapitolu „Schopnost obchodního myšlení“, která se již obchodní stránky vývoje software týká.

Aleš Roubíček

To ovšem stále neznamená, že vývoj kecá do kšeftu obchodníkům, ale že vývoj se má chovat ekonomicky a tržně. Ve velké firmě je vaším „zákazníkem“ právě obchodní oddělení. A také to, že s obchodem v tomtu případě komunikuje pouze vaše PM, je špatně.

Equilibrix

Nevím, kde jste vyčetl, že s obchodním oddělením zákazníka komunikuje pouze náš PM, stejně jako to, že bych snad ve svém minulém příspěvku mínil slovem business obchod, přestože jsem takové slovo nepoužil a ani se na něj neodkazoval – toliko k „předmětnosti“ obou Vašich reakcí.

Chtěl jsem pouze říci, že vývojář u nás nemusí mít ani základy ekonomiky, jelikož se k žádným číslům týkajícím se obchodní stránky projektu nedostane, a troufám si říci, že rozhodně nejsme jako firma výjimkou (neříkám však, že by tyto znalosti neměly být ve výbavě každého člověka, ať již programátora či kohokoliv jiného). Pokud však člověk pracuje „sám na sebe“, je samozřejmě situace jiná a mohu se s tvrzeními v článku ztotožnit. V článku však není uvedeno, zda se týká právě živnostníku nebo i větších firem, a proto k němu mám (a ostatní též) určité výhrady.

Aleš Roubíček

Nepsal jsem, že Váš PM komunikuje s obchodním oddělením zákazníka. Pokud to tak vyzněla, tak se omlouvám.

Ad korporace vs. živnostník. Tohle nikterak uvedeno být nemusí, protože z principu v tom rozdíl není. Živnostník ty soft skilly mít musí, jinak by se neuživil, v korporaci může existovat „teplé klidné“ místečko, ale to je IMO špatně a není to ani v zájmu vývojáře ani korporace.

Equilibrix

Omluva přijata :)

Ano, z principu projektu a jeho obchodní stránky v tom rozdíl není – projekt musí vydělávat ať na něm dělá jeden živnostník nebo velká firma. Rozdíl je však právě v té výbavě jedince; zatímco živnostník ty ekonomické schopnosti mít musí, protože to za něj nikdo jiný neudělá, ve velké firmě je to naopak, jelikož tam se o ekonomickou stránku věci řadový vývojář zpravidla zajímat nemusí. A článek pojednává právě o jedinci, přičemž říká, že tato výbava je téměř nutností pro každého „novodobého“ programátora. S tím však, s odkazem na své minulé příspěvky, nemohu souhlasit.

Myslím, že oba již navzájem dostatečně chápeme svá stanoviska a asi již nemá cenu v této diskusi pokračovat :)

Inkvizitor

Z reakcí nic podobného vidět není. Nevím, jak jsi došel k takovému výsledku. Článek, který je plný polopravd a zavádějích tvrzení, se stane kvalitním jenom proto, že ho někdo zkritizoval? Mama mia!

Aleš Roubíček

Můžeš uvést polopravdy a zavádějící tvrzení? Prosím.

Inkvizitor

V prvé řadě se mi nezdá, že by platy šly nějak výrazně dolů. Odporuje to mojí zkušenosti a ani inzerce tomu nenapovídá. Výše výdělku se samozřejmě liší podle toho, kde daný člověk pracuje, co umí a co si dokáže vyjednat, ale tak tomu bylo, co si pamatuju, vždycky.

Dále není pravda, že školy učí „jenom“ programování. Možná jsi nebyl spokojený s tím, co Tě doc. Richta nebo někdo jiný na FELu naučil v Softwarovém inženýrství, ale když nic, tak jsi tam alespoň získal nějakou představu o tom, že něco podobného existuje. Zrovna tak bychom mohli tvrdit, že vysoká škola nenaučí člověka pořádně programovat a byla by to samozřejmě pravda.

To, že psaní programů je přepisování algoritmů do kódu, je další polopravda. V malých týmech tomu tak není a ve velkých to tak může fungovat, ale pak zase neplatí to, co tvrdí článek – tam jsou procesy holt tak nastavené. Že takový člověk musí umět aspoň základní komunikaci, pravda je, ale ta je natolik zřejmá, že snad nemá cenu o tom psát.

Hlavní poblém spatřuju, spolu s jinými, že ta tvrzení se zjevně týkají nějakého segmentu, který autor nejmenoval, ale z článku naopak vyznívá, že ta tvrzení platí v celém oboru. Nevím, jestli to měl být záměr, ale výsledek je dost rozpačitý.

Já jsem ale protestoval proti Tvému tvrzení obecně. To, že je nějaký text hojně kritizovaný, může sice v některých případech znamenat, že tzv. ťal do živého, ale pravděpodobnější je, že v tom textu jsou nedostatky. Takže se bavme o konkrétních námitkách kritiků; to poplácávání autora po zádech mi přijde zbytečné. On se z kritiky (snad) nezhroutí.

radek

jen bych rad v te zaplave „kritiku“ chtel napsat, ze jsem si clanek precetl a velice se mi libi.
A hlavne je realne pravdivy (kosmuzel, kosmudik… :) )

ondra.novacisko.cz

Článek jsem nečetl celý, protože mě to odradilo už v prvních větách. Protože s nimi nesouhlasím.

Programátor je cvičená opice, které někdo dá úkol a ona to přepíše do kódu. Jde jen pouze o úroveň, tedy ta nejnižší pouze přepisouje algoritmy, ta vyšší je vymýšlí a da další třeba zadává úkoly pro které je třeba vymyslet algoritmy.

Píšu to z vlastní zkušenosti, protože v určitých ohledech jsem ta cvičená opice. Málo koho z vyššího vedení zajímá, co jsi použil za algoritmus pro seřazení desítky milionů čísel. To člověk musí obchájit pouze horizontálně, tedy s ostatními v teamu, maximálně tak s nejbližším seniorem.

Důležitá je podle mne komunikace v teamu. Dobré je, pokud se problému udělá porada, do které každý „coder“ přináší vlastní pohled na daný úkol, vlastní návrh řešení, a kde se dělá ten pravý brain-storming. Ale pak porada skončí a jde se kódovat, každý ke svému stroji, každý řeší ty svoje drobné problémy, jako jak navrhnou meziksicht tak, aby na to mohl soused navázat se svým modulem, který bude hotovej koncem týdne.

A ze své zkušenosti vím, že programátor-team-leader-projektant-produkťák většinou neumí programovat, vést tým, projektovat projekt, obchodovat, ani vymýšlet obchodní model. Často na to ani nemá čas.

Václav Novotný

Pokud je pravda, že většina programátor-team-leader-projektant-produkťáků neumí programovat, nebyl byste ráději, kdybyste na takových místech měl výborné programátory, kteří na základě tohoto článku vstřebali více obchodních znalostí a šli vám dělat vedoucí?

ondra.novacisko.cz

Ani ne. Pod slovem výborný programátor si představuju člověka, který programuje i v noci ve spánku. Po takovém člověku nemůžete chtít, aby dělal obchoďáka. I karierní postup je problematický. Pokud má někdo dělat vedoucího, musí mít vůdčí schopnosti. Pokud je nemá, nemůže vést tým. A někteří ani nechtějí.

Tím nechci programátorům upírat postup v kariéře. Jenže to nejde dělat klasicky stylem, skladník ⇒ vedoucí skladu ⇒ vedoucí skladovacích prostor ⇒ vedoucí oddělení ⇒ vedoucí pobočky ⇒ ředitel. Už protože, že skladník těžko bude umět dělat ředitele, bez patřičné rekvalifikace. U programátorů je třeba se zeptat, zda vůbec se chtějí rekvalifikovat. Mnoho špičkových programátorů spíš dál rozvíjí své znalosti v oblasti programování a nepotřebují se rekvalifikovat na něco jiného. Otázka ocenění špičkového programátora je o nečem jiným. Špičkový programátor se rozhodně od nováčka pozná a dobrý team leader by to měl poznat taky.

Už jsem několikrát viděl, jak špičkový programátor vedl tým. Mezi kamarády tomu říkáme „rozklad velení“. Proč asi? Programuje a na tým nemá čas.

drevolution

Aha, tak v tom případě si asi nerozumíme v tom, co znamená výborný programátor, respektive možná ani dokonce v tom, co programátora dělá programátorem. Pro mě je výborný programátor takový, který:

– dokáže držet termín
– pokud ví, že překročí termín, tak o tom včas informuje
– chodí do práce v takový čas, aby se co nejvícesetkával se zbytkem týmu
– produkuje méně chybový kód než průměr, protože kód testuje
– je schopný mezilidské komunikace a má alespoň průměrný sociální intelekt
– dodržuje týmová pravidla pro psaní kódu a věci s tím spojené (způsob verzování atd.)
– zajímá se o novinky v oboru
– přichází s vlastními nápady na zlepšení

Asi by se dalo pokračovat dále. Co jsem ale chtěl říci je to, že výborný programátor pro mě není člověk, který jakoukoliv situaci algoritmizuje na úkor ostatních věcí. To není programátor, ale mimoň :)

ondra.novacisko.cz

Špičkový programátor je ten, který napíše kód, jenž není potřeba po půl roce předělávat. Nebo takový, který to napíše tak, aby po půl roce nebyl potřeba kompletní redesign (smazat a napsat znova). Nebo takový, který napíše kód tak, že chyba se v něm najde během minuty a doba vychytávání chyb je kratší než doba vývoje. Špičkový programátor napíše takový kód, který na výjimečné situace reaguje tak, že se nezhroutí, nesmaže půlku databáze, zareportuje stav a to tak, aby vyhledání problému zvládnul sám uživatel/admin. Aplikace špičkového programátora jsou stabilní, správně zareagují na všechny nepředvídatelné situace, jsou rychlé, a svižně reagují na uživatele. Kód špičkového programátora je dobře čitelný, rozhranní je podrobně okomentované a použití rozhraní je intuitivní, bez nutnosti pro každý případ užití kopírovat nutnou omáčku kolem toho. Kód špičkového programátora je domyšlený do detailu, řešící každou situaci, která může nastat, efektivní, rychlé, paměťově (prostředkově) nenáročné… a to v termínu, nebo ještě lépe před termínem. Špičkový programátor by měl šetřit čas a peníze a to i v případě, že si řekne o vyšší plat.

Samozřejmě všechny ty věci okolo, jako komunikace, verzování, doučování v oboru, jsou věci, který by měl zvládnout běžný programátor, o tom snad nikdo nepochybuje.

(s termínama je to problém, protože špičkový programátor pod mizerným seniorem bude buď vypadat jako lammer – ńa složité úkoly krátké termíny, nebo jako génius – totéž obráceně.)

Joey

Onehdá proběhla pěkná diskuse na builder.cz o tom, co je to „dobrý programátor“. IMHO to pěkně shrnul Miloslav Ponkrác:
http://forum.builder.cz/read.php?31,3239123,3239153#msg-3239153

A protože definic okamžitě uvolnil jako public domain, tak ji přetiskuju:

Velmi důležitá je definice významu „dobrý programátor“.

1) Definice ekonomická = ten, který vydělá nejvíce.

2) Praktická definice = ten, který umí vše, co je potřeba.

3) Buddhistická definice = ten, který ví, co dělá a umědomuje si přesně význam a důsledky každého řádku kódu, který napíše.

4) Genetická definice = ten, který má největší talent na programování.

5) Definice Hollywoodu = ten, který je nejznámnější jako programátor.

6) Definice vojenská = ten, který má nejvíce certifikátů a prošel největším množstvím školení.

7) Umělecká definice = ten, který jde svými cestami.

8) Definice šprta = ten, který zná nazpaměť referenční příručku.

9) Definice veterána = ten, který prošel všemi chybami a namlátil si hubu na všech možných průserech, co je možné, takže si dává pozor. Můžete se spolehnout, že s ním nedopadnete katastrofálně.

10) Definice prozíravosti = ten, jehož zdrojové kódy se dají dlouho udržovat, a není nutné je pro neudržovatelnost zahodit při prvním požadavku na další featuru.

11) Definice dobré architektury = ten, jehož programy mají promyšlenou architekturu.

Každý člověk považuje za dobrého programátora nějakou kombinaci výše uvedených bodů s různými váhami. Pro mě je to kombinace 2,3,4,7,9,10,­11 s důrazem na 3, 10, 11 a trochu 9.

Hodně jsou za dobré programátory považováni lidi, kteří splňují 5, 6, nebo 8, ale já toto ignoruji a tyhle důkazy nepovažuji za nic jiného, než public relation, případně schopnost se něco nadrtit nazpamět. Body 5, 6 a 8 jsou slepou uličkou, které mohou nastat jako vedlejší efekty při cestě za programátorskou virtuozitou, ale pokud tam není nic dalšího máte před sebou člověka, který si na programátora jen hraje.

heh

tak tahle definice je absolutne fenomenalni… s kazdym bodem musi clovek souhlasit… uz to pojmenovani… opravdu, hezky.. jinak clanek se mi moc nelibi… btw, zajimave ze v tomhle listu definice dobreho programataru neni ani slovo o tymu… naopak autor clanku rika, programator neni ten kdo umi programovat, ale ten kdo dobre vychazi s tymem atd bla bla bla

brebta

No, to je proste definice asocialniho solisty rozmrzeleho z toho, ze je cim dal tim mene vyznamny. Absence schopnosti spoluprace na ruznych urovnich tomu citelne chybi. Staci se podivat na nektere kauzy ohledne vyvoje linuxoveho jadra, kde rada (mozna) technicky dobrych programatoru narazila prave z duvodu nedostatecnych socialnich schopnosti.

František Kučera

Na druhé straně většina těch „sociálně schopnějších“ není schopná do jádra nic připsat a jen tlachají v internetových diskusích a říkají, co by se mělo…

bpbp

Nejen, že je fenomenální, ale také dobře použitelná jako osnova při přijímacích pohovorech.

A s trochou snahy se dá abstrahovat na jakoukoliv pozici.

uf

I kdyz nejsem spickovy programator (a je to asi cim dal horsi). Ale rizeni by me nebavilo. A ze vsech programatoru nemuzou byt vedouci.

Petr N

Souhlas, vedouci musi umet zaklad a bezkonfliktne rozdat praci podrizenym, tak aby ji bezchybne a nejlepe bez protestu vykonali. Na papiry ídealne sekretarku. (Myslim to vazne.)
Vedouci opravdu nemusi mit detailni znalosti problemu, ale musi mit prehled, respekt a nejlepe prirozenou autoritu (Neporouci, ale zada, je schopny pochvalit, pri prusvihu nerve, ale umi to vytknout rozumne, a je inteligentni minimalmalne stejne jako podrizeny.)

Tom5

Souhlasím. Jen bych místo termínu „cvičená opice“ použil slovo „voják“.

Ja.

Amen.

Lukas

mozna mi to uplne nedochazi, ale je clanek o tom ze je spatne umet od vseho trochu (doba geniálních všeumělů, co zvládli udělat všechno sami, pominula), nebo o tom, ze je dobre umet od vsecho trochu (programátor, který umí jen programovat, vlastně neumí nic) ??

Ten clanek je teda pekna slatanina.

ondra.novacisko.cz

Soustružníci soustruží, prodavači prodávají, instalatéři instalují, řidič řídí (autobusy), programátoři programují.

Je to řemeslo jako každé jiné, jde jen o kvalitu toho řemesla. Elektrikář Vám natahá dráty kam mu ukážete. Lepší elektrikář Vám k tomu udělá návrh rozvodů a zapojení okruhů tak, aby Vám lednička spolu s pračkou nevyhazovaly jističe.

Běžný programátor Vám nakóduje, co mu řeknete. Lepší programátor je schopen i nějaké té analytické práce, kdy může být výsledkem efektivnější aplikace, než si zadavatel přál.

Někdo umí jen to svoje, někdo umí „něco navíc“. Každý má svou cenu. Jde jen o úroveň. Ukrajinec zbourá, co mu ukážete, i přesto, že si při tom strhne strop na hlavu. Lepší stavař by měl umět posoudit i statiku objektu a odmítnout vybourat nosnou stěnu.

(zkušenost: kterak instalátoři plastových oken přeřízli u okálu tři nosné trámy, aby pak složitě vymýšleli překlad, protože hrozilo, že se jim celý okál zhroutí na hlavu. Holt, okál viděli poprvé v životě).

Michal Zahradnicek

+1

Myslim, ze toto je velmi dobre obrazne vyjadrenie urovne programatorov…

uf

Ted jsou programatori, ktere nezajima problemova domena. Reknete mi, co to ma delat, ja to udelam a rychle pryc a zapomenu. To za nasich casu nebylo.

Tom5

Výborně. Napsat na toto téma celý hlavní článek jako úvahu? Gratuluji.

To by mne zajímalo, co si čtenýři z tohoto článku vzali.

Připomíná mi to Homera Simpsona, když se stal manažerem a ptal se svých lidí: „Pracujete?“ – „Ano.“ – „Hmmm… Tak pracujte víc.“

Konkrétně:
1. autor popisuje obecný problém jako problém specifické skupiny aniž by na to upozornil
2. míchá dohromady několik profesí: obchodník, programátor, projektant atd. (chyběla tam např. uklízečka – musí si umět uklidit, technik – vyřešit problém s HW atd.) bez vysvětlení
3. vzhledem k nedávnému článku „Jak vyhodit peníze za zbytečný web“ stejného autora bych čekal nějaké vysvětlení a oddělení. Takto ty názory nepůsobí konzistentně.
4. v článku chybí zcela řešení probíraného problému (pokud to tedy opravdu neměla být jen úvaha)

Asi bych to uzavřel parafrází: „Autor článku si jen s psaním vět nevystačí“

Lokutus

Přitom stačilo říci, že dnešní projekty jsou zhusta velmi obsáhlé, tedy mimo rámec schopností jednoho člověka, a proto je potřeba umět S.P.O.L.U.P.R­.A.C.O.V.A.T.

Ale jinak dobrý článek, jen IMO zbytečně tendenční, což, jak vidno, se odrazilo v diskusi. Také je trochu problém, že není jisté zacílení článku. Zda cílí jen na web vývojáře, anebo i na korporátní sféru, kde jsou podmínky zhusta odlišné. A další problém je v tom, že praxe se zhusta liší od teorie. Teoreticky máme kvalitní tým vývojářů, projekťáků, konzultantů a obchodníků, kteří spolupracují v okouzlujícím souladu. Faktem ale je, že každá firma (komerční subjekt), se snaží maximalizovat zisky při snaze minimalizovat náklady. A já sám se často setkávám se situací, kdy si zákazník raději vybere solitéra než firmu s hromadou diplomů a certifikátů na zdi, protože solitér prostě nepotřebuje pracovat v týmu na to, aby vytvořil analýzu bez zbytečných certifikovaných keců, s použitím nějakého frameworku naprgal aplikaci, vyfakturoval a často ještě zajistil podporu, a to za poloviční cenu, protože nemusí živit tým obchodníků, projektových manažerů a konzultantů. Jistě, každý programátor by měl být univerzál i co se týče komunikace se zákazníkem, ale týmová spolupráce není vždy nezbytná. Pořád ještě platí základní pravidlo investičních nákladů – kdo to udělá nejlépe z hlediska výnosů/nákladů, ted pokud možno zadarmo?

Adam Šnobl

Pěkný článek, díky za něj. Vzhledem k diskuzi, která se kolem něj rozproudila, se určitě jedná o zajímavé téma.

Mně osobně se článek líbí, a pokud odečtu určitou míru provokace, tak s jeho vyzněním souhlasím. Kromě toho bych rád upozornil na knihu, kterou jsem před časem četl a která se v podstatě celá věnuje stejnému tématu: http://knihy.cpress.cz/knihy/pocitacova-literatura/programovani/co-programatory-ve-skole-neuci-aneb-softwarove-inzenyrstvi-v-realne-praxi/

Břetislav Wajtr

Dobra knizka, muzu take doporucit… rekl bych, ze je ale spise vhodna az pro seniorske a vyssi pozice, ktere si v ni najdou vic nez absolventi. Protoze absolventi (jako kdysi ja) obsahu stejnak nebudou verit :)

Aleš Roubíček

Pochybuju, nebo nechci věřit, že ta kniha něco dá seniorovi.

tommy

Tak si ji prectete a budete valit oci

Aleš Roubíček

Knihu samozřejmě mám přečtenou, mám k ní nějaký postoj. Nejsem ale senior. :)

roman3

Tiez sa mi pacila tato knizka, ale nesedi mi jej moc dokonaly pohlad na vec aj dokonala kariera autora, ktora viedla k kto vie akej nedokonalej smrti v 42 rokoch. (Nechcem urazat, ale nieco ho k nedokonalemu koncu priviedlo.)

Cody

Skvěle napsáno! A musím říct, že se přesně s těmito problémy u programátorů velice často setkávám. A stejně tak i s tím, že tento fakt odmítají, protože „oni to přece nepotřebují“.

A dle reakcí je vidět, že to setrvává i tady.

Gratuluji Martine!

danaketh

…a nejen že to stále trvá ale dneska jsem ti přidal 3 body k charisma :) Když si vzpomenu co všechno jsem musel ještě nedávno řešit jako programátor… Kdyby to byl jeden případ, tak bych o článku asi pochyboval ale ono to bylo všude stejné. Programátor řešící například odpovědi klientům v případě nějakého bugu, to mi lezlo na nervy.

Teď už se naštěstí stará kolega a já se můžu věnovat hlavně programování.

ondra.novacisko.cz

Na to snad má být helpdesk, nebo techsupport ne?

danaketh

Jo, má. Ale kupodivu i velká firma je schopná to provozovat stylem „helpdesk/techsup­port“ se zeptá vývojářů co mají odpovědět :)

ondra.novacisko.cz

Proti tomu žádná. Ale funguje jako schopná firewall (pro ty, co volají na helpdesk aniž by RTFM případně RTFFAQ a taky jako proxy cache. Tedy na opakované dotazy odpovídá sám helpdesk a už neotravuje vývojáře.

danaketh

Což o to, já bych proti tomu neměl – člověk si alespoň na chvíli odpočine od kódu a je lepší se zeptat než klientovi tlačit nějaké nesmysly z příručky „How to confuse a client in few easy steps“. Ale když pak chytnete na helpdesku někoho, kdo místo copy/paste, úpravy a odeslání prostě vaši odpověď rovnou přepošle…

Klient získá email který nemá a ve finále se může dozvědět i jiné věci které nemá znát :) Nebudu jmenovat firmu ale je to nadnárodní korporace a přesto tam nic nefunguje a pravá ruka neví, co dělá levá :)

kert

…vystihuje tento citát:
„Pokud se s vaším géniem snoubí zároveň talent s nikým nevyjít, jste pro moderní vývoj téměř nepoužitelní.
Je to možná smutné, mnozí (včetně mne – pozn.aut.) to považují za konec romantických a báječných časů velkých hrdinských skutků, ale taková je realita.“
Ano, díky za článek i za autorovu schopnost sebereflexe :-)
Soft skills dnes musí mít každý, kdo jenom racionalizuje a kategorizuje, stává se – dříve či později – nepříjemným. To platí imho pro osvč i pro pracanty ve velkých firmách (od seniorských pozic výše).

Honza Skýpala

Výborný článek, který bych doplnil následující obecnou úvahou, platnou nejen pro IT a programování (i když tam jakoby překvapivě), ale naprosto pro vše: Dnes již prakticky vůbec nezáleží na hard skills (v našem případě programování), protože ty se dají snadno doučit. Mnohem důležitější jsou soft skills, jak se uvádí v článku, jedná se o schopnost vyjít s lidmi, přizpůsobit se standardnímu procesu, organizace (své vlastní) práce, tzv. self micro-management, a taky vůle učit se novým věcem. Soft skills jsou dané mnohem více geneticky a typem člověka a je podstatně obtížnější je změnit, hard skills lze oproti nim relativně snadno nabýt. Je dobré si právě toto uvědomit při vybírání si kolegů (na jakékoliv úrovni, od najímání lidí do firmy až po požadavek na zapojení spolupracovníků do týmu pro určitý konkrétní projekt).

pas2007

Neřekl bych, že soft skills jsou dané geneticky a hard skills se dají snadno nabýt. Přesvědčivě může klidně znít i opačný názor – programování je kreativní činnost a jako taková je podmíněna talentem. Naopak řízení projektu, lidí, času… to je jen o dodržování nějaké metodiky, trpělivosti, pracovitosti, houževnatosti. Pravda bude jako obvykle někde uprostřed, obojí je trochu hard a trochu soft.

Honza Skýpala

Programování a kreativní práce? Tu skutečně kreativní práci dnes odvádí software architect. Dnešní programátor má v oblasti kreativity mnohem blíže malíři pokojů než Picasovi.

JS

Nic ve zlem, ale pokud to tak delate, delate to spatne. Na automatickou praci mame stroje. Zamestnavat tim lidi je mrhani talentem.

uf

Programovani muze byt kreativni, pokud musite zvolit z nekolika zpusobu, jak problem vyresit.

Programovani i analyza jsou uz spise inzenyrske discipliny. Ale na kreativite to neubira.

Inkvizitor

Každý člověk přistupuje k věcem jinak. Až budu potřebovat operaci, mnohem raději se svěřím zkušenému a zručnému chirurgovi, který má problémy s komunikací, než frikulínovi s mokrým diplomem z VOŠ ekonomicko-medicínské. Kdybych hledal jaderného fyzika, zachoval bych se podobně.

Dělal jsem u nás ve firmě pohovory s X lidmi. kteří se ucházeli o místo programátora. Někteří měli „soft skills“ na rozdávání, ale práci nedostali, protože

a) nedokázali vyřešit jednoduchý programátorský problém
b) neměli vůbec povědomí o základních možných problémech v cizím kódu
c) ikdyž jsem jim řešení přinesl přímo pod nos, nebyli schopní ani dokončit větu. Leckterý student střední školy by odpověď vypálil okamžitě.

A to byli lidé, kteří měli o danou práci zájem. Nebavím se o lidech, kteří se nemohou rozhodnout, jestli chtějí dělat grafika, učitele na hudební škole, programátora, nebo šéfkuchaře.

Takže ano – pokud je člověk inteligentní a flexibilní, dokáže se naučit prakticky cokoliv. Spousta lidí se „soft skills“ podle mého názoru ale prostě nemá schopnosti vhodné pro práci v technickém oboru. To se samozřejmě ve velkých firmách na některých pozicích ztratí, ale pokud takové schopnosti nejsou třeba, tento člověk podle mě prostě NENÍ vývojář. Je mi líto, nesouhlasím.

František Kučera

„Dobrý vývojář musí totiž znát (kromě programování) spoustu věcí“

Mít širší rozhled, nemít klapky na očích, nevidět jen ty svoje proměnné, bajty a nízkoúrovňové metody… je samozřejmě správné. ALE: ne neznamená to, že by programátor měl všechny ty věci kolem dělat (byť rozumět by jim měl).

Tady jsou totiž dva protichůdné faktory:

  • Týmová práce zdržuje – e-mailování, telefonování, IM, schůzky, to všechno bere čas. Vysvětlit, co chci udělat, ostatním* zabere často víc času než kdyby si to měl člověk udělat sám. K tomu se přičítají ještě případné osobní antipatie, byrokratické procesy (kdy schvalovací proces trvá několikanásobně déle než vlastní činnost – a stejně to většinu času někomu jen leží na stole nebo ve schránce). Z tohoto pohledu je ideální renesanční člověk, všeuměl, který zvládne projekt od začátku do konce a nemusí se s nikým rozčilovat.
  • Příliš mnoho činností člověka rozptyluje, „multitasking“ má velkou režii, člověk se nemůže soustředit na to, co umí nejlépe a řeší administrační věci kolem. Proto máme specializaci (které vděčíme za ekonomický růst a díky které nežijeme v jeskyních). Každý dělá to, co umí nejlépe, pak efektivně využíváme zdroje (lidi). Není dobré když vysoce kvalifikovaný zdroj (programátor) dělá věci, které může zastat sekretářka nebo nějaký brigádník, který se stará o síť, myši a tiskárny.

Než doputuje informace od zákazníka/uživatele k programátorovi, je to taková tichá pošta, na každém komunikačním rozhraní (zákazník/analytik, analytik/vývojář atd.) dochází k šumům a nedorozuměním – a také k časovým zpožděním, než se dohodne několik schůzek. Ovšem když má vývojář vstávat od rozdělané práce a sbírat požadavky od zákazníků, to je taky otrava a žrout drahocenného času. Ideálně by měl mít každý vývojář (nebo skupina vývojářů) sekretářku (někdy tuhle roli zastává projekťák), který zařídí všechno kolem a vývojář se pak může soustředit na svoji práci a výjimečně důležité schůzky, kde se řeší zásadní věci. A nemusí zabít třeba půl dne vyjednáváním o tom, aby mu síťaři povolili nějaký port na firewallu nebo popohánět jiné kolegy, aby dodali ikony nebo překlady, které měly být hotové už dávno.

Univerzální závěr z toho udělat nejde, záleží čemu dáme větší váhu, co nás víc trápí. Trochu se obávám, že budeme vždy nespokojení – každý chce to, co nemá (jako s manželstvím :-). Když budu mít problémy s analytiky a dalšími kolegy, budu se vztekat a říkat, že bych si radši všechno udělal sám a po svém. Když budu na všechno sám, budu naštvaný na to, že musím trávit čas s těmi pitomými zákazníky a vysvětlovat jim banality, což může dělat obchodník s analytikem, a já bych se mohl soustředit na programování (což nikdo jiný dělat nemůže). Prostě život je boj a trefit to optimum není vůbec jen tak.

„Samosebou, každý má možnost říct: Já jsem přeci PROGRAMÁTOR, tyhle věci za mne má řešit někdo jiný, já jsem od toho, abych programoval… Ano, ale takový ‚programátor‘ je něco jako dělník u pásu – ráno přijde do práce, osm hodin dělá to, co má v pracovní návodce, a pak jde domů.“

S tím si dovolím nesouhlasit – šéf směny v montovně si klidně může stoupnout k pásu a montovat, mistr na stavbě nebo v dílně může vzít rozdělanou práci po učňovi a dodělat ji (dokonce často lépe než on). Ale dokáže si manažer (nebo projekťák, obchodník, analytik, tester…) stáhnout zdrojáky aplikace a pokračovat v práci programátora, který odešel? Někdy ano, zažil jsem takové dva (nebo spíš jeden a půl), ale většinou to v IT neplatí a manažeři umí řídit a všechno kolem, ale programovat neumí (v lepším případě už to zapomněli, v horším to nikdy neuměli). To je v pořádku – každý má nějakou specializaci, ale není to vztah jako na té stavbě nebo v dílně či montovně u pásu.

*) ať už to jsou podřízení nebo někdo další v řetězci (např. analytik → vývojář → tester), nebo kolegové z jiných odděleních (síťaři, po kterých něco chci).

Honza Skýpala

Drzá poznámka: pokud mi trvá déle vysvětlit někomu, co chi, než si to udělat sám, pak je to moje chyba, neumím vysvětlovat.

František Kučera
  1. Na komunikaci musí být vždy dva.
  2. Ne vždy je to o tom, že by ten druhý (nebo první) byl hloupější a špatně chápal (vysvětloval). Dobře vidět je to třeba na testování – vývojář už do problematiky zasvěcený je, ví, jaký je smysl programu, ví, jak se má chovat… ale tuhle znalost je potřeba předat* testerovi a až potom může testovat. Kdyby testování prováděl přímo vývojář, tak odpadne nutnost ty znalosti externalizovat a vložit je do hlavy jiného člověka, otestováno by pak bylo během chvilky. (Ovšem v tomhle případě je nepřijatelné, aby celou práci dělal jeden člověk, protože je potřeba, aby kontrolu prováděl někdo jiný než vlastní práci.)

Podobné je to se sběrem požadavků – potřeby zákazníka musí pochopit** nejdřív analytik a pak je musí nějak předat vývojáři – tzn. nějak explicitně je formulovat, převést z myšlenek ve své hlavně na papír nebo aspoň na mluven slova. A vývojář tohle zase musí dostat do svojí hlavy, pochopit. Na druhou stranu analýza nespočívá jen v předání požadavků 1:1*** a není dobré plýtvat časem programátora na to, co může dělat analytik (a vice versa).

*) je celkem jedno, zda to dělá vývojář, nebo analytik, nebo si to sám tester čte z analýzy/zadání. Dostat ty znalosti do hlavy dalšího člověka (testera) stojí čas v každém případě.

**) nebo lépe řečeno je z něj vydolovat

***) byť to tak někdy bývá

Aleš Roubíček

V článku je pěkně odděleno Programátor vs. Vývojář.

František Kučera

To je, přiznejme si, tak trochu hraní se slovíčky. Jistě, můžeme si říkat honosněji „vývojář“ místo „programátor“ nebo „kodér“, ale v principu je to totéž – člověk, který vytváří programy, píše zdrojový kód. Sice se o někom říká „to je jen kodér“ nebo „to je pan Vývojář“, ale je to vlastně jen nějaké citové zabarvení, které té větě chceme dát – práce je to stejná – jen někdo je zkušenější, druhý méně zkušený, někdo šikovnější, druhý méně šikovný. Profesi mají stejnou, znalosti a odborné kvality různé (ale to ještě není důvod je kastovat na dvě skupiny). Vyšší/jinou kategorií je až SW architekt nebo třeba programátor-analytik, který může dělat jak programování, tak analýzu, v podstatě člověk, který má dvě profese.

A pak jde ještě slovo vývojář chápat jako „člen vývojového týmu“ tzn. včetně testerů, analytiků, projekťáků atd.  – prostě ta část ajťáků, která se nezabývá provozem, ale vývojem nového.

ondra.novacisko.cz

K té tiché poště, nemáte úplně pravdu. Cílem není přeformulovávat požadavky zákazníků, ale filtrovat je. Tedy pokud se ke mě jako k programátorovi dostane požadavek od uživatele / zákazníka, zpravidla mám k dispozici veškerý záznam komunikace s helpdeskem, takže tam vidím, co říkal zákazník, jaké kroky zkusil helpdesk, co k tomu dopsal senior, a podobně. Mohu přímo formulovat formulovat dodatečný dotazy, či případně zjistit, na čí straně byla chyba (ne vždy se helpdesk zeptá správně, a kolikrát častěji „školíme“ lidi na helpdesku, než opravujeme chyby uživatelů :-)

Jistě, viz „analýza nespočívá jen v předání požadavků 1:1“. K filtrování, prioritizaci, upřesňování atd. samozřejmě dochází, ale zároveň tu s každým krokem je i ten efekt „tiché pošty“, kdy se část informace ztrácí, nebo se odchyluje od původního významu. Což může být mimochodem dobře i špatně – Jednak analytik může objevit i ty potřeby zákazníka, které sám zákazník nedokáže formulovat (a vývojář by je z něj nedostal). A jednak každý vidíme věci trochu jinak, stejná slova chápeme trochu jinak, máme jiné výchozí znalosti, někdy i jinou logiku… a význam sdělení se posouvá. Podobně to funguje i vertikálně – v organizační struktuře – např. než doputuje nějaké opatření od ministra až k úředníkovi na přepážce… :-)

Michal Augustýn

Trochu se obávám, že budeme vždy nespokojení…

Já bych se toho nebál – vždyť nespokojenost je to, co nás žene dál ;-)

Avatar

Môj názor je taký, že článok veľmi dobre vystihuje realitu. Som momentálne vo fáze prijímacích pohovorov a to čo ste písali v článku, sa veľmi zhoduje s tým, čo personalisti, prípadne projektoví manažéri od uchádzača žiadajú – hybrida medzi programátorom a konzultantom. To, že programátor už dnes nemusí byť binárny génius je dôsledok štandardizovania postupov, aspoň teda v JEE svete určite. Na druhej strane to zdôrazňuje význam programátora, ktorý nie je (a podľa mňa nikdy ani nebol) kódiacou opicou, ale častokrát je človekom, ktorý o danom projekte vie najviac. Presun ku konzultantskej a konfiguračnej činnosti je viacmenej nevyhnutný, pretože ak akurát nepracujete na nejakej novej super duper aplikácii pre Android, tak robíte maintaining vecí, ktoré sú už nasadené, prípadne rozširujete. Good Luck.

František Kučera

Což je mimochodem děsná nuda a taky na člověka neustále vypadávají kostlivci ze skříní, které tam nechal tým před ním… ale někdo to dělat musí, no.

stej

Ještě pro doplnění: The Non-Programming Programmer. Anebo někdo řeší to a jiný zase tohle :)

Jiří Řezníček Jr.

Jako ze života vystřiženo.

estonto

Podobně jako spousta jiných vývojářů zde pracuji v softwarové firmě s ročním obratem v desítkách miliónů korun. Na obchodní myšlení máme obchodníky, na organizaci práce máme project managery a na programování programátory. Samozřejmě všichni tito lidé musí být schopni nějaké té týmové práce, ale to nepovažuji za žádnou výjimečnou a vzácnou schopnost. Za těch téměř pět let, co ve firmě pracuji, se našel pouze jediný „autista“, který nebyl týmové práce schopen, a tak byl po několika měsících propuštěn.

Při přijímacích řízeních, kde posuzuji uchazeče na místa programátorů, kladu důraz především na schopnost programátorsky myslet a na zvládnutí dané technologie, zatímco „měkké dovednosti“ mohou hrát roli jen tehdy, když zcela absentují.

Žádná revoluce se nekoná, dobrý programátor je prostě ten, kdo umí dobře programovat :)

Jean

„kladu důraz především na schopnost programátorsky myslet a na zvládnutí dané technologie“

Hmm, bohuzel jsem videl vysledky podobnych programatoru v podobne firme, jako bude zrejme i ta vase (pozor, usuzuji pouze podle vasich minimalnich naroku u prijimacich pohovoru). Vysledek byl po par letech tento:

„““A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.


Such code can become a personal fiefdom, since the author care barely understand it anymore, and no one else can come close. Once simple repairs become all day affairs, as the code turns to mud. It becomes increasingly difficult for management to tell how long such repairs ought to take. Simple objectives turn into trench warfare. Everyone becomes resigned to a turgid pace. Some even come to prefer it, hiding in their cozy foxholes, and making their two line-per-day repairs.
„““
http://www.laputan.org/mud/mud.html#BigBallOfMud

Na Internetu se vali spousta clanku o tom, jak spravne delat prijimaci pohovory, od lidi, kteri je delaji desitky let. Muj oblibeny: http://www.martinfowler.com/bliki/PreferDesignSkills.html

Joey

„Na Internetu se vali spousta clanku o tom, jak spravne delat prijimaci pohovory, od lidi, kteri je delaji desitky let. Muj oblibeny…“

IMHO je to jen jiný pohled na věc a nelze říct, že by jeden z nich byl špatný. Martin Fowler sice hezky popisuje, jak si vybírá spolupracovníky, aby nebyli přeborníky jen na vymezenou oblast, ale spíš všestraně užiteční, až bude společnost přecházet na jinou vývojovou platformu. S tím se dá ale s úspěchem polemizovat. Proč bych nabíral skvělého „vymýšleče“ do týmu, když ty, co to navrhnou a vymyslím mám a prostě potřebuju člověka, který umí platformu a bude kódovat a navrhovat relevantní úpravy, protože zná výborně danou oblast? Taky v kolika firmách se přechází na jinou platformu tak často, aby se jim nevyplatilo si své lidi vyškolit (z Delphi do .NET/Java, z jedné databáze na jinou apod.)?

Jean

– „Martin Fowler sice hezky popisuje, jak si vybírá spolupracovníky, aby nebyli přeborníky jen na vymezenou oblast, ale spíš všestraně užiteční, až bude společnost přecházet na jinou vývojovou platformu. S tím se dá ale s úspěchem polemizovat.“

V tomto clanku bohuzel nic podobneho nevidim. Vidim tam tvrzeni, ze jsou tito lide pro zakaznika/firmu vyhodnejsi.
Doporucuju k prostudovani nejake dalsi clanky na podobne tema od MF:

http://martinfowler.com/bliki/CheaperTalentHypothesis.html – „““Its really difficult to drive this point to old school companies who think a army of cheap programmers is a bargain than small teams of really talented people. No wonder why there is so much inefficiency all around.“““

http://martinfowler.com/bliki/CannotMeasureProductivity.html
http://martinfowler.com/bliki/TechnicalDebt.html

Pripadne nejake clanky od Joela: http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html

A hlavne neco o metodologii, protoze se mi zda, ze tu propagujete „Monumental“:
http://martinfowler.com/articles/newMethodology.html
„From Nothing, to Monumental, to Agile“, tzn. ze jste rekneme 10 az 20 let pozadu za opravdu uspesnyma firmama jako jsou Microsoft, Apple, Google a dalsi:

„“““
Before Google, companies in Silicon Valley already knew it was important to have the best hackers. So they claimed, at least. But Google pushed this idea further than anyone had before. Their hypothesis seems to have been that, in the initial stages at least, all you need is good hackers: if you hire all the smartest people and put them to work on a problem where their success can be measured, you win. All the other stuff—which includes all the stuff that business schools think business consists of—you can figure out along the way. The results won’t be perfect, but they’ll be optimal. If this was their hypothesis, it’s now been verified experimentally.
„“““
http://www.paulgraham.com/5founders.html

Vezmu-li v uvahu, ze dobry programator je hlavne dobry optimalizator (coz vychazi z jeho nezbytne lenosti: Why Good Programmers Are Lazy and Dumb – http://blogoscoped.com/archive/2005-08-24-n14.html), tak jestlize ma programator moznost zoptimalizovat procesy, bude z toho Agile a nikoli Monumental. Tzn. Google a ne „Velka Enterprise Nekompetentni Firma“ s programatory v Indii nebo Cine.

– „Proč bych nabíral skvělého „vymýšleče“ do týmu, když ty, co to navrhnou a vymyslím mám a prostě potřebuju člověka, který umí platformu a bude kódovat a navrhovat relevantní úpravy, protože zná výborně danou oblast?“

Protoze http://martinfowler.com/articles/newMethodology.html#PlugCompatibleProgrammingUnits ? :

„“““
Plug Compatible Programming Units

One of the aims of traditional methodologies is to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren’t so important, only the roles are important. That way if you plan a project it doesn’t matter which analyst and which testers you get, just that you know how many you have so you know how the number of resources affects your plan.

But this raises a key question: are the people involved in software development replaceable parts? One of the key features of agile methods is that they reject this assumption.

Perhaps the most explicit rejection of people as resources is Alistair Cockburn. In his paper Characterizing People as Non-Linear, First-Order Components in Software Development, he makes the point that predictable processes require components that behave in a predictable way. However people are not predictable components. Furthermore his studies of software projects have led him to conclude the people are the most important factor in software development.

In the title, [of his article] I refer to people as „components“. That is how people are treated in the process / methodology design literature. The mistake in this approach is that „people“ are highly variable and non-linear, with unique success and failure modes. Those factors are first-order, not negligible factors. Failure of process and methodology designers to account for them contributes to the sorts of unplanned project trajectories we so often see.

— [Cockburn non-linear]

One wonders if not the nature of software development works against us here. When we’re programming a computer, we control an inherently predictable device. Since we’re in this business because we are good at doing that, we are ideally suited to messing up when faced with human beings.

Although Cockburn is the most explicit in his people-centric view of software development, the notion of people first is a common theme with many thinkers in software. The problem, too often, is that methodology has been opposed to the notion of people as the first-order factor in project success.

This creates a strong positive feedback effect. If you expect all your developers to be plug compatible programming units, you don’t try to treat them as individuals. This lowers morale (and productivity). The good people look for a better place to be, and you end up with what you desire: plug compatible programming units.

Deciding that people come first is a big decision, one that requires a lot of determination to push through. The notion of people as resources is deeply ingrained in business thinking, its roots going back to the impact of Frederick Taylor’s Scientific Management approach. In running a factory, this Taylorist approach may make sense. But for the highly creative and professional work, which I believe software development to be, this does not hold. (And in fact modern manufacturing is also moving away from the Taylorist model.)
„““

Joey

„V tomto clanku bohuzel nic podobneho nevidim. Vidim tam tvrzeni, ze jsou tito lide pro zakaznika/firmu vyhodnejsi.“

Myslím, že není nutné slovíčkařit. Vzhledem k odkazům a pojmenování situace („…protoze se mi zda, ze tu propagujete „Monumental“…“) se mi zdá, že si rozumíme, co jsem chtěl říct. Taky bych rád podotknul, že i když jsem to nezmínil (neboť jsem to nepokládal za důležité), tak jsem svou reakcí chtěl hrát spíše ďáblova advokáta než prezentovat svůj názor (který se spíše blíží tomu, co se popisuje v odkazovaných článcích, byť si nemyslím, že z toho lze vždy uplatnit vše). A když jsem pak pročítal všechny ty odkazy, byl jsem velmi rád, že jsem vůbec toho advokáta zahrál. Texty jsou opravdu zajímavé a díky za ně. K přečtení je mohu jen doporučit.

Zkusím se ale ještě vrátit a pokusím se nahlédnout do české reality – myslím, že na poli IT se tu objevují v podstatě jen firmy, které:

1. jsou podobočkou / dceřinkou zahraniční korporace a pracují buď nějaké velmi vymezené oblasti (typicky „banda kodérů“) nebo customizují a udržují jinde napsaný kód („banda konfigurátorů“).

2. fungují jako námezdní síla pro krátkodobý vývoj či outsourcing (továrna na kód).

3. postavily svou existenci na jedné aplikaci (např. informačním systému), kterou postupně obalují dalšími featurami / moduly, a pokud to bude možné, tak ji budou vyvíjet až do skonání světa.

4. stojí na jediné osobě analytik-vývojář-tester-konzultant v jedné osobě – tj. one-man show firmy / živnostníci.

Ani u jedné kategorie (možná s vyjímkou dostatečně osvícených firem z třetí skupiny) si nejsem jistý, že by dokázala využít schopnosti nového Paula Buchheita a změnit například osvědčenou (tj. tu zrovna zavedenou) metodologii vývoje.

U tohoto mě napadá – existují i u nás nějaké společnosti, které by opravdu dělaly vývoj „jinak“. Sice se toho už hodně změnilo a spousta vývojářů zná klíčová slova jako je agilní programování, unit testy apod. (dokonce se o tom i učí děti na školách), ale existuje „český“ ThoughtWorks?

František Kučera

Do které skupiny bys zařadil firmy jako Unicorn nebo Logos (v době, kdy ještě byl Logosem)?

Joey

Nevim proc bych mel hodnotit „Logos, kdyz byl jeste Logosem“ – zkuste jej ohodnotit vy. Pokud firmu znate nejak lepe, urcite se vam povede ji nejak priblizit nam, co je znaji maximalne podle jmena.

Presto si ale zkusim tipnout. Jelikoz je pred dvema lety koupil Ness, bude z nej nejspise primovni „tovarna na kod“ a „my vam to zautsourcujem – bude to levnejsi“ – cili sehnat „projekt“, nejak nabouchat, vyfakturovat, dalsi upravy solidne nadsadit, aby jich moc nechteli a casem pripadne dotlacit k novemu projektu, kteremu budeme rikat upgrade ci modernizace a bude se to delat v podstate od nuly.

S Unicorn jsem prisel do styku jen pred osmi lety, kdy jsem shanel jako student bez valne praxe nejakou praci. Nebyl jsem z firmy nadseny, takze jsem nakonec radeji skoncil u male ceske spolecnosti, kde mi prislo, ze jsou otevrenejsi k napadum a zmenam. Unicorn mi z popisu nekolika mych kolegu, kteri ve spolecnosti pracovalo pripadal (pred temi nekolika lety) jako typicka „tovarna na kod“. Je mozne, ze se vsak mnohe zmenilo a ze opravdu uz „delaji software jinak“. Ja jako skeptik to vidim jen na velmi povedeny marketing. Aktualne ale informace zevnitr nemam, mozna nam je tu nekdo prednese a budeme vedet vice. Budu rad, kdyz se budu mylit.

truhla

Zajímavý (a záslužný) pokus o typologizaci českých firem, leč uvedená typologie rozhodně není úplná. Např. http://www.definity.cz/cz/sekce/o+spolecnosti/ nelze zařadit do ani jedné z kategorií, dokonce se žádné z kategorií ani nepřibližuje.

Joey

Tak nam ji popis – co a jak se u nich dela. Uz treba jen ten vstupenkovy system by mohl byt zajimavy a je otazkou proc jej neprodavaji jinam ale je udelan jen pro TicketArt?

Proc vlastne u nas nevznika software, ktery by se pokusil konkurovat v Evrope ci ve svete? Existuje prece tolik oblasti, kde je znalost ceskeho prostredi mozne snadno generalizovat (tj. ne treba ucetnicky program, ale ten system na prodej vstupenek snad ano).

Proc kdyz uz vznikne neco zajimaveho, tak s tim autori radeji jdou pryc nez aby se toho nejaka ceska sw firma chopila a rozjela ten spravny byznys? Napr. Stankuv NetBeans, ktery skoncil u Sunu (malou naplasti muze byt to, ze Sun vyvoj nynni snad dela ve sve ceske pobocce).

petiar

Vďaka za príjemné počítanie.

Mirek

No nevím, věta v úvodu „Pojďme se společně podívat, jaké základní schopnosti jsou nutné k tomu, aby se z tuctového „ťukače kódu“ stal Vývojář. “ mne navnadila, ale nakonec jsem byl zklamán, protože jsem se dozvěděl jen obecně známé skutečnosti, nebo spíš jen část obecně známých skutečností.

Ale pak jsem si pořádně přečetl předchozí větu „Programátor, který umí jen přepisovat algoritmy do programovacího jazyka, dnes ztrácí aureolu vysoce kvalifikovaného odborníka, a jeho cena na pracovním trhu neklesá, ale přímo padá.“ a byl jsem doma.

Ano, „autisté“ se na trhu moc neuplatní :o)

backup

tak bych nad tim mavnul rukou, ale bohuzel se to prenasi do praxe a my v softwarovych tymech, kde musime skutecne pracovat, s temi nesmysly pak zapolime a stoji to silene energie, nez se to mladym absolventum podari vymlatit z hlavy.

Samozrejme, ze to chapu, mlady clovek vyrustal jeste v rodine, ktera za komunismu nepouzivala mozek a kriticke mysleni bylo jen na zavadu. A takovy mlady clovek pak prijde na vysokou skolu, kde mu nekdo, komu jeste tece mliko po brade vyklada, jak je to s temi projekty. A dovi se, ze existuji soft-skills a ze je treba byt tymovy hrac. A mlady clovek, naucen slepe verit autorite si to zapise za usi a take to pri kazde vhodne prilezitosti vyklada.

Ale, na druhou stranu, ja doufam, ze uz to do penze nak doklepu, a pak se z tech soft-skills treba poserte …

100% Lenin

Ale pane kolego, to jsou zcestné bludy a typická lenost nás ajťáků. :D
Často mystifikujeme okolí tím, že (například) řekneme – můžou za to komanči Tehdy nebylo kritického myšlení. Howgh.


Pokud se nad tím zamyslím, tak můj náhled na věc je ten, že kritické myšlení musí generovat střední a vyšší školství. Protože kritické myšlení je neodmyslitelným atributem zvláště technických oborů.

Jako příklad mohu použít „důkaz sporem“. Ten přeci jistou úroveň kritického myšlení vyžaduje. Důkaz sporem jsme používali již na střední škole. Vy ne?


Dále nechápu, co pořád máte s tím komunismem. Přeci do roku 1989 všechny výrobní prostředky (externality a veksláky nepropíráme) patřily státu. Stát řídila skupina zvoucí se KSČ a její představitelé. A právě tato skupina rozhodovala o tom co se s výrobními prostředky bude dít a nebo nebude. Téměř vše muselo být od těchto lidí posvěceno.
A rozhodně tedy mohu potvrdit, že nikdo z běžných občanů neměl onu možnost „vzít si vše podle svých potřeb“. Nebo vy o tom něco víte?
Tak kde je ten komunismus? Že vy si pletete pojmy s průjmy (památná to slova našeho prófy)?

Jako příklad mohu potvrdit ten fakt, že reálný socialismus nám mnohým pomohl k vyššímu stupni používání kritického myšlení tím způsobem, že generoval „nedostatek“. A my jsme se museli prát s „nedostatkem“. Umět nahradit něco něčím tak, aby vše fungovalo a nešli jsme sedět.
Dnes vídáme takový obraz, že noví kolegové nemají (mnohdy) tendenci něco řešit. Máme tu wikiny, máme tu různé jiné zdroje, to najdeme tam a tam.
Ale když pak hodnotíme ten bastl. Tak to je opravdu veselo. Prostě a jednoduše. Dnes si mnozí kolegové berou fragmenty z blízkého i vzdáleného okolí a ztracejí přehled o tom co tvoří, jak to tvoří a jak to vlastně funguje a má fungovat. Zahlceni v nadbytku informací nedokážou kriticky zhodnotit jejich potřebnost a podle toho i vypadá výsledek. Na rozdíl od jejich předchůdců totiž žijí v informačním nadbytku. Prakticky mohou brát cokoliv odevšad. Ale tento „IT komunisticko informační nadbytek“ jim zatemňuje mysl.

Osobně pak doporučuji, nejen vám, se vyhnout politizování technických oborů a třeba i tomu našemu programování.


S čím souhlasím, je to o těch mlíčňácích na vysokých školách – i když i zde mohu myslet na to, že každý může jednou začínat.


Zajsté mladý člověk (každý mladý člověk) nevěří slepě autoritám.
Myslím si, že autoritám věří pouze nekriticky myslící hlupák.

A takové do našeho týmu rozhodně nebereme.

backup

obcas se zamicha do prospevku trochu komunismu, aby to nebylo takove suche. Samozrejme vim, ze papouskovani autorit je doma i v jinych systemech. (kdyz tak posloucham nekdy me zahranicni kolegy z kapitalisticke ciziny).

Vase tvrzeni o _vhodnosti_ nedostatku jako motoru kritickeho mysleni nesdilim, znam kolegu, ktery ma rodinu v Alzirsku – to je takovy _narod opravaru_ , protoze vlastne nic neni a presto tito lide nemaji zadne kriticke mysleni.

Kritickemu mysleni by se naucili mladi lide na vysoke skole tehdy, kdyby jim profesor predlozil nekolik poslednich vyzkumiu a studii k problematice soft-skills a jejich praktickych vysledku v praxi a kdyby studenti s profesorem o tom diskutovali. Bohuzel skutecnost je takova, ze pan profesor vyklada studentum neco, co si pred par lety precetl v nejake zahranicni knizce.

unknown

„Myslím si, že autoritám věří pouze nekriticky myslící hlupák.“

Vazeny, motate v jedne vete paty pres devaty: Viru s myslenim a nedostatek kritickeho mysleni s hlouposti. To ze nekdo nemysli kriticky jeste neznamena ze nemysli vubec (ze je hloupy). Je vice zpusobu mysleni, kdyby bylo jen to kriticke, nemuselo by se tak nazyvat. To ze nekdo nekomu veri jeste automaticky neznamena, ze je hlupak. Pripadne se Vam popletl slovosled a chtel jste napsat: Autoritam nekriticky veri jen hlupak s cimz by se dalo i souhlasit.

100% Lenin

tak nějak.
Už jsem pár let out of republic a je to poznat na vyjadřování. Díky.

Jen bych dodal – že hodně záleží i na mentalitě a prostředí, kde človíček vyrůstá.
Ale jak jsem napsal výše, tak nějak to znám ve směru kapitalistického východu a mentalita je tu přeci jen trochu jiná. Historické podmínky taktéž a ty tradice a jazykové bariéry.
Rozhodně je tu velký nedostatek kvalitních analytiků, vývojářů, architektů a dalších (teď je na trhu spíše odpad!).
Dneska je to spíše jak sázka do loterie, někoho nabrat do party a nevědět co je za ním.
A hledejte ve městě s 10-i milióny obyvatel onu příslovečnou jehlu v kupce sena.

Takže, ještě jednou díky a zdarec všem diskutujícím.

Jirka Hradil

Jirka Hradil

drevolution

Několika diskutujícím se stále divím. Proč to berete tak, že valná většina lidí, která má ony soft-skills, neumí programovat? Článek byl přeci o tom, že máme dobrého programátora, který chce dál růst a dokázat více. Má na výběr. Buď se může ještě více věnovat oboru a studovat další technologie, nebo se bude věnovat zlepšení svého projevu, aby lépe prodal své vědomosti. Ano cesty jsou to odlišné, ale pořád víme, že ten náš programátor umí programovat, tak proč o tom někteří z vás pochybují?

backup

je mozno argumentovat 2 zpusoby:

– energeticky: den ma 24 hodin a nelze delat vsechno

– sociologicky: urcity typ osobnosti je predurcen k urcitemu stylu chovani a nemuze to sve _ja_ vymenovat jak trenyrky.

Viz prispevek ‚inkvizitor‘ o neco vyse.

ferren

clanek popisuje dnesni dobu a trendy,to jo,ale ne cestu k lepsimu.

z praxe, vidim trochu do zalezitosti kolem grafiky. velky tym,velka spolecnost,ISO na proces, to vse vede k spatnym produktum. nebo snad existuje nejaky velky kvalitni software? aspon jeden? neznam zadny. vsechny kvalitni nastroje, revolucni veci atd maji na svedomi tymy do 30 lidi s velmi plochou struktorou. tzv. DARPA model zalozeny na individualnich talentech.

ja uz moc neprogramuju,za­jimaji me uz jine veci, driv bylo programovani tvurci a naplnovalo me, ted se spis rozhlizim v kreativnejsim umeleckem svete. ale i tak, mozna to vyzni nabubrele,ale kdyz jednou za cas neco potrebuju,tak plati vyrok jednoho byvaleho kolegy „IBM na tomhle delalo rok. ok, ja to budu mit za 4 dny“
smutne je ze to je docela realisticky vyrok.

Tom5

To máte tak. Vysokoškolák vám taky objem primitivního tělesa začne počítat automaticky určitým integrálem.

Na druhou stranu jak známo se od určité velikosti a komplexnosti projektu viditelně zvyšuje režie. Ale to neznamená, že se přestanou takové projekty realizovat.

František Kučera

„IBM na tomhle delalo rok. ok, ja to budu mit za 4 dny“
smutne je ze to je docela realisticky vyrok.

Částečně to pravda je, protože velké firmy mají jinak nastavené procesy, důraz na kvalitu a vůbec všechno… ale z větší části je to spíš výrok generála po válce – když člověk vidí, k čemu došli, co naprogramovali, tak řekne, že by to zvládl mnohem rychleji – pravdu sice má (netrvalo by to 4 dny, ale pořád méně než původní vývoj), jenže on by nedělal vše od začátku, od by vlastně jen opsal výsledek – to je jako když soudruzi dovezou ze západu magnetofon, rozmontují ho a podle něj udělají vlastní – taky to zvládnou rychleji, protože nemuseli ztrácet čas výzkumem, analýzou… ale to neznamená, že jsou skutečně rychlejší nebo lepší.

100% Lenin

On ten výrok je všeobecně oblíbený. Dokonce mne napadla následující analogie se slavným Freudovým citátem.

„Ten, kdo z nás nevyslovil podobný výrok (o 4 dnech a IBM) alespoň jednou, ten není 100% prgoš!!!“

A ruku na srdce. Víte co je to za potěšení, když to nějakému tomu PM-ovi vmetete po roce do ..ichtu? 100%-ní.

:D
Jinak souhlas. Vše je o porozumění procesů a o individuálních schopnostech jedinců, kteří tvoří tým a nakonec i o těch co je vedou a řídí. A tak dál.
Ale, ale, ale.
Nějak jsem se zamotal – není to přeci jenom o krapínek složitější, než-li se nám všem zdá?
Asi ano.

Mirek

Hm, mám zkušenosti z konstruování letadel, aut, architektury, programování … a potvrzují mi to, co říkal už starej Tupolev (konstruktér slavnej túček – letadel): jeden člověk je schopen problém vyřešit v nějakém čase, dva lidé ten čas zkrátí, tři také, ale od čtyř nahopru už to stojí za starou belu. Podobně se vyjadřoval jeho „konkurent“ Kelly Johnson, šéfkonstruktér od Lockheedu (U2, BlackBird, StarFighter), že pokud je člověk talentovanej, tak obvykle rychle dospěje k použitelnému ba skvélému řešení a když to pak rozvrtává, obvykle to zkazí. … obé volně řečeno (nepamatuji si přesné znění výroků, ale smysl je snad stejný).
Mám zkušenost, že velké týmy, to je spousta času na vzájemnou komunikaci, slaďování a dlaší podobný nutnosti … přitom se rozmělňuje koncept, vytrácí se jiskra řešení a dílo se stává bezpohlavním mastodontem. Statisticky ve velkých týmech je převaha průměrných lidí, kteří nejsou schopní pochopit nápady několika málo talentovaných tahounů a jenom je pak rozhňaňají a pohřbí do průměrnosti. Bléé. Bohužel, gausova křivka vztažená na populaci je neúprosná. Jediné co pak funguje je to, že malý tým talentovaných rvůrců dotáhne nejprve věc do takové stavu, když to stačí dát jen rozkreslit a dočesat. Protože síla velkého množství průměrných lidí může být v tom, že dokážou odvést v krátkém čase obrovské množství rutinní práce. Kritické je ovšem samotné předání díla do rutinérského prostředí – nesmí tam být nejsanost a možnost uhnout od konceptu jinam.

Joey

Jinými slovy, co už tady odkázal kolega diskutující:
http://martinfowler.com/bliki/CheaperTalentHypothesis.html

100% Lenin

Pod to se podepíšu.

Máme x tisíc zaměstnanců, x desítek až stovek vývojářů a ani jeden z vývojářů neumí to co požadují naši intelektuálové (v článku).
Dáváme na tahouny a rutinní dodělávky. Ale rozhodně nemáme univerzály. Těmi jsou Projektoví Manažéři – a ti někdy stojí za to.
Pořád vidí jak to máme dělat, koordinují ty, kteří to nemají dělat a nedej Bůh jim šáhnout na jejich ego.
To je pak hustý.

Dobrý vývoj nestojí ani na těch, ani na oněch – ale na souhře všech.
Univerzální voják či sofistikovaný voják. Nic není jednoduché

Prostě to tak je a basta fidli.

Jean

> Máme x tisíc zaměstnanců, x desítek až stovek vývojářů a ani jeden z vývojářů neumí to co požadují naši intelektuálové (v článku).

Nemuzu uverit, ze ani jeden neumi nic z DRY, KISS, TDD, komunikativniho kodu, rychleho uceni ci spoluprace se specialisty. Dali jste jim prostor? Jestli ano, tak to mate jako firma fakt smulu na lidi. S nekolika takovymi (do deseti) jsem spolupracoval a zdaleka nemuzu rict, ze bych zblizka poznal stovky vyvojaru.

Jeste poznamka na okraj – ti „intelektualove“ jsou pragmatici. Tzn. vsechny postupy, ktere davaji do obehu si vyzkouseli, roky je optimalizovali a jeste porad je optimalizuji. Jsou to aktivni vyvojari a kdyz si prectete nejake knizky od MF, zjistite ze manazery a teoretiky zrovna dvakrat neuznavaji.

Pripadne muzete zkusit trenink (mam s tim dobre zkusenosti a da se provozovat paralelne pri programovani, jestlize je clovek ochotny pretrpet trochu multitaskingu): Software Training Sucks: Why We Need to Roll it Back 1,000 Years – http://www.softwarebyrob.com/2005/11/15/software-training-sucks-roll-it-back/ :

„““
Someone with a lot of experience and a little theory tends to write code that runs well but is difficult to maintain and extend. Since the point of software design (which relies heavily on theory) is to organize a complicated system into something extensible and easily-understood, a solution lacking in design tends to want in these two areas. The larger the system, the worse the problem becomes.
„““

Joey

Taky se mi nechce verit, ze pokud ma firma stovku vyvojaru, tak ze to jsou vsichni „jen koderi“ – lopaty. Na druhou stranu, chapu, ze takhle mohou zvenci vypadat. Byva to ale problem vlastni koncepce (jak probiha vyvoj daneho sw) a vedeni jednotlivych tymu nez to, ze by ti koderi nebyli dostatecne schopni.

LennyCZ

Naprosto správně.

Mluvíte mi z duše, jenom mně by trvalo 10 let než bych tu myšlenku vůbec formuloval a předal to k „rozmělnění“ :-)

Díky za povzbuzení.

Teď by mne ale zajímalo, jestli náhodou neexistuje fungující způsob (nebo aspoň berlička) jak v takovém týmu tuto tendenci změnit – rozeznat talent od průměru a vytvořit těmto lidem prostor doladit jejich dílo do správné podoby.

Mirek

Fungující řešení existuje. Je to prostě věc organizace práce a organizace týmu. Nevím, jak to popsat vyčerpávajícm způsobem, ale ona je vůbec otázka, jestli existuje nějaká univerzálně použitelná kuchařka. Nezbytně nutným předpokladem je pečlivá práce s lidmi např. ve spolupráci s personalisty. Personalisté ve firmě mají nejen z úkol nábor lidí z venku, ale též důležitou roli v tom, aby člověka umístili na místo, kam se v celém soukolí nejlépe hodí a všeobecně s ním pracovali aby mj. i našel sám sebe.

Další věc je hlava řešitelského týmu. Bertone, Pininfarina, Wernher von Braun, Koroljov, Johnson, Colin Chapman, Jakovlev, Burt Rutan, nebo u nás Ledvinka, Vlček, Beneš a Mráz, Rublič, Matějček jsou či byli nejen geniální technici a tvůrci, ale též organizátoři, politici. Měli opravdu komlexní kvalifikaci i charisma. Podle mé životní zkušenosti tvoří opravdu malou část populace. Ale to vůbec nevadí, protože se dokážou prosadit a shromáždit kolem sebe tým lidí a zorganiozovat si ho tak aby mohli za daných podmínek tvořit.

Ono být průměrný není žádná hanba. Je to normálnější být „průměrný“, protože průměrný znamená staticky obvyklý. Na mravenčí práci „průměrných“ lidí pak stojí vše. Navíc ani ve velké počtu velmi nadaných lidí není možné řešit koncepční otázky. Už jen proto, že nelze slovně komunikovat o věcech, které se musí cítit a předávat třeba jen tónem hlasu.

Mám zajímavou zkušenost: dělal jsem diplomku pod člověkem, který byl takovou geniální vůdčí osobností. Seděli jsem spolu a bavili se o tom, kde byl na dovolené a tak. Do toho jsme přeskakovali k vlatnímu tématu práce. Neřekl mi nic moc konkrétního, jen mi kladl občas otáku a po mé odpovědi říkal hm, nebo aha :o) S odstupem času jsem si uvědomil, že se ptal přesně na to, co bylo klíčové, co mne blokovalo, co potřebovalo usadit. Asi po dvou třech hodinách rozhovoru jsem měl najednou jasno a říkal jsem si, že jsem měl za ním zajít hned a netrápit si s tím nejřív měsíc hlavu. Tenkrát jsem totiž ještě nevěděl, že by to bez toho měsíce tápání bylo k ničemu. Že jsem se nejdřím musel pořádně zorientovat v problému, poznat a zacítit i jeho skrytá témata. Teprve pak mi mohla obrovská zkušenost vedoucího diplomky k něčemu být.

Není účelné, aby si takovou řeholí procházelo všech „sto“ lidí, kteří pak budou jen dělat detaily. Ti mají vlastní svět, vlastní řehole a vlastní témata, která se týkají ekonomiky, spádovosti, průchodnosti procesu výroby. Jedním z nich je například kázeň. Nesmí do díla vnášet vlastní koncepty ale opravdu jen implementovat požadovaný algoritmus a to vysoce spolehlivě a bez chyb. To je už sama o sobě velmi náročná práce – tedy se vším, co k ní patří.

Jean

U IBM to bude spis problem v tom, ze produkuji bloatware, stejne jako vetsina ostatnich enterprise firem. A zrovna IBM bych obecne s kvalitou dvakrat nespojoval ;) (u nich hrozne zalezi na tom, o jaky tym/produkt se konkretne jedna – ostatne jako ve vsech ostatnich firmach).

Barbar

„Znalost obchodu, organizace, komunikace, trhu či managementu…“ Pokud někdo bude opravdu dobře, kromě programování, ovládat i tyto disciplíny, tak je naprosto zbytečné, aby někde pracoval jako zaměstnanec!

Nejlepším řešením pro takového člověka je, založit si s.r.o. a pokud pro někoho pracovat tak ve stylu outsourcing, ale spíše prodávat produkty (ať už své vlastní nebo cizí :-)). Z vlastní zkušenosti můžu říct, že si tak ten člověk vydělá několikanásobně víc než jako zaměstnanec firmy vykonávající stejnou činnost…

Naopak, pokud budete umět i uvedené disciplíny, tak Vás jako zaměstnance budou chtít vyrazit jako prvního – protože Vaši nadřízení nesnesou, že tím, že si všechno vyřešíte sám a je nepotřebujete v podstatě ukazujete na jejich zbytečnost :-)

A nedej bože, aby jste trhu rozuměli natolik, že budete vidět různé „tunely“ lidí nad Váma nebo celé firmy – to už si rovnou běžte vyklidit stůl (pokud Vás k němu někdo z bezpečnostního pustí :-)) :-DDD

peter

Cista pravda.
Kamosovi sa to stalo v Accenture a to nebol ani moc sikovny a ani do toho vela nevidel. :)
Holt je to o kvalide ludi vo firme a firemnej kulture. Ked hlupost prenikne na veduce pozicie, niet cesty spat.

ooo

„Že je často problém sehnat programátora, který opravdu umí programovat a ne jen psát kód, je jiná věc, a je smutnou realitou, že u webového vývoje to platí dvojnásob“ … to je obraz soucasne situace na trhu, tudiz nevim proc by uchazec o praci MUSEL mit vyse popisovane schopnosti, kdyz vetsina firem bude rada i za to, kdyz najdou nekoho, kdo bude „pouze“ umet dobre programovat

memox

Samozrejme ze v projektoch ako su webove stranky inventarizacne software , bankove software a podobne . Netreba vyssie algoritmicke myslenie .
A samozrejme tito ludia ludia co robia tito „podruzne software“ si musia nieco vymysliet aby sa hrali na elitu .

Predsa ten titul ing nemaju len na to aby denne vyrabali nieco co inteligencou nepresahuje 1+1. Tak si vymyslaju legendy o vyvojaroch .

memox

Robi autor clanku v tejto oblasti :D ?

memox

Tam kde japonci, korejci a cinania riesia chodiacich robotov a riadenie auta pocitacom, riesi zapad dokola syndrom „vyvojar“ .

s

vsechny schopnosti, co se v clanku popisujou se ziskaji praxi. Autor objevil novy kontinent.

Jenda

Diky autorovi za vynikajici clanek. Mam na veci stejny nazor.

manualni zrucnik

Jsem zamestnancem proto, ze neumim vsechno, umim jen algoritmizovat pozadavky, hledat reseni a jeste nejakou tu lepsi usabilitu aplikaci, jakz takz design navrhnout. Pokud ode mne budete chtit delat obchodni plany, seru Vam na programovani, nebo se prezamestnam se jako lepe placeny manager jinde. Vedouci by porad chteli vic a vic aby clovek zvladal, ve skutecnosti ale je to jenom problem firmy, ze neumi tak jak je vydelavat, a protoze ma nadstav manazeru, nejsou ji schopni programatori uzivit a proto vymysli chujoviny, viz. clanek. Zdar ! „Programatorovi programovani a svini pomyje“!

MindTheGap

To máte pak ještě firmy, které si vymýšleji debilní evidenci každé půlhodiny práce, kterou vykonáte během dne.
Na pětiminutovou opravu, i přiblblého odkazu či tlačítka, kde jste zatížen jinou týmovou režií a komunikací s klientem, musíte navíc vykázat podrobný záznam o tom, co jste vlastně a komu dělal. To je zhruba stejně nebo vícenáročné, časově, debilní práce pro neabsolventy základní školy, potupa pro odborné zaměření člověka, který studoval, aby se drbal s pi*ovinama kvůli neschopným vedoucím.
Po deseti takových zásazích jste úplně v prdeli s energií a máte chuť se na to vy*rat.
Proč nemá tohle smysl je prosté: mnohokrát jsem schválně zavedl do záznamu hrubou chybu, které si nikdo nevšiml, a vyhodnocovací algoritmy už vůbec ne.
Jenom vedoucí týmu, jeho šéf a šéf šéfa si pořád myslí, že všechno jde spočítat.

kos

protože pracujete v heterogenním prostředí

Tomáš

Je pravda, ze vyvoj web aplikaci trosku pokulhava. A to hlavne proto, ze je to lehke pro zacatecniky. Staci jim znat v PHP echo a include, a uz muzou napsat prvni stranku. Postupne si nabaluji podminky, cykly apod. Bohuzel takovyto clovek si hned mysli, ze je programator. Pak k nam prijde na pohovor clovek co si mysli, ze programovat objektove znamena, pouzivat include (a takovychto odborniku nam na pohovor prijde X). :D

atom

Takže pokud bych měl článek shrnout, průměrný programátor v Javě by měl umět v základu asi tak toto, pokud nechce chcípnout hlady:

1) Znalosti základních algoritmů (HeapSort,QuickSort atd.), grafové algoritmy, asymptotické složitosti algoritmů, paralelní algoritmy (modelování na Qn, všesměrová vysílání atd.)
2) Znalosti HW (co jsou registry, jak funguje context switch, přístup do RAM, sběrnice atd.), znalosti assembleru pro x86 nebo aspoň nějaký Atmel, logické obvody AND, XOR, CMOS/TTL atd.
3) Algebra – konečná tělesa, cyklické kódy, asymetrické šifry (RSA…), komprese atd., booleova algebra
4) Základní programovací jazyky – Pascal, Smalltalk, php, Java, C/C++, C#, Perl, Ruby, Python, možná Scala
5) Znalosti vnitřností JVM – garbage collector (aspoň CMS, možná G1), využití JIT, převod do bytecode, limity classloaderů
7) Jazyky a překlady – LR/LL(k) gramatiky, syntaktický analyzátor, lexan, optimalizace
8) Databáze – Znalost SQL tak na úrovni SQL/2003, optimalizace, převod ER modelu na relační, NoSQL databáze, administrace Oracle, MySQL, MSSQL
9) UML – všechny typy diagramů, zkušenost s Rational Rose nebo EA
10) Test Driven vývoj, Ant+Maven, Agile devel (aspoň XP), SVN
11) J2EE/JEE, EJB3, SOA (aspoň SOAP+REST), BPEL, JSP+JSF, IceFaces, log4j, slf4j, Hibernate, Portlety, možná Spring a věci okolo; zkušenosti s Tomcatem a aspoň JBoss, GlassFish nebo WebLogic
12) Zkušenosti s eclipse, netbeans nebo idea
13) HTML – XHTML, ECMAscript, CSS level 2, AJAX, WebUnit a zkušenosti s FF a IE6–8
14) Administrace linuxu a windows, možná solaris; znalost bashe a cmd, cron, servicy, daemoni, zabezpečení linux + windows
15) Sítě – znalost OSI pozpátku i o půlnoci, konfigurace routerů (možná znalost IOS), DNS, TCP/IP, HTTP, HTTPS, RIP, ARP, RARP, BGP, RIP, OSPF a směrovácí algoritmy obecně, FTP, rozdíl SFTP/FTPS, SSH
16) Vlákna, mutexy v Javě; JNI
17) BPM, ITIL, PDL
18) XML a jeho infoset, DOM, XPath, XQuery, XSLT
19) Soft skills – schopnost sebeorganizování se, práce v týmu, vyjednávání se zákazníky, support, psaní dokumentace, vytváření prezentací, slušná rétorika, schopnost vcítění se do požadavků zákazníka a přenést to na papír

Tož není jednoduché se dnes uchytit jako programátor…

drevolution

Tohle se mi líbí :) Osobně takový nejsem, ale chtěl bych být.

Paia

Já jsem na to dojel. Já totiž vůbec nejsem programátor. Jo a taky umím jen česky a rozumím slovensky (ročník 1968 a antitalent na cizí jazyky).

6 roků jsem dělal správce sítě ve výrobním podniku v menším okresním městě. Šlo o 2 servery a cca 100 stolních PC a notebooků. Byli jsme taková odnož mateřské firmy vzdálené přes půl republiky. Staral jsem se o chod sítě, mailserveru, firewallu a udržoval v chodu počítače všemožnýho stáří, strojovej park se postupně obnovoval, takže jsem každou chvilku něco přeinstalovával, k tomu občasný rady BFUčkům.
Jak přicházela krize, firma se rozhodla k restrukturalizaci a že si sítě na pobočkách bude spravovat vzdáleně z centrály (a lidi z centrály budou pravidelně na pobočky dojíždět – jak úsporné, že?). Takže mi zrušili místo.

No a už jsem rok bez práce. V oboru nemůžu nic sehnat, na několika pohovorech na správce sítě jsem během roku byl, ale vždycky mě nevzali.
Nejhorší jsou právě přemrštěný poptávky po lidech. Firma zveřejní, že hledá správce sítě se znalostí windows a office a počítačovýho hardwaru, ale v dalších požadavcích je, že má umět programovat v php, javě, c++, znát sql, dále většinou požadujou ještě EN a DE (i když se jedná o ryze českou firmu), nedejbože manažerský schopnosti.

To si neuvědomujou, že někdo, kdo se šroubovákem pitvá bedýnky a vyměňuje součástky, tahá síťový kabely a kontroluje internetovej provoz, že takovej člověk se těžko bude věnovat nějakýmu programování??? A naopak – že kvalitní programátor se zase nezabývá hardwarem a funkčností serverů a sítě???

A protože jsem se celej život motal kolem počítačů a sítí, neumím ani nic jinýho, takže se nechytám ani jako nějakej skladník, po kterým chtějí zase 5 roků praxe ve skladu. Dokonce mě nevzali ani ke stroji, do kterýho bych strkal nějakej plastovej polotovar a vytahoval hotovej výlisek. Jen proto, že jsem nikdy ve výrobě nepracoval.

paso + ctyri jednicky zavinac seznam v cz

jj, neveselo truchlivo a bude hur – business se meni; zkuste pisnout zkama ste a co mate za skolu na muj mail vyse, nic neslibuji, takze klido jen zakladni info a anonymne – mail staci, muze se stat ze se nekde pobliz neco vyskytne…

Aminux

Sice je to OT, ale já dělám v BOSCHi a tam pracujou lidi různých profesí. Už jsme tam měli i řezníky, zedníky, kuchuře a to i na CNC lince! Takže si myslím, že by to šlo, jenže jak jste řekl, je krize a ani ten BOSCH moc nepřibírá. Občas na montáž, ale tam se moc lidem nechce.

Petr N

Muj prispevek je tochu OT, ale neda mi to. Tento clanek mi moc nesedi, predevsim z toho duvodu, protoze ma vest k tomu aby clovek umel X veci a ve finale nic poradne.
Ze sveho hlediska beru za neralne umet na profi urovni vice nez tri systemy, sitarinu (na logicke i fyzicke urovni) a k tomu navic HW, programovat v SQL, nekolik modulu SAPu , atd.

samboush

Programator jako zamestnanec, je jen kolecko ve velkym strojecku, a pokud dodrzuje tak nejak zasady pro programovani ve vice lidech, dal zalezi uz jen na vedoucim projektu jak to organizuje.
Tzn jeho postaveni, reputace zalezi jen na tom jak dokaze svoji praci obhajit u vedouciho/sefa nekoho nad nim.

Vyhody: pohodlna prace , pri prakticky nulovem riziku v dobe hojnosti i nehojnosti, jisty relativne slusny prijem, relativne dost casu na vlastni vyvoj, kdyz ma stesti muse se dostat i k necemu nakladnymu a zajimavymu. Normovane zadavana prace a ocekavatelna kontrola. Jde to v sandalech.

Nevyhody: pohodlnost, rutina, odtrzeni od reality, minimalni ovlivneni vlatni prosperity, nejhorsi moznost jak svuj potencial vycerpavat a prodavat

POZOR: je treba si budovat pozici v tymu(oblibenej si muze dovolit vic kixu), nema smysl makat vic nez ostatni, pokud neplanuji u zamestnavatele nejaky rust. Ale pozice sefprogramatora za to nestoji :). Nebezpeci podlehnuti syndromu poplacani po zadech!!! Nema smysl se morit nekde kde vam neni dobre.

Programator jako soukromnik/kon­traktor: takhle se to da delat na mnoho zpusobu. Od hodne dobre az po hodne blbe. Ale zakladni ukazatel je kc/hodina.Res­pective kolik casu mesicne clovek odpracuje a kolik za to dostane. Cim min casu tim lepe. Nezalezi ani tak na kvalite kodera(ale je to cesta jak se jim stat), ale spis na jeho umu praci si sehnat a nechat si ji poradne zaplatit.

Vyhody:nekolika nasobny prijem od zamestnance, volnost v planovani casu, v dobe hojnosti a optimalnim nastaveni opravdu zadne starosti. Lze investovat velkou cast vydelku do vlastniho vyvoje a je na nej i dost casu. Staci jeden vetsi klient a dvere se oteviraj automaticky. Nelze se uz vratit k funkci zamestnance.
Nevyhody:Nutnost navstevovat klienty a udrzovat pseudo pratelsky vztahy, v sandalich to nejde. v dobe krize jde prvni od valu, je treba az chorobne dodrzovat programatorsky protokol. Je treba brat ksefty hlavne podle pomeru prace/cena. Hodne administrace. Zadavani prace, jinej kraj jinej mrav. Platebni moralka nekterejch klientu. V krizi to muze byt i jednou za rok. Stresujici narazovky. Nelze se uz vratit k funkci zamestnance.
POZOR: nutnost brat zalohy, pokud je projekt delsi placene milestones nutnosti. Odevzdavat zdrojaky az po vyrovnani uctu. Idiot vas nestoji jen nervy , ale vetsinou i prachy. Nutnost dusledne dbat na vlastni reputaci. Pokud je clovek programatorsky prasatko jako, tak ho to nauci :)
!!!POZOR2!!!: je treba investovat a ulejvat si prachy na budoucnost na vlastni podnikani a dobu nehojnosti.

Programator jako soukromnik/ma­jitel/zamestna­vatel: Asi nejvetsi potencial v otazce zisku a jak zuzitkovat dosavadni portfolio dovednosti, konecna faze kariery programatora (podle mne), ale zaroven obrovske riziko.
Vyhody: uz je to jen a jen na Vas.
Nevyhody:Je to fakt boj na zivot a na smrt.Neni moc prostoru na spatny volby.

POZOR: dulezity je vybrat si fakt vec s potencialem financnim, idealni jsou do toho zacatku vlastni penize(max pulka toho co mate), pokud nestacej tak nejaky safe money(ne Banka), mecenas, investor, financne zajistenej partner/spolu­majitel projektu. Hlavne nenest riziko vetsi nez jste schopen dusevne , fyzicky a financne unest.

POZN: programovani je jen programovani dokud to je jen konicek. Jak uz se to stane praci uz je to primarne hure ci lepe uzavreny obchod. Cim drive to cloveku docvakne, tim ziska vetsi cast sebe sama co ma moznost prodat. :)

Zamerne nepisu o tom jak idealne programovat(a ani to nevim), na to existuje milion navodu a postupu a milion nazoru. Pro mne je dulezity abych se u toho citil pohodlne, stale mne to alespon trosku bavilo.
Co je dobrej programator nedokazu ohodnotit, ale v dnesnim svete zastavam nazor , ze to je ten co si tim nejvic vydela. A pokud je to jeden z vyvolenejch co je sto jeste vymyslet neco inovativniho, je to zas ten co to inovativni dokaze nejlepe prodat. Az bude svet fungovat jinak, zmenim treba i nazor. Ale ted to je co nejmene programovani zaco nejvice penez. Zbyde sil na neco poradnyho :)..

opis

Vystihnul jste to přesně

11) J2EE/JEE, EJB3, SOA (aspoň SOAP+REST), BPEL, JSP+JSF, IceFaces, log4j, slf4j, Hibernate, Portlety, možná Spring a věci okolo; zkušenosti s Tomcatem a aspoň JBoss, GlassFish nebo WebLogic
12) Zkušenosti s eclipse, netbeans nebo idea

Pokud budete pracovat s .NET tak potřebujete pouze ASP .NET + IIS

laik se zajmem

…nadcasovej clanek. I komentáre dobre. Dik

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.