Joel on Software

Joel on Software   Joel ukol sa Software

 

Ibang artikulong "Joel On Software" na nasa Filipino

Ibang artikulong "Joel On Software" na nasa Ingles

Iemail ang may akda (sa Ingles lamang)

 

Fire And Motion


Ni Joel Spolsky
Glenn Gamboa and Cathy Victor
Inedit ni Val J. Gonzales
Ika-6 ng Enero, 2002

Minsan, wala talaga akong matapos-tapos na trabaho.

Oo nga, papasok ako ng opisina, kakalat-kalat, nagche-check ng email bawat sampung segundo, nagbabasa sa web, o kaya gumagawa ng kahit ano tulad ng pagbabayad ng American Express na bill. Pero, ang pagbabalik at magaganahan ulit sa pagco-code ay parang ayaw mangyari.

Tetris

Itong mga panahon ng di pagiging produktibo ay kadalasang tumatagal ng isa o dalawang araw. Ngunit mayroong mga panahon sa aking career bilang developer na lumilipas ang ilang linggo na wala akong natatapos. Sabi nga nila, wala ako sa daloy. Wala ako sa zone. Wala ako kahit saan.

Lahat naman ay tinotopak; ang ibang tao ay katamtaman lamang, ang iba ay medyo malala at nagiging sanhi ng kanilang pagiging walang silbi. At ang mga panahon ng hindi pagiging produktibo ay maaayon mo sa mga madidilim na mood.

Naiisip ko tuloy yung mga mananaliksik na nagsasabing hindi kayang kontrolin ng mga tao ang kanilang pagkamatakaw, kaya lahat ng balak para magdiyeta ay tinatayang maging temporaryo lamang at sigurado ring babalik sila sa dating timbang. Siguro bilang isang software developer, hindi ko rin puwedeng kontrolin ang panahon kung kailan ako magiging produktibo, at kailangan ko lang tanggapin at paghaluin ang mga mababagal at mabibilis na panahon at umaasang umabot sa hustong bilang ng code para hindi ako mawalan ng trabaho.

 

 

Go read The Onion for a while.

 

 

Bilang isang developer, naloloko ako dahil ako ay karaniwang masipag sa pagco-code dalawa o tatlong oras araw-araw. Noong nagkaroon ako ng summer internship sa Microsoft, isa sa mga kasamahan ko ay nagsabing siya ay nagtatrabaho lamang umpisa 12 hanggang 5 araw-araw. Limang oras, bawasan mo ng pananghalian, at mahal pa rin sya ng kanyang grupo dahil kaya pa rin niyang gumawa ng higit pa sa karaniwan. Natuklasan ko na may katotohanan ang ganoong bagay. Nakukunsiyensya ako kapag nakikita ko kung gaano kahirap magtrabaho ang lahat, samantalang dalawa o tatlo lamang ang dekalidad na oras ko at natuturing pa ring isa ako sa mga pinakaproduktibong miyembro ng team. Iyon siguro ang dahilan kung bakit pinagpilitan ng Peopleware at XP na tanggalin ang overtime at striktong ilagay sa 40 oras ng pagtatrabaho lang bawat linggo. Ginawa nila ito na panatag sa kaalamang hindi ito makababawas sa output ng team.

Ngunit hindi yung mga araw na may ginagawa ako sa dalawang oras lang ng trabaho ang ikinababahala ko. Kungdi, yung mga araw na wala akong nagagawa na kahit ano man lang.

Pinag-isipan ko na rin ito nang madalas. Pilit kong inaalala kung kailan ako may pinakamaraming nagawa sa aking buong career. Siguro, ito ay noong inilipat ako ng Microsoft sa isang napakaganda at magarang na bagong opisina na may malalaking bintana na nakatapat sa isang magandang courtyard na yari sa bato at hitik sa namumulaklak na mga puno ng cherry. Lahat ay nagki-click. Ilang buwan na na ako ay tuloy-tuloy sa pagtatrabaho para mailabas ang detalyadong specifications para sa Excel Basic -- isang mala-monumentong tambak ng papel na nagsasaad ng mga detalyeng sumasakop ng malahiganteng object model at programming environment. Talagang walang makakapigil sa akin. Noong pinapunta ako sa Boston para sa MacWorld, nagdala ako ng laptop at isinulat ang Windows class nang nakaupo sa isang terrace sa HBS.

Kapag nasa flow ka ay hindi na mahirap na ituloy ito. Marami sa mga araw ko ay ganito: (1) papasok sa trabaho (2) check ng email, basa sa web, atbp. (3) mananghalian muna bago magtrabaho (4) babalik mula sa panananghalian (5) check ng email, basa sa web, atbp. (6) magdesisyong magsisimula na (7) check ng email, basa sa web, atbp. (8) magdesisyon ulit na kailangan ko na talagang magumpisa (9) magbukas ng sinusumpang editor at (10) magsulat ng code ng walang-tigil hanggang sa hindi ko na namamalayan na 7:30 na pala ng gabi.

bike tripSa pagitan ng step 8 at step 9 ay tila may bug, dahil hindi ko parating nalalampasan ang bangin na iyon. Para sa akin, ang pagsisimula lang ang mahirap na gawin. Ang bagay na hindi gumagalaw ay mananatiling hindi gumagalaw. May di kapani-paniwalang kabigatan sa utak ko na ang hirap pagulungin, pero simulang mapagulong na ito nang buong-bilis, hindi na mahirap panatilihing gumagalaw ito. Tulad ng isang bisikletang inihanda para sa malayong bike trip – sa unang paggamit ng bisikletang suot ang lahat ng mga gears, ang hirap paniwalaan kung gaano kahirap pagulungin ito, pero pag nasimulan nang gumulong, ang pakiramdam ay sing-dali ng parang walang dalang kahit anong gamit.

Ito siguro ang susi sa pagiging produktibo: ang makapag-umpisa. Siguro kapag ang pair programming ay gumana, ito ay gumana kasi kapag nag-schedule ka ng pair programming session kasama ang iyong kapareha, napupuwersa niyo ang isa’t-isa na magsimula.

Joel in the ArmyNoong ako ay isang Israeli paratrooper pa, isang heneral ang bumisita upang magbigay ng maliit na talumpati tungkol sa stratehiya. Sa mga labanan ng hukbong-katihan, ang sabi niya sa amin, isa lang ang stratehiya: Fire And Motion. Kumikilos ka palapit sa kalaban habang nagpapaputok ng iyong sandata. Ang pagpapaputok ay nagpupuwersa sa kanya na manatiling nakababa ang kanyang ulo para di ka niya mapapaputukan. (Iyon ang ibig sabihin ng mga sundalo kapag sumisigaw sila ng “cover me.” Ibig sabihin, “paputukan ang ating kalaban para siya ay dumapa at di makapagpaputok sa akin habang ako ay patawid sa kalyeng ito, dito.” Epektibo ito.) Ang pagkilos ay makakatulong sa iyo sa pagsakop ng teritoryo at makalapit sa kalaban, kung saan ang mga pagpapaputok naman ay mas malamang na makatama sa target. Kung hindi ka kumikilos, ang kalaban ang nakakapagdesisyon kung ano ang mangyayari. Hindi ito maganda. Kung di ka magpapaputok, ang kalaban ang magpapaputok sa iyo. Hindi ka na makakagalaw.

Naalala ko ito sa mahabang panahon. Napansin kong halos lahat ng klase ng stratehiyang pangmilitar, mula sa mga dogfights ng hukbong panghimpapawid hanggang sa malawakang galaw-pandagat, ay base sa ideya ng Fire And Motion. Inabot pa ako ng labinlimang taon para matanto na ang prinsipyo ng Fire And Motion ay ayon din sa pamumuhay. Kailangan mong umusad ng paunti-unti araw-araw. Hindi na bale kung ang code mo ay walang kuwenta o sira-sira at walang may gusto nito. Kung ikaw ay umuusad, nagsusulat ng code at patuloy sa pag-aayos ng mga sira, ang oras ay nasa panig mo. Maghanda ka kapag tumira sa iyo ang kakompetensiya mo. Pinupuwersa ka lang ba nilang gumanti sa mga tira nila para di ka makausad?

HailstormSOAPRDFLocked In The TrunkIsipin ang kasaysayan ng stratehiya ng data access na nagmula sa Microsoft. ODBC, RDO, DAO, ADO, OLEDB, ngayon ADO.NET – Lahat Bago! Ang mga ito ba ay technological imperatives? Ang resulta ng inutil na design group na kailangan magimbento muli ng data access taon-taon? (Iyon nga yata iyon sa katunayan.) Ngunit ang panghuling resulta ay cover fire lamang. Wala nang mapagpipilian ang kakompetensiya kundi ang gumastos ng lahat ng kanilang oras sa pagpo-port at paghahabol, oras na di nila magagamit sa paggawa ng mga bagong features. Tingnan sa malapitan ang software landscape. Ang mga kumpanyang maaayos ang takbo ay yung may pinakamaliit na pagtitiwala sa mga malalaking kumpanya at hindi nangangailangang gumastos ng lahat ng kanilang cycles sa paghahabol at pagsasagawang-muli at pagaayos ng mga bugs na lumalabas lamang sa Windows XP. Ang mga kumpanyang nadadapa ay yung mga gumagamit ng napakaraming oras sa pagbabasa ng mga dahon ng tsaa upang maintindihan ang direksyon sa kinabukasan ng Microsoft. Ang mga tao ay nagaalala tungkol sa .NET at nagdesisyong ulitin ang pagsusulat ng kanilang buong architecture para sa .NET dahil sa iniisiip nilang kinakailangan ito. Tinitira lang kayo ng Microsoft, at ito ay cover fire lamang para sila ay makausad at ikaw ay hindi. Ganyan kung paano ang nilalaro ang isang laro, Bubby. Ikaw ba susuporta sa Hailstorm? SOAP? RDF? Ikaw ba ay nagsusuporta nito dahil kailangan ng mga customer mo, o dahil may tumitira lang sa iyo at kailangan mong sagutin? Ang mga sales team ng malalaking kumpanya ay nakakaintindi ng cover fire. Pumupunta sila sa kanilang mga customer at nagsasabing, “Ok, di niyo kailangang bumili sa amin. Bumili kayo sa pinakamahusay na vendor pero siguruhin niyong makakuha kayo ng produktong sumusuporta ng XML / SOAP / CDE / J2EE kasi kung hindi, kayo ay Locked In The Trunk.” Kapag ang maliliit na kumpanya ay sumubok nang magbenta sa account na iyon, lahat ng maririnig nila ay mga masunuring CTOs na parang mga loro na “Mayroon ba kayong J2EE?” At kakailanganin nilang mag-aksaya ng lahat ng kanilang oras sa pagbubuo sa J2EE kahit di naman ito talagang bumebenta, at di sila nabibigyan ng oportunidad na maiba ang kanilang mga sarili. Checkbox feature ito – ginagawa mo siya dahil kailangan mo ang checkbox na nagsasabing mayroon kayo nito, pero wala naman gagamit o nangangailangan nito. At ito ay cover fire.

Fire and Motion, para sa mga maliliit na kumpanyang tulad ng sa akin ay nangangahulugan ng dalawang bagay. Kailangang nasa panig mo ang oras, at kailangang umuusad ka araw-araw. Sa kalaunan ay mananalo ka rin. Ang natapos ko lang kahapon ay ang mapaganda ang mga kulay sa FogBUGZ ng kaunti. Ok lang iyon. Paganda naman na ito ng paganda sa lahat ng oras. Araw-araw, ang software namin ay paganda na ng paganda at parami na ng parami ang aming customers at iyon naman ang importante. Hanggang ang kumpanya namin ay di pa sinlaki ng Oracle, hindi pa namin kailangang isipin ang mga engrandeng stratehiya. Kailangan lang naming pumasok tuwing umaga at magbukas ng editor.

It's getting better all the time... o/~



Ang artikulong ito ay orihinal na lumalabas sa Ingles sa ngalang Fire and Motion  

Si Joel Spolsky ang nagtatag ng Fog Creek Software, isang maliit na kumpanya ng sofware sa New York City. Siya ay nagtapos sa Yale University at nagtrabaho bilang programmer at manager sa Microsoft, Viacom, at Juno.


Ang mga nilalaman ng mga pahinang ito ay kumakatawan sa opinyon ng isang tao.
Ang lahat ng nilalaman ay Copyright ©1999-2005 ni Joel Spolsky. Taglay ang lahat ng karapatan sa pagmamay-ari.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky