.jpg)
2016. április 7., csütörtök
"Tegnap még nem tudtam programozni, de ma már tudok"
Beleszaladtam egy friss blogposztba, ahol a bloggazda Ördög Rafael (Lean Poker) alapítóval készített interjút a fenti címmel.
Kávé és karrier: Tegnap még nem tudtam programozni, de ma már tudok
Karriercoach , Karriercoach Blog , Karriercoach FB brandhez tartozóan.
Jó sok téma előkerült, külön-külön blogposztot érne a kifejtésük (azaz muszáj lesz durva léptékben tömörítenem). Van az elhangzottak között, amivel nagyon egyetértek és van amivel nagyon nem és vannak finomabb átmenetek is :)
Nézzük sorjában:
A perdöntő főmotívum: az interjú teljesíti hivatását/küldetését!
Merthogy ad egy(több) nagyon-nagyon jó tippet, a Greenfox Academy, a Junior programozó és Tech4Biz képzések említésével, linkjével (más linkek mellett). Ez óriási pozitívum az én szememben, hiszen ad egy keretet, vezérfonalat azoknak, akik kacérkodnának a programozással - ha már ennyit lehet vele keresni, ugye ;).
+ Van komoly pszichológiai teszt (tegyük fel jóhiszeműen, hogy a kiértékelés korrelál a kiválasztás helyességével.
+ 4 hónap se nem kevés (hogy mélységekbe is lehessen alászállni), se nem sok (hogy indulásnál elkedvetlenítést okozzon).Sok minden előkerülhet, problémamegoldás, teammunka, teljes vertikumon etc.
+ Nagyon fontos a jó terep, valós körülmények, valós (minta)projektek,
+ Kurzus végén el is lehet helyezkedni, mert segítenek ebben is.
Ha valaki eljut sikeresen a kurzus végéig és kedve is van a dologhoz, annak már "csak" a fizetésért kell megküzdenie és a helyes életvezetést kell kitalálnia és megélnie. :)
- Mondjuk a jelentős túljelentkezés vethet fel problémákat a kimaradók szemszögéből.
Zárójeles megjegyzés: ha valaki egyedül és nem szervezett keretek között akar nekiveselkedni "az akarok-e programozó lenni" témának, annak jó sok kérdést kellhet őszintén végiggondolnia. Én a minap csak annyira jutottam, hogy sajnos ez perpillanat nekem túl nagy, túl komplex, túl ellentmondásos topik, hogy korrekten, közelítő teljességgel, minimális betűvel le tudjam írni. Az említett 4 hónap mindenesetre jó referenciapont a fentiekből.
A Coursera-t, én nem degradálnám le, "csak elméleti alapok"-ra. Vannak ott az ilyen kurzusoknál tesztek, időre kidolgozandó házi feladatok, nagyfeladatok (kiértékeléssel), fórumok révén lehet problémákat kezelni, megoldani, kiértékelni. Minimális díjért certifikációs oklevél is kapható. Bőven ajánlható azoknak akik kiszorulnak a Greenfox Academy típusú képzésekből, ráadásul az angol nyelv is gyakorolható vele.Még akár az önálló távmunka is megcélozható vele/általa (persze megint inkább csak nyugaton).
A NodeSchool-t én nem ismertem, amolyan "köztes" (tehát izgalmas) megoldásnak ígérkezik a fenti két spektrumvég között. Ahhoz jobban bele kellene merülnöm a cucc-ba, hogy véleményt formáljak róla, érzékeljem előnyeit, hátrányait, amit most időkímélésből kihagyok.
A meetup-okról nekem perdöntően nagyon rossz véleményem van.
- Tárgyunk szempontjából nem is tartom hatékonynak.
- A szponzorok (pl.: Prezi) tudhatnak visszataszítóan rettenetesek is lenni.
- Sem kapcsolatépítésre, sem mentorságra nem látszott jó platformnak az én szememben.
Én töröltem is az accountomat pár próba után. De símán lehet ám, hogy csak itthon Magyarországon csináljuk (csináltuk) rosszul, rosszabbul a műfajt.
UPDATE (2016-04-10)
A kommentfolyamban tisztázódott egy meetupos félreértés, aminek sajnos én voltam a gyökéroka. Én ugyanis az előadás-centrikus meetupokra asszociáltam az interjúból, ilyenekről volt élményem, másmilyenről mégcsak tudomásom sem igazán volt (egy egzotikus példát leszámítva), ráadásul mint kiderült én kifejezetten backend- és nem frontend-fejlősztői világból érkezem.
De mint kiderült vannak koncepcionálisan másmilyen meetupok is, amik, ha jók, akkor szintén melegen ajánlhatók az érdeklődőknek, mind mentori, mind kapcsolatépítési szempontból. Egy-egy próbát megérhez az érdeklődőknek, kis költség és pontenciálisan nagy haszon reményében, mondom ezt látatlanba is (én érdeklődő kezdőként biztos próbálkoznék ilyen irányba is).
Coderetreat Budapest
Pylvax Budapest
PHP Pair Programing Budapest
RailsGirls Budapest
DjangoGirls Budapest
PS: Azt tartom továbbra is, hogy szerencse itt is kell bőségesen, hogy az érdeklődés jó táptalajt kapjon. Egy könyvet gyorsabban lehet elolvasni, mint egy tárgybeli videó-kurzust megnézni, ahogy egy bottom-up meetup "fabejárás" is nagyobb erőforrásigényt meg azonalibb és célirányosabb elköteleződést jelenthet, mint egy top-down Coursera/Udacity választék-szűrés. De mindez egyrészt ízlés kérdése, másrészt nem zárják ki egymást. Bizony az (érdeklődő szempontjából) ocsút a búzától
nagyüzemben kell tudni szétválasztani :)
UPDATE (2016-04-12)
Tegnap este futottam bele egy blogba és annak - tárgyunk szempontjából érdekes - két blogposztjába. Komment meg kiegészítés nélkül hagyom őket, hiszen nem célom blogposztban blogposztot írni.
1. 15 menő oktatójáték, hogy megtanulj programozni
2. "Obama bejelentette, arra fogja kérni a Kongresszust, emeljék meg 4 milliárd dollárral, azaz több mint 1100 milliárd forinttal az amerikai oktatás támogatását, a hangsúlyt az informatikaórára helyezve. A kétségkívül hatalmas mérföldkőnek számító lépésnek azonban volt több előzménye is, ezek közül is kiemelkedik a The Hour of Code, azaz a Kódolás Órája, amely már világeseménnyé bővült. Néhány napja jött ki a szervező code.org jelentése a tavaly decemberi egy hetes rendezvényről, amely szerint már 195 millió alkalommal próbálták ki az oldalukon a programozást."
Innentől már csak az interjú egyes részleteivel foglalkoznék (sorrendben).
1.
A "programozó bit" ("mindenkinél volt egy olyan nap, amikor hirtelen programozó lett. Tegnap meg nem volt az, ma meg mar igen.") dologgal a magam részéről nagyon nem értek egyet.
Az én tapasztalatom szerint ilyen nincs. De ha volt is, egyre inkább kihal, mint (érdemi) tényező. ;) Egy-egy sikerélményt, egy-egy fázist lezáró mérfölkövet nem szabad ennek hívni.
A programozás
- egy nagyon nehéz meló
- sok kudarcélménnyel
- sok nemszeretem dologgal
* teammunka
* tesztelés
* dokumentálás
* verbális küzdés, különféle szerepkörű figurákkal
* mások korábbi hibás kódjaiban való könyékig túrás
* etc.
- állandó repetítiv tanulással
- időnyomással
- stresszel
- egészségtelen környezetben (órákon át szemrongáló görnyedés a monitor elött, potenciálisan komoly kiégés-veszéllyel).
Az eufória akkor tudhat a legnagyobb lenni, ha nehéz feladatot tudunk és/vagy könnyedén megoldani és/vagy látványosan, ütősen. A programozás hőskorában lehett ilyen bőségesen. A mai trendek viszont azt mutatják, hogy csak az igazán tehetségesek vékonyodó krémje esélyes csak igazán erre, míg a fizetett programozói munkák tömege minden másról szól, csak nem erről.
A jó oldala mindennek, hogy a felhalmozott korábbi tapasztalatoknak köszönhetően jóval könnyebb ebbe a világba beilleszkedni, horribile dictu több pénzt keresni vele, viszont a rossz oldala, hogy cserében jóval nehezebb egészségesen talpon maradni (65 évesen való nyugdíjazásig).
Én egyébként általában a teljes faltól-falig gondolkodást szoktam hiányolni a témát érintő gondolkodásokból. A maximum-keresés, Hanoi-tornyok, kockaforgatás alapfeladatok megírása akármilyen értelmes programozási nyelven, az csak egy nagyon pici része a nagy egésznek, az én értelmezésemben.
2.
Probléma-felbontás.
Na ez nagyon nagy kedvenc témám. Én egyébként dekomponálást szoktam mindig mondani, de lehet, hogy jobb a felbontás (mert minden benne van, ami kell és mégis csak jobban hangzik egy magyar nyelvű szövegben. A hárommal ezelötti munkahelyemen, szállóigeként mindig evvel szívattak kedvességből a kollégáim, amikor visszatérően került elő, mint ultimate megoldási gyógyszer :)
Én azonban picit másképp látom a dolgot, mint Rafael.
Sokkal nehezebbnek látszik paradox módon az átütő erőt meglátni benne, mint aztán könnyedén alkalmazni.
Nekem az a tapasztalatom, hogy mi magyarok szükségtelenül túltoljuk az agyasságot (adhoc rögtönzésekkel sokszor megspékelve), élen járunk az elbonyolításban (lásd hozzá a társadalmat nagyban mérgező általános és mindent behálózó bürokráciát is). Aminek aztán következménye, hogy küszködünk sikertelenül egy nehéz problémával és/vagy sok hibával, mint megoldanánk lazán, könnyedén két vagy több nagyságrendileg sokkal könnyebb problémát. Szeretjük azt gondolni, hogy a "zseni uralkodik a káoszon".
Messzire vezet: de azt gondolom a nyugati világ egyik nagy sikertényezője az, hogy társadalmilag sokkal jobb munkamegosztásban, könnyebben és jobban tudnak élni. Nem azért, mert jobbak a probléma-felbontásban, hanem mert felismerték az előnyét, mi meg nem vagyunk képesek ezt észrevenni. Mi is - en bloc a teljes hierarchiában - tud(hat)nánk jól felbontani, csak valamiért nemigazán jön össze prioritáshiányban, rossz motivációk eredőjeként.
3.
Akreditált képzés
Egyetértek, túlságosan lassú vele kapcsolatban lényegében minden, pláne Magyarországon. Hamarabb és jobb eredményeket lehet elérni a kor kihívásaira. Hiába van több és mélyebb képzés rajtuk, ha például a piac egyre kevésbé akarja megfizetni a nagy pörgetés közben.
4.
Lean-póker
Az ötlet jó, támogatható az én értelmezésemben.
Azonban én mindenképpen kiemelném, hogy a szakmai jóság és üzleti sikeresség nagyon nehezen tud korrelálni egymással, az én 32+ éves tapasztalatom alapján. Nagyon sok szoftverszemét lett üzletileg sikeres, még az operációs rendszereknél is ;), és vannak hamvába holt értékes projektek (pl.: Steve Jobs NeXT-je).
Az sem mindegy, hogy a fejlesztő "push"-ol, avagy az ügyfél(igény) "pull" üzemmódban fejti ki szívó hatását. Nagyon eltérő stratégiákat eredményezhet a dolog, ami vezethet üzleti sikerre éppúgy, mind kudarcra.
Feliratkozás:
Megjegyzések küldése (Atom)
Bejegyzések
Nagyon örülök az interviewra adott reakciódnak, mindig abból tanul az ember leginkább ha dialógus részese lehet. (Remélem nem bánod ha tegeződünk.) Köszönet érte!
VálaszTörlésAmit mindenképp szeretnék előre bocsájtani, hogy egy interview mindenképp szűkös formátum arra, hogy mindent részletesen ki lehessen fejteni. Egyetértek abban, hogy az egyes témák külön-külön blog bejegyzéseket is megérnének. Ráadásul az olvasóknak is véges a türelme, tehát nem nagyon lehet mély részletekbe belemenni. Ennek elkerülhetetlen következménye, hogy rengeteg sarkítás van az interviewban, amit esetleg hosszabb szakmázgatásban már sokkal óvatosabban fogalmaznék meg.
WoW :) És persze, hogy nem bánom a tegeződést, sőt.
TörlésÍgy van, abszolút ahogy mondod. Éppen ezért az arányosság szem elött tartásával, én is tömörítettem, sarkítottam a blogposztomban, pedig itt elvben jóval több tér lenne a betűknek, mint egy interjúban. Igyekeztem az előzetesen "definiált" méreteket tartani a reflexiómban,felvállalva ennek ismert korlátait.
Az első dolog amire reagálnék az a meetup-ok kérdése. Tény és való, hogy nem minden meetup jó, sőt! Vannak kifejezetten alacsony színvonalú előadások is, és egy-egy meetup group kínálata is elég hullámzó tud lenni. Épp ezért volt nekünk a Craft Meetup megalapításánál nagyon fontos szempont, hogy minden egyes előadást komoly minőségi kontrollnak vessünk alá. (Például a szervezők minden egyes előadást meghallgatnak mielőtt elfogadjuk.) Én személy szerint rendkívül büszke is vagyok arra az immár 21 előadásra, ami immár a YouTube csatornánkat gazdagítja.
VálaszTörlésA meetupok ismerkedésre is tudnak jók lenni ha az ember nem kifejezetten introvertált, és nem rohan haza az előadás után. Eleinte ismeretlenül valóban kicsit nehezebb bekapcsolódni, de ha már van néhány ismerős a rendszeresen járó arcok közül, akkor egy idő után viszonylag gyorsan kezd bővülni az ember ismeretségi hálózata.
Az én tapasztalatom szerint kevesen tudnak jól és érdekesen prezentálni, komoly információértékkel. Egyébként sajnos én sem vagyok jó benne.
TörlésAzt tartom, hogy sok idő és sok energia kiválogatni a jókat, míg a hozzáadott értéket már nem érzem evvel arányosnak. De ezt vehetjük az én hibámnak.
By the way nemcsak a meetupokkal vagyok így, hanem a fizetős szakmai konferenciákkal is, ahol nagyon sok gyenge előadás bír lenni.
Az előzetes kontroll az jó ötlet tudhat lenni, mind a meetup-minőségbiztosítás miatt, mind a prezentáció szempontjából (hiszen másodjára/többedjére előadva tudhat jobb lenni).
Tárgyunk kontextusa szempontjából ugye úgy került elő a meetup, hogy akik kacérkodnak a programozással, azok menjenek ilyen alkalmakra (ötletekért, mentorokért, kapcsolatokért). Na nekem evvel volt eredendően problémám, illetve nagyon nem érzem hatékonynak. Én jobban hiszek abban, hogy a kezdőnek (jól) irányított impulzus(oka)t kell kapnia, a meetupok, meg adhoc módon esetlegesek (értelmezésemben).
Elismerem, hogy az interview-ban nem volt egyértelmű a megfogalmazás, de én nem elsősorban az előadásokat tartalmazó meetupokra gondoltam a programozni tanulni vágyók esetében. Meg is említettem azt a 4 esemény sorozatot amit számukra ajánlok: Coderetreat Budapest, Pylvax, RailsGirls, DjangoGirls. Azóta amúgy indult még egy esemény sorozat PHP Pair Programing néven. Ezek az esemény sorozatok mind azt tűzték zászlajukra, hogy különböző tudású programozókat hozzanak össze programozni. A Pylvax, RailsGirls és DjangoGirls teljesen kezdőket céloz dedikált mentorokkal, míg a Coderetreat és a PHP Pair Programing mar kölcsönös mentoráláson alapul.
TörlésA szakmai előadások hatékonysága valóban változó tud lenni. Konferenciából is csak a néhány legjobbra érdemes eljárni, és még ott is be-be csúszik egy-egy kevésbé jó előadás. Sajnos azt el kell ismerni, hogy nagyon meg kell válogatni, hogy melyik konferenciára fizet be az ember. De ha belegondolunk az egyetemi előadások közül is csak az volt jó, amit egy kifejezetten tehetséges előadó tartott amúgy is érdekes témáról.
Saját tapasztalataim alapján valóban nem könnyű feladat fenntartani egy meetup minőségi színvonalát, és részben ez is az oka annak, hogy a Craft meetup-on szinte kizárólag Emarsysos emberek adtak elő: házon belül tudjuk kik a jó előadók, és van arra is mód, hogy előzőleg megvitassuk az előadás tartalmát. Külső előadókat jóval nehezebben tudunk felkérni, mivel nem tudjuk mennyire jó előadók, és azt sem tudjuk mi az ami épp foglalkoztatja őket, milyen témát érdemes nekik felvetni. Így a külső előadók esetében teljesen az önként jelentkezőkre vagyunk utalva. Ezzel együtt én úgy érzem maximálisan megérte beletenni ezt a munkát. Például ezekért az előadásokért:
https://www.youtube.com/watch?v=AKd6DQyxUlY
https://www.youtube.com/watch?v=uefiMhZ5dWY
https://www.youtube.com/watch?v=S_6ThOkaQN4
Még egy apró megjegyzés a konferenciákkal kapcsolatban. Mind az előadásos esti meetupok esetében mind a konferenciáknál a realizálható érték nagyobbik fele a kapcsolat építésből adódik. Én rengeteg embert ismertem meg így, akikkel azóta tartom a kapcsolatot, és segítjük egymást. Ehhez persze az kell, hogy az ember merjen vadidegeneket megszólítani ebédnél, cigizés közben illetve, hogy merjen odamenni előadás után az előadóhoz és érdemi társalgásba kezdeni vele.
TörlésÍgy már abszolút rendben van, tök jó és ajánlható alternatíva, ráadásul én is kitalálhattam volna a "coderetreat"-ből, hogy miről lehet szó. Az ember csak a legjobbakat tudja kivánni, hogy beteljesítse az alkalom(sorozat) a küldetését.
TörlésÉn valóban csak az előadás alapú meetupokra fókuszáltam plánehogy ilyeneken voltam csak (az én területemen nem is nagyon volt/van másmilyen, amiről én tudok, de lehet, hogy durván le vagyok maradva). Egy fizetős konferencia 0-dik napján voltam hasonlón amiről te beszélsz, ahol a neves Olivier Grisel (scikit-learn egyik frontembere) volt a "játékmester", azt nagyon élveztem, nagyon jó délelött volt.
Pontosan úgy van ahogy mondod. Nemigazán tudom hogyan miért, de nagyon kevés karizmatikus előadó volt még a főiskolán/egyetemen is, ahová én jártam (BMF,ELTE) és mégcsak nem is témafüggő talán a dolog. Én nagyjából mindent szerettem az egyetemen beleértve a legdurvább matekokat is (csak a funkcionális nyelveket és a grafikus programozást nem), viszont alig-alig volt (én felfogásomban) jó előadó. Valahogy mintha ez a feature adottság lenne, nem tanulható képesség.
Belenéztem kommentreakcióim elött pár videótokba (ahol moderáltál 6 ember között, a lean pókeresbe, meg az "esés"-esbe), sajnos az én fülem nagyon gyenge ezekhez: hiába indultak érdekesen, még ha én pont nem a frontend-fejlesztés világában utazom is, így aztán fel kellett adjam őket. Konkréten rengeteg mindent nem értettem ki a videókból. Még a lean póker üzenetét sem tudtam rendesen összerakni, hogy fordítod le a lean pókert valós projekt körülményekre, amikor már nem pókerezni kell, hanem a 64%-nyi halott feture fejlesztési idejét értelmesebbre fordítani egy más konkrét adott projekt kontextusában.
TörlésVégül updateltem magát a posztomat is az említett 5 meetup-linkkel, hogy az infó necsak a kommnentfolyamban legyen meg.
TörlésAz, hogy valaki jó előadó kisebb részben adottság, de nagyobb része tanulható. Sajnos nagyon kevesen tesznek bele energiát, és tananyag se nagyon érhető el, inkább egymástól tudunk tanulni. Az Emarsysnál mi elég nagy energiát teszünk abba is, hogy akinek meg van az alap készsége erre, annak segítünk kihozni magából a maximumot. De tény, hogy ezzel mi nagyon nagy kivételnek számítunk a szakmában. A legtöbb jó előadó csak azért az, mert kiemelten jó adottságai voltak, és ráérzett magától, pedig ennek abszolút nem kellene így lennie.
TörlésA 3 említett videóból kettőnél valóban nem sikerült jól a hangfelvétel. A Lean Pokeresnél még épp csak tanultuk hogyan kell ezt csinálni, a panel beszélgetésnél meg nem volt megfelelő infrastruktúránk 7 ember hangosításához. A legtöbb videóban azért már sokkal jobban sikerült a hangfelvétel.
A Lean Poker célja az, hogy egyes módszereket gyakoroltasson egy mesterségesen generált de egyéb hatásoktól mentes közegben. Kb annyi a köze a valósághoz, mint egy küzdő sportbeli forma gyakorlatnak a verekedéshez. A való élet soha nem pont olyan lesz, de kialakít rutinos mozdulatokat, amik észrevétlenül beépülnek az éles helyzetekben adott reakcióinkba. A Lean Poker ahhoz ad építő kockákat, hogy képesek legyünk a lehető leggyorsabban feedback-et gyűjteni, de az építő kockákat utána meg bele kell helyezni a való életbeli szituációkba. Az utóbbi sem triviális, de ha nincsenek meg az építő kockák, akkor még nehezebb.
Az én sejtésem, hogy nem tanulható, maximum csak javítható az a fajta "jó előadóság" amit én jónak tartok. De ne legyen igazam, sőt az ellenkezőjét kívánom a világnak.
TörlésSzámomra önmagában már az nemtriviális kérdés, hogy lehet igazolni vagy cáfolni a tanulhatóságot. Próbáltam definiálni a "jó előadóság"-ot és már itt elakadtam. Begépeltem pár definiciót, szempontot és mindent kitöröltem azonnal mert nem voltak elég jók/publikálhatók.
Köszönöm a lean pokeres kiegészítéseket. A részleteket már egyre jobban értem, de a lényeg még mindig nincs meg. Vélhetőleg szóban, néhány célirányos kérdéssel, ezt is könnyebb lenne rövidre zárni.
Vagy azzal ha eljössz egy eseményre. Az többet ér minden szónál :)
TörlésAzt azonban el kell ismerni, hogy az előadásos meetup-oknál jóval hatékonyabbak mind ismerkedésre mind mentor keresésre az olyan meetupok amik inkább workshop jellegűek. Egy coderetreat-en például szinte elkerülhetetlenül megismerkedik az ember legalább 6 új emberrel, akikkel 45-45 percet kódol is közösen.
VálaszTörlésAz meglep, hogy a Prezi számodra visszataszítóan rettenetes. Érdekelne mitől alakult ki róluk ez a véleményed. Nekem történetesen a feleségem ott dolgozik fejlesztőként, és még ha nem is minden felhőtlen összességében nagyon jól érzi ott magát, és szakmailag is rengeteget fejlődött.
"Programozó bit" - na ez valóban egy masszív sarkítás de nem ok nélkül való, ezért nem is fogom megvédeni mint abszolút igazságot. A szoftver fejlesztésben mindig van még hova fejlődni, és már csak ezért sem ennyire egyszerű a kép. Ezzel együtt én azt figyeltem meg, hogy van egy olyan mérföldkő a fejlesztők életében, amikor ráéreznek a dolog ízére, megjön az önbizalmuk, és a folytonos "szívást" már nem úgy élik meg mint áthághatatlan akadályok sorát, hanem mint kihívást, aminek a megoldása örömet okoz. Az első időszakban, amikor meg azzal küzd az ember, hogy syntax helyes kódot írjon, meg hogy egyáltalán elképzelése legyen arról, hogy merre kell indulni az nagyon demotiválóan tud hatni az emberekre. Mivel ez az állapot viszonylag hirtelen szokott megszűnni, és gyakorlatilag perdöntő, hogy valakinek van-e kitartása ahhoz, hogy eddig eljusson, ezért én ezt egy kiemelten fontos mérföld kőnek érzem. Aki el tud jutni idáig, annak utána már nem szokott kérdés lenni, hogy abba hagyja az egészet, viszont ez előtt a pont előtt sokan feladják, mert nem tudják, hogy ez egy normális fázisa a tanulási folyamatnak. A sarkos megfogalmazásnak elsősorban az volt a célja, hogy a programozni tanulni vágyókat felkészítse arra, hogy az első időszak igenis nehéz, demotiváló lesz, és ezen át kell esni, végig kell menni az úton akkor is ha sokáig nem látjuk a fényt az alagút végén.
Talán az adatbanyaszat.blog.hu-n írtam egy publikus kommentet az egyik Prezis meetup után (Google-n keresztül nem találtam), sok minden nem tetszett, másnak sem egyébként. A legnagyobb problémám az volt, hogy lenyúltak egy működő meetupot, majd úgy ajándékoztak, hogy közben a saját filozófiájukra/képükre akarták formálni az egészet (ha jól tévedek egyébként sikerrel), és mindezt valami elképesztő nagyképűséggel. Nekem ez olyan rémisztő volt, hogy Prezit soha többet nem akarok látni.
TörlésDe szakmán kívüli megnyilvánulásaiktól is feláll a szőr a hátamon:
http://index.hu/video/2015/11/19/prezi_ovi_budapest_school_halacsy_peter_ovoda_iskola/
"Programozó bit" Nem tudom. Az én tapasztalatom, pláne az utóbbi időben más volt (most 32+ éves időtávlatban nézve a dolgot).
TörlésEgyrészt egyre sűrűbben egyre több újat kellett tanulni, gyorsuló avulás mellett, állandósuló szívások (szívástömeg/-koncentráció) mellett.
Másrészt az agilis fejlesztési módszertan is rendesen ki szokta fejteni káros mellékhatásait: idővel arányosan egyre szuboptimálisabb rendszerek toldozgatásánál-foltozgatásánál. Sokszor levegőt venni sincs idő ilyenkor.
A végeredmény: az élvezkedéses fázisok kvázi tünnek el, a nagy pörgésben/hajtásban, meg globális piaci versenyben.
Persze símán lehet (sőt biztos), hogy én lassultam csak le vénségemre... :)
Az én eredendő problémám a "programozó-bit" tanulási görbe jellegű. Analógiának érzem az angol-tanulással. Nagyon hamar komoly sikerélményt lehet elérni az angollal, mondatokat tudhat az ember megformálni, még akár fórumozni is tudhat angol nyelven ("angol bit"-ként). De a valós angol nyelvtudás még nagyon messze van ettől a ponttól, az én értelmezésemben.
Ha régen meg is állt a dolog, meg nekem is volt ilyen "bit"-feelingem, ma már ez eltünőben van, rossz tendenciák miatt. Én ezt ennyire pesszimistán látom.
Prezi: sajnos nem ismerem a pontos történetet az általad említett meetup ügyében, így arra nem tudok reagálni. Csak azt tudom elmondani, hogy én hogyan látom a Prezit.
TörlésAz tény, hogy a Prezi alapítóknak van egy erőteljes életfilozófiája ami mögé nem csak beálltak saját maguk, hanem magát a céget is úgy építették fel, hogy az is ezt képviselje. Én személy szerint ezt nem érzem bajnak, egy olyan cég ami ilyen profitot tud termelni jó ha megfogalmaz társadalmi célokat, és ezek mögé a célok mögé nem csak szavakkal, hanem tettekkel is beáll.
A linkelt videóval viszont nem értem mi a bajod. Végre valaki nem csak nyavalyog azon, hogy pocsék az oktatás, hanem megpróbál jobbat csinálni ráadásul nem csak a gazdagoknak. A porosz gyökerekkel rendelkező frontális oktatás egyszerűen alkalmatlan a 21. század kihívásaira de az állami iskolarendszer reformjai épp a központosítást és az magolt tudás erősítését szolgálták eddig, épp az ellenkezőjét mint amire szükség volna.
Egyszerűen azért van szükség az ilyen civil kezdeményezésekre, mert az állam elbukott. Számomra üdvözítő, hogy vannak tehetős emberek akik e mögé beállnak, és megpróbáljak a világot kicsit jobbá tenni. Vagy legalábbis olyanabbá ami nekik jobban tetszene.
Mondjuk azt sem teljesen értem, hogy ha nem tetszett a Prezi által képviselt világkép, akkor miért vittétek oda a meetup-ot? Egy cég ha szponzorál valamit, akkor azzal a dologgal azonosítják, tehát teljesen érthető ha vannak elvárásaik a szponzori pénzért cserébe. Én se szponzorálnék cégként olyat amivel nem tudok azonosulni. Ugyan ezt megfordítva, én konkrétan elhoztam meetup-ot szponzortól miután meghallottam, hogy a cég HR vezetője kérdőre vonta a nőnemű résztvevőt, hogy mit keres egy programozó meetupon. Mint meetup szervező én ezzel nem, hogy nem tudtam azonosulni, de szöges ellentétben állt azzal amit képviselek, és a meetupomat sem fogom olyan szponzorhoz vinni, aki ilyen előítéletesen viselkedik.
Törlés"Programozó bit" - Nekem azért nem ugyan az a programozás tanulás és az angol tanulás, mert egy társalgás során nincs módod mindenre rákeresni Google-ben amit még nem tudsz. A programozás esetén sokkal kisebb az a lexikális tudás amit feltétlen fejben kell tartani. És ezt éppen az elmúlt évek folyamatai váltották ki. Pár éve még simán volt értelme egy konkrét nyelvhez tartozó lexikális tudást kérdezni egy interview-n, vagy rákérdezni a nyelv tipikus gotcha-ira. Ma már ez értelmét vesztette. Ha valaki rájött mikor mire keressen rá a neten, és utána hogyan építse be azt egy TDD folyamatba, akkor a programozási feladatok széles spektrumát le tudja már fedni. Ma egy Junior és egy Senior között nem az a fő különbség, hogy mi az amit az egyik meg tud oldani a másik nem, hanem sokkal inkább az, hogy a Junior jóval lassabban oldja meg jóval inkább hagyatkozik az internetre. Persze egy Junior által irt kódot sok esetben még érdemes kicsit faragni, refactorálni, de ez pont olyasmi amit viszonylag gyorsan felszednek a srácok. 3-6 hónap után már alig szoktam beleszólni a Junior fejlesztők munkájába.
TörlésAmúgy nekem egy olyan érzetem is kialakult most az előző commentet olvasva, hogy gyökeresen más tapasztalataink vannak melyeket feltehetőleg gyökeresen más hátterű cégeknél szereztünk. Nekem például az agilitásról még véletlenül sem a folyton romló kód jut eszembe, hanem a fokozatosan javuló kódminőség. A 4 év alatt amit a jelenlegi munkahelyemen töltöttem összehasonlíthatatlanul jobb lett a kódminőség. Meg vannak persze az agilitás korlátai - nagyobb refactor ritkán tud megvalósulni egyszerre - de kisebb lépések eredőjeként komoly dolgokat is el lehet érni.
TörlésNem gondolnám, hogy ebben a szűkös és technikailag eléggé gyengécske/korlátos (hiába a nagy Google-től származó) blogspot.hu-s "kommentmotorban" fel lehet oldani a Prezi-averzióim mélyrétegeit. Valszeg a komment-formátum sem jó rá, élőszóban könnyebb lenne. Rákérdeztél, röviden próbáltam rá válaszolni, itt és most eddig tudtunk jutni nyilvánvalóan.
TörlésA konkrét kérdésedre válaszolva én csak egy voltam a 60-90 érdeklődő főből, ráadásul tényleg csak érdeklődő státuszban (nem szervezőként). Prezi nem szponzortól nyúlta le magának a meetupot, hanem egy önszerveződő nagyobb érdeklődéshullám vasútjára ült csak fel. Az ajánlata sem volt vállalhatatlan, "csak", most egy kicsit túlspilázva, extrapolálva amolyan "keresztapás" stílusban adta elő.
A linkelt videónál az a gond, hogy attól még, hogy valaki sikeres és pénze van, nem biztos, hogy tudja a nagy tutit egy olyan nehéz témában, mint a gyereknevelés és -tanítás meg mögé rakható értelmesen társadalmi konszenzus. Más szóval a nemes cél valamint az üzleti sikeresség önmagában még nem validál módszert.
Magáról a témáról betűhegyeket lehetne írni (én is követtem el ilyen "bűnöket" ezen a blogon).
Önmagában azzal semmi bajom, ha szülők bizalmat szavaznak Halácsyék - számomra - hagymázas elképzeléseinek én csak azt a jogomat tartom fenn magamnak, hogy a saját tapasztalatom alapján, hadd ne kelljen jóképet vágnom hozzá.
A "programozó bit" dologban viszont ezek szerint nagyon nem értünk egyet. Amit konkréten írsz azzal nincs gond, csak az a baj vele, hogy más vágányra terel, mint ami nekem eredendően problémám volt az egyébként általad felhozott dologgal. Állítom továbbra is, az angol nyelvtanulásos analógiám fenntartása mellett, hogy "bit"-es megvilágosodás egy értékénél jóval nagyobb mézesmadzagot jelent, a valóság rovására. Én ezt gondolom, elfogadom, ha valaki evvel nem ért egyet.
TörlésAgilis módszertannál nálam axióma, hogy ahol a rendszer minősége romlik idővel, ott megbukottnak tekintem az agilis módszertant (mivel nem tudta beteljesíteni hivatását). Nyilván a fordítottja is igaz, ahol javul a minőség és megfelelően konvergál a cél felé, ott működőképes tudhat lenni a módszertan.
Az "agilitást" biztos lehet jól csinálni (távolról sem zárnám ki), de megfelelő feladat és környezet kell hozzá. Amit én láttam éveken át az közel mind rossz volt diszharmóniák miatt.
A téma maga olyan, hogy a folyamat komplexitása miatt kevéssé átlátható, nehezen konkludálható, de a végeredmény azért jóval könnyebben azonosítható.
Mindazonáltal az agilis módszertannal szembeni minden - rossz tapasztalatom ellenére való - nyitottságom sem feledteti azt a "programozó bit" kontextusában, (ez most kicsit bonyi lett, de talán érthető), hogy általánosságban kevéssé kedvez a tanulni vágyó dolgozónak, sokkal inkább a konkrét projektnek magának, amiről én eredendően szólni kívántam volna.
Igen, valóban nem feltétlen ez a megfelelő forum, hogy a Preziről beszélgessünk, és tényleg nem ismerem annak a meetup-nak a történetét. :) Csupán annyit akartam még mondani, hogy szerintem a Halácsy se azt gondolja, hogy ő tudja a nagy tutit ebben az ügyben. Két kulcs mondat is elhangzik a videóban: "Ezeket nem én találom ki! Nagyon jól hangzanak, de kb 30 éve erről beszélnek" A másik kulcs mondat, hogy a tanárok kezébe döntési hatáskört akarnak adni. Nekem ebből pont az jön le, hogy Ő pontosan tudja, hogy a Prezi sikere nem jelenti azt, hogy Ő innentől tudja a nagy tutit. Épp ellenkezőleg, azoknak a kezébe akarja adni a döntés lehetőségét akik értenek is hozzá.
TörlésAmúgy aki ismeri H.P.-t az tudja, hogy Ő az utolsó aki bármilyen döntést egyedül hozna meg. Ha szakmai kérdéssel fordulsz hozzá a legtöbb esetben visszakérdez, hogy "szerinted mi a legjobb megoldás?". Nagyon ritkán mondja meg a tutit, sokkal inkább segít megtalálni a saját válaszaidat. Klasszikus coaching típusú vezető.
Ezzel együtt szerintem azt sem mondta senki, hogy kötelező egyetérteni vele. Ő csinál valamit ami szerinte jó, és megadja másoknak a lehetőséget hogy csatlakozzanak a kezdeményezéshez. De bárkinek ott van a lehetőség, hogy maradhat az állami oktatásban, vagy csinálhat saját alternatív oktatást.
"Agilis módszertannál nálam axióma, hogy ahol a rendszer minősége romlik idővel, ott megbukottnak tekintem az agilis módszertant" --- Ez ügyben nekem két meglátásom van:
Törlés1) A legtöbb esetben amikor agilis módszertanról beszélünk akkor csak nevében agilis a csapat, valójában nem hű az agilis manifesztóhoz. Rengeteg pocsék agilis bevezetés történik, és ezek jelentősen rontják az agilitás megítélését. Sajnos buzzword lett az agilitásból amit a cégek pénzért megvenni szeretnének, miközben az agilitás egy cég kultúra és gondolkodás mód. A formalizált scrumnak és a köré épített tanácsadói rétegnek annyi köze van az agilitáshoz mint Adam Sandler-nek a minőségi filmgyártáshoz.
2) Még ahol jól is vezetik be az agilitást ott is előfordulhat, hogy nem működik jól. Ez egyszerűen azért van mert az Agilitás nem egy ezüstgolyó, hanem egy megoldás ami rengeteg kontextusban jól működik. De például rakéta vezérlő szoftvert egy Mars misszióhoz nem agilisen érdemes fejleszteni.
Azzal viszont nem értek egyet, hogy nem kedvez a tanulni vágyóknak az agilitás. Eleve az agilis csapatokban rengeteg pár kódolás történik, ami gyakorlatilag one-on-one mentoringba is át tud csapni. Ráadásul minden kicsi iterációkban történik, és ennél jobb közeg nincs arra, hogy az ember tanuljon a saját hibáiból. Nincs ideje a hibáknak arra, hogy kezelhetetlenné váljanak, minden iterációban tudunk reflektálni az előző hét eseményeire. Az agilitás pont arra van kihegyezve, hogy segítse a csapat önfejlesztését. Ha ez nem történik meg, akkor az nagyon nem agilitás.
TörlésA Prezit és Halácsyt ezen a ponton lezárnám, így is több szó volt róla, mint jólesett volna. Részemről, annyi a zárszó ebben a threadben, hogy nekem teljesen más és másképp jött le, mint neked. További megvitatható konkrétumok nélkül viszont nincs miről tovább beszélni esetükben.
TörlésAmi az agilitást illeti, a két meglátásod nekem túl általános ahhoz, hogy cáfolja az idézett axiómámat. Magával a manifesztóval is komoly problémáim vannak "axióma" szinten is (de ebbe végképp nem mennék bele, mert sosem zárjuk le ezt a comment-folyamot)
TörlésÉs nyilván a valós életbeli tartalommal megtöltése sem triviális ügy.
Tartom továbbra is, hogy kevésbé kedvez a tanulnivágyóknak is és itt hangsúlyozom, hogy a való életben (meetupokra nyilván teljesen megfelelő).
Akkor tudna kedvezni, ha lenne mondjuk tíz típushiba (extrapolálva), amit ki kellene és lehetne gyomlálni. Ámde azonban ellenben viszont, mind a potenciális hibák száma nő, mind a megtalálási nehézségük majd menedzselésük nehezedik, miközben a pörgős gazdasági versenyben, mindenre egyre kevesebb idő és erőforrás jut a versenyelőny megtartása valamint a profit érdekében.
A párprogramozás sem ultimate gyógyszer valódi munkastresszben, nézetem szerint.
Azt nem teljesen értettem, hogy hogy jönnek ide az olyan tankönyvi algoritmus példák amiket említettél, és mire mondtad, hogy hiányolod a faltól falig gondolkodást. Ha valamit képviselek én magam is az épp az, hogy nem attól lesz valaki programozó, hogy olyan elemi dolgokat fejleszt le, amik egyébként minden nyelven már a nyelv részeként elérhetőek. Persze fontos lépése lehet ez is a tanulásnak, de messze nem ettől lesz valaki programozó.
VálaszTörlés(Én speciel 10 éve kódoltam már mikor először találkoztam ezekkel a feladatokkal. Persze 8 évesen kezdtem a programozást azzal, hogy a QBasic példa programjaiba bele módosítgattam, hogy picit más legyen a játék, és utána is mindig "valódi" projekteken dolgoztam, és csak az egyetem évei alatt találkoztam először Hanoii tornyaival.)
A másik amit nem sikerült kontextusba helyeznem az a probléma felbontással kapcsolatos reakciód. Általánosságában persze egyetértek azzal a meglátással, hogy egy ökörség azt gondolni, hogy a zseni uralkodik a káoszon. Az egyik legfontosabb alapelv a YAGNI ("you ain't gonna need it") és nem véletlenül. A kód minél egyszerűbb annál könnyebb vele bánni. Ez olyannyira igaz, hogy sokszor azt szoktuk mondani, hogy a legjobb kód az amit nem kellet megírnunk. (Vagy azért mert más megírta már nekünk, vagy azért mert sikerült bebizonyítani, hogy nem volna üzleti értéke.) Egyel kevésbe jó, de még mindig zseniális az a kód, amit végre sikerült törölni. :) Szóval amit nem értek az az, hogy miben nem értünk egyet. :)
"Faltól-falig" topik. Számomra nehéz téma az, hogy mit kell mondani egy "programozással kacérkodó"-nak (utaltam is rá egy apróbetűs bekezdésben). Azért nehéz, mert kevés szóval kéne, se nem marketing-csábító, se nem elriasztó ám arányos impulzust adni, ami minél egzaktabb döntéshez vezet. Egyelőre pihentetem is a témát, emiatt.
TörlésNekem a "programozó bit" egy túlzottan csábító hívószó, de ha már van ilyen (illetve tegyük fel én tévedek a megítélésében), akkor is terjedelmi korlátok figyelembevétele mellett is, éreztem a dolog árnyalásának hiányát, a teljesség kontextusában.
Probléma-felbontás. Nekem az jött le az interjús szavaidból, hogy mindenki akar/szeret felbontani problémát, csak nagyon sok önkínzás és gyakorlás kell hozzá.
TörlésÉn meg úgy érzem a fordítottját mondom. Szerintem tudnánk jól és könnyedén felbontani, csak nincs rá motivációnk, most úgy nagy áltlánosságban fogalmazva (az én tapasztalatom szerint).
By the way én elképesztő mennyiségű túlkomplex és okádék kódot láttam az életemben ahhoz, hogy hiányát érezzem a probléma-felbontásnak (valós gyakorlatban).
A probléma felbontás témában akkor viszont valóban ellentétes tapasztalataink vannak. Ráadásul picit másról is beszélünk.
TörlésAmiről Te beszélsz az nekem a refactor témakörhöz kapcsolódik. De én ha találkozok egy rossz kódrészlettel, akkor szinte garantáltan neki esek. Legalább egy picit jobbá teszem ha teljesen rendbe rakni nincs is idő. Sokszor vitázunk a kollégáimmal, hogy mennyi refactor fér bele egy-egy iterációba, de szerintem nekünk sikerül valamelyest a közép úton járni. Persze nálunk se sül minden jól el. Az egyik jó szándékú kolléga egyszer saját szakállra belevágott egy nagyobb refactba, és az lett a vége, hogy félbe kellet hagynia, és a fél állapot rosszabb volt mint ha bele se kezd. De ez egy nagyon ritka kivétel, nem is nagyon tudnék másik hasonló esetet felhozni.
Szóval nekem az a tapasztalatom a saját kollégáimmal, hogy szeretünk problémát felbontani refactor formájában, és aktívan műveljük is. Az újoncoknak viszont eleinte még nem megy ez olyan jól, főleg ebben szorulnak mentor segítségére.
Amiről viszont én beszéltem az egyel korábbi lépés. Amikor előttem van az üres lap, és egy követelmény. Ilyenkor egy teljesen kezdőnek sok esetben ötlete sincs hogyan kell elindulni. Nem találja meg azt az absztrakciós réteget ami a feladat alatt van közvetlenül. Én erről a készségről beszéltem. És szerintem ez épp olyasmi, amire nagyon nehezen érez rá egy újonc, és sok gyakorlást igényel.
Tényleg más gyökerekkel rendelkezünk, más nyelvet beszélünk. Az általad írt "refactoring" dologgal megint nincs gond, csak én megint nem erről beszélek. Hanem pont arról, hogy MIÉRT alakulnak olyan (1)komplex (2)gányolások tengernyi mennyiségben (nem hinném, hogy csak én futok bele ilyenekbe, mindenhol másutt csak kód-igazgyöngyök lennének), aminek aztán refactoringgal kell nekiesni és legalább részben gyógyítani.
TörlésErről pont van egy egy órás előadásom :) Kicsit hosszabb téma, úgyhogy itt most nem mennék bele mélyebben, de a lényeg, hogy ez valamennyire elkerülhetetlen. Nem az a cél, hogy ne legyen gányolt kód, hanem az, hogy ne váljon fenntarthatatlanná az állapot. A refactor ennek az eszköze.
TörlésHa mindig mindent tökéletesre írnánk egyrészt soha nem végeznénk, mert mindig lehet jobbat, másrészt a kód akkor is rohad ha eredetileg tökéletes volt. A kérdés csak az, hogy mi az egyensúlyi állapot a makulátlan soha el nem készülő kód, és a gyorsan elkészült fenntarthatatlan kód között. Ez viszont már nagyon az adott cégen és közegen múlik.
Én egyrészt szigorúbb vagyok, nekem nem elég a "fenntartható állapot". Ahogy én látom egy-egy újabb agilisen érkező üzleti igény nagyon sokszor azonnal szuboptimálisabb állapotba teszi a rendszert, csupáncsak a megjelenésével is.
TörlésÉn azt mondom egyszerre cél az üzleti igény kielégítése, és a "re-optimalizáció" (hogy a következő kör ne hátrányból induljon). Az én tapasztalatom viszont az, hogy a pörgésben és stresszben csak az üzleti igény szokott kielégülni, de egyre inkább úgy, hogy az csomó nemkívánt mellékhatással jár, a reoptimalizálás minden igénye nélkül. Nincs közvetlen előny/hátrány: csak közben szép lassan nőnek a fejlesztési és üzemeltetési költségek meg egyre nő az esélye a marakodásnak a megrendelő és szállító között a felelősség megosztásakor, a (köz)hangulatromlásról már nem is beszélve.
Nyilván mindez hozzáállás, szakmai képesség kérdése, milyen tendenciák mellett hová mivé fejlődik, mindennek nem kéne ennyire sarkítottan rosszul történnie, de a (globális) verseny nagy szorító erő, ami sok rossz választ tudhat generálni.
Másrészt engedékenyebb (fenti sorokból is láthatóan). Nem kívánok tökéletes kódot/redszert, de azt igen, hogy ne legyen belekódolva a fejlesztési folyamatba a tönkremenés, informatika oldaláról (csak az üzlet magának tehesse tönkre a saját maga által kifizetett cuccot).
Az amit itt szerintem feszegetsz az a nem funkcionális követelmények üzleti értékének kommunikációja. Ez egy valóban nehéz témakör, és még en sem találtam rá kielégítő megoldást. Robert C. Martin azt az álláspontot képviseli, hogy nem kell mindenről tudni az üzleti oldalnak, fű alatt kell megcsinálni az ilyen jellegű feladatokat, és tudni kell nemet mondani az irreális határidőkre. Nekem ez némileg őszintétlen hozzáállsásnak tűnik, és könnyebb mondani mint csinálni. Ami nekem eddig valamennyire bevált az az üzleti oldal és a fejlesztők közötti őszinte bizalmon alapuló kommunikáció, de ez sem tökéletes. Szóval el kell ismerni, hogy ez még egy nyitott probléma...
TörlésAmit Martin mond az OO-paradigma kompatibilis ugyan :), de én teljesen ellentétes álláspontot képviselek (amit korábban már fejtegettem itt a blogon): (át)láthatóvá és termékké kell konvertálni a re-optimalizációt, egy jól kitalált meg visszamérhető protokoll mentén.
TörlésMinden funkciónak van kisebb-nagyobb rezsije, amit tudomásul kell venni minden szereplőnek: a megrendelő se "mazsolázgathat", költségminimalizálás szintjén, hiszen overhead az élet más területén is van (hr, számlázás, főkönyvelés stb). Ahogy az autóból sem spórolják ki a plusz pénzbe kerülő anyagot és technológiát, mert balesetek különben jóval csúnyább kimenetelűek lennének.
Persze evvel a kényszerkörülménnyel az informatika-oldal sem élhet vissza, ezért kell szabályozottnak és visszamérhetőnek kell lennie.
Nagy kincs a bizalom, a tisztességes hozzáállás és az üzleti oldal hozzáértése/rálátása a projekt egészére, ez már félsiker az úton. A problémák ott kezdődnek ha ez(ek valamelyike) nincs és/vagy olyan belharcok vannak mindkét oldalon a nagy pörgésben és helyezkedésben, hogy csak egyre gyorsabban avuló szemméttel töltjük a szoftvertemetőt.
Én értem és megértem, hogy a gyorsuló pörgésben és versenyben, aki gyorsabban ér célt, az nagyobbat kaszál és nincs is evvel gond, egy prototípuskód sok randaságot el tudhat viselni, a cél érdekében, ha az időn van a fókusz. De egy ipari standard - üzemeltetésre szánt - informatikai folyamatot ne "melegvízet feltalálós" prototípusként akarjanak implementálni, korábbi tapasztalatok ignorálásával, olyan üzletis emberek, akik bármiféle hozzáértés nélkül csak a pénzt tudják felmutatni a projekthez (vagy még azt se) az informatikai oldal meg tudja és legyen méltósága hozzá szakmailag védhetően definiálni mit igen mit nem (feladat ismeretében).
Van egyébként még egy érdekes aspektus, amire én nem tudom az optimális választ (csak a sajátomat): nevezetesen a globális verseny kihozhat egy olyan attitüdöt az informatikusokból, hogy azért programozzunk "bonyin/csúnyán", hogy a versenytársak ne tudják "lecsapni a kezünkről" a munkát (mert hiszen így a fejlesztő ért hozzá a legjobban, horribile dictu még üzemeltetés szintjén is).
TörlésEgy tisztább, szakmailag vállalhatóbb kódot, projektet más is könnyebben át tudhat venni. A fejlesztő kap egy ellenmotivációt is, miközben önmagában is nehéz téma a "hogyan fejlesszünk korrekten..."
Sajnos annyira görény meccsek tudnak menni a háttérben, egyéni partikuláris üzleti érdekek mentén, hogy ha nem is fogadja el ezt az ember, a motivációkatt azért könnyű érzékelni.
Én azt mondom a "szenvedő" szemszögből is, hogy így NEM szabad versenyelőnyt kovácsolni, hiába ez a nehezebb út. Megfordítva, ha csak így lehet érvényesülni, az nem sok jót ígér a jövőre nézvést.
Végül a Lean Poker kapcsán: a Lean Poker nem arra tanít meg hogyan legyél üzletileg sikeres, hanem arra, hogyan segítheted az üzleti oldalt a gyors és hatékony döntés hozásban a Lean Startup es a Continuous Deployment eszközeivel. Ez egy abszolút szakmai kiválóságról szóló történet, és csupán egy eszközt ad a fejlesztők kezébe, amit aztán vagy ki tud használni az üzleti oldal megfelelően, vagy nem.
VálaszTörlésEgyébiránt épp holnap lesz egy esemény, ha van kedved gyere el. :)
Huh... meglepően hosszú lett ez a comment :) Remélem nem bánod, és nagyon várom a viszont válaszod. :)
Ördög Rafael
Köszönöm a kommenteket, kiegészítéseket! Szerintem komment-csúcsot döntöttünk pár óra alatt, itt a - mondjuk rendesen eldugott - blogomon :)
Törlés