No adivinis, mesura

Escrit per Aaloy a 24 de February , 2008 a les 5:58 p.m.

A l'hora de fer estimacions de projectes una de les regles bàsiques que hi ha és que si existeix algun tipus de dada mesurable és millor això que res, i que és millor tenir una dada objectiva i reproduïble que tirar d'arts adivinatòries.

Això és aplicable també a altres àmbits de la programació: en lloc de dir "aquest algoritme crec que millora el rendiment" mesurem els seus efectes abans i després, sols d'aquesta manera podrem avaluar objectivament les millores que tenim.

En lloc de dir "el rendiment en producció serà millor", comprovem-ho, agafem-ne mostres i facem extrapolacions. Comprovem els canvis que feim quan posem cachés, optimitzam la base de dades, augmentam la memòria del sistema i documentem-ho tot.

La informàtica és una ciència i com a tal les afirmacions si no són demostrables i reproduïbles sols tenen sols el valor que els vulgui atribuir cada un segons la solvència de la persona que les fa. Si les afirmacions van acompanyades de mesures i dades, ja no és cosa de creure o no, és cosa de comprovar. Potser per això a tots ens agraden tant els benchmarks.

1 comentari, 0 trackbacks (URL) , Tags: Gestió de projectes

Integració contínua

Escrit per Aaloy a 10 de February , 2008 a les 5:50 p.m.

Recentment he estat fent un poc de recerca per veure com podia aplicar els conceptes d'integració contínua als nostres projectes. El conjunt d'aplicacions que tenim ha anat creixent al llarg del temps i les dependències entre les llibreries i les aplicacions també ho ha fet.

La idea de la integració contínua és que hi ha un mecanisme automàtic que recull les actualitzacions dels diferents repositoris de control de versions que es tenguin i aplica els tests d'unitat per comprovar que tot funcioni i que els tets passen. D'aquesta manera, i si s'han fet els tests, podem minimitzar l'impacte d'un canvi d'una llibreria en les aplicacions, és a dir, si pel que sigui canviam una llibreria i els canvis impacten a una aplicació de manera no prevista, quan construïm l'aplicació no passarà els tests.

El programari d'integració contínua permet seguir els tests, treure'n estadístiques i veure manera integrada què és el que ha fallat o comprovar que tot ha anat bé. A més es pot utilitzar el programari per a la construcció de l'aplicació i el seu desplegament als entorns de proves. Fet i fet, aquest tipus de coses es poden fer molt bé amb scripts i ens asseguram que en tot moment tenim la nostra aplicació a punt.

En entorns on hi ha molta gent, la integració continua garanteix que si algú "peta" l'aplicació amb commit que no passa els tests, aquest fet es descobrirà prest i es podrà minimitzar el seu impacte. La majoria de sistemes que he avaluat a més permeten a més dels tests unitaris, passar tests al codi font per intentar detectar errors, veure que se segueixen les regles d'estil, etc.

Per a les meves necessitats volia que el sistema d'integració contínua fos capaç de fer feina amb Java (la majoria ho compleixen) però que a més pogués passar els tests de Python i que en general pogués fer des de la construcció de l'aplicació, passar els tests i fer-ne el desplegament.

El que més m'ha agradat per ara és un sistema anomenat Hudson. Hudson és una aplicació recent, feta en Java, fàcil de desplegar i de fer anar. La interfície està molt cuidada i té tot el que necessit per començar. A més hi ha un article de com fer la integració per Python, que m'ha anat molt bé per començar.

Hi ha moltes més alternatives, a mi Hudson me va molt bé perquè té tot el que necessit per aquesta etapa del desenvolupament i és prou extensible com per a que pugui cobrir les nostres necessitats del futur proper. Hi ha altres sistemes a on triar, la gent de Confluence n'ha fet una taula comparativa. Mirau i comparau, però si teniu les mateixes necessitas que jo, no deixeu de fer una ullada al Hudson.

0 comentaris, 0 trackbacks (URL) , Tags: Java Gestió de projectes

Projecte mascota: NDD

Escrit per Aaloy a 07 de December , 2007 a les 9:15 p.m.

Hi ha uns tipus de projectes, normalment petits, que serveixen per provar nous conceptes i idees, que els anglosaxons, sempre tan ocurrents amb els noms, anomenen projectes mascota: els pet projects.

Aquest tipus de projectes estan molt lligats als programadors que els fan, se'ls agafa "carinyo", a força de bregar amb ells provant noves idees. Els pobres però, també solen ser un conjunt de pegats, ja que no es caracteritzen per una arquitectura ben definida i elegant, sinó per ser un conjunt de proves de concepte i de noves rutines que el programador vol provar.

Aquests darrers dies he posat en marxa el meu pet project: a partir de la necessitat de refer una web he començat a desenvolupar el que serà el nou lloc web de No Diguis Dois. Té tot allò que el caracteritza per ser un projecte mascota:

• No hi ha implicació econòmica, la família és la família.
• Es fa a hores lliures
• Hi vaig provant tot el que se m'acud :)

La idea és acabar amb un lloc web on el grup pugui posar la seva biografia, cançons, fotografies i mantenir als fans al tanto de les seves actuacions.

El projecte correrà damunt Django, bé de fet ja corre, però sols a la meva màquina per ara ja que s'han de pujar molts continguts i m'ha servit per provar tot un grapat de pluguins i idees:

• Photologue: és una aplicació Django molt senzilla que s'integra dins l'administrador i que ens permet mantenir galeries de fotos. L'he adaptada un poc per a que estigui en català i per a que s'adapti a les meves necessitats, però m'ha estalviat molta feina, ja que tot el manteniment i les plantilles venen donades.
• jcarousel: Una vegada ja tenim les fotos convé presentar-les bé. Jcarousel és un afegitó per jQuery que ens permet mostrar galeries de fotos. Com que a més volia mostrar la foto en gran, he optat per l'estàndard
• ThickBox : No hi ha prou lloances per aquest afegitó de jQuery que és cada dia millor. En dues potades tenia connectada la galeria de jcarousel amb la presentació del ThickBox. L'exemple del jcarousel ha fet més nosa que servei ja que està molt lligat a mostrar sols una galeria, però sigui com sigui ara puc mostar diverses galeries de fotos i quan se'ns selecciona una passar a la presentació de ThickBox.
• He provat els inclusion tags de Django. Una virgueria de fa poc. El problema era que volia mostrar a cada plana contingut dinàmic i a la mateix vegada no perdre la potència de les vistes genèriques. Els inclusion tags permeten definir en dues potades tags per a la nostra aplilcació, de manera que ara tenc un {% show_components %} com a tag que em permet generar sempre que vulgui la llista de components. Això m'ha permès treballar amb sols amb una plantilla i que totes les altres n'heretin, fins i tot les vistes genèriques i disminuir l'acoblament de les aplicacions com photologue de l'aplicació que he generada per la gestió del lloc web de No Diguis Dois.
• També he fet servir el nou tag per les cachés de Django. Aquest tag ens permet definir una caché sols per un tros de la pàgina web. En el meu cas l'he fet servir per mantenir els menús, part dels quals es genera dinàmicament. El tema de les cachés en Django està força ben aconseguit, es pot cachejar part de la plana, la plana sencera, les dades, o qualsevol cosa que vulguem, ja que tenim accés a l'API, i no tan sols això, sinó triar si volem fer servir la memòria, el sistema de fitxer, la base de dades o el memcached per a gestionar-la.

Encara em queden força coses més a provar, com l'edició en línia dels continguts, però no sé si serà per aquesta versió. Ara els plans són sortir en quant tinguem llests els continguts i netejar un poc el codi i pujar-ho a un repositori subversion public, per si algun altre grup de rock ho pot aprofitar.

Supòs que la web es llançarà poc abans del nou disc, i esper tenir el codi prou netejat com per a poder-ho publicar en condicions. És el que té un pet project, que a la que et descuides te mossega els calçons.

0 comentaris, 0 trackbacks (URL) , Tags: Gestió de projectes

L’analista

Escrit per Aaloy a 25 de November , 2007 a les 6:32 p.m.

Tret del llibre Software requirements,

L'analista és la persona que ajuda als qui han demanat el projecte [1] a trobar la diferència entre el que ells diuen que volen i el que realment necessiten.

[1] stakeholders a l'original

M'ha feta gràcia la definició perquè és quelcom que sovint és perd al rol d'analista. L'analista ha de poder dir la seva en el projecte, proposar solucions, millores i expressar sense por el perquè troba que el que s'està demanant no funcionarà, o no és necessari.

Encara que se pugui dir que el client sempre té raó, si duim aquesta frase a les seves darreres conseqüències en el desenvolupament de programari, estarem pervertint la feina de l'analista.

És potser el mateix que quan un demana un disseny web i li diu al dissenyador des de com vol el format, les fotos, els colors i la tipografia. Llavors per a què vols un dissenyador web?

Pel que es veu aquest tipus de situacions no és sols pròpia d'analistes o dissenyadors web. Parlant amb un arquitecte em deia que té clients que ja li venen amb els plànols fets i que no atenen a raons, són els que solen acabar amb el bany aferrat a la cuina. També vaig viure una situació semblant amb un interiorista, el client li deia com ho volia tot, col·locació, llums, decoració, fins que l'home l'hi va tenir que dir que aquells temes eren precisament la seva feina.

Potser ens ho tendríem que plantejar de tant en tant allò de dir: "escolta, això és la meva feina, si la vols fer tu endavant però després també t'has de responsabilitzar dels resultats".

5 comentaris, 0 trackbacks (URL) , Tags: Gestió de projectes

Què torbes a corregir un error de producció?

Escrit per Aaloy a 18 de November , 2007 a les 4:34 p.m.

Trobar un error al teu codi és un emprenyo. Poder començar la depuració en 30 segons, trobar l'error 2 minuts, pujar-ho al subversion i actualitzar la versió de producció de manera que als 5 minuts d'haver detectat l'error estigui corregit no té preu.

Això és el gran avantatge dels llenguatges d'script, que el temps que passa des de que trobes un error a poder-ho corregir és molt curt (llevat d'excepcions amb errors difícils de trobar i depurar, clar). Curt perquè normalment posar en marxa l'entorn de desenvolupament no duu més que uns pocs segons i ja pots començar a depurar.

Si tot està ben organitzat el codi estarà a un repositori subvesion i l'entorn de producció no serà sinó un client de subversion, de manera que fer una actualització una vegada trobat un error que no afecti a la base de dades, és bàsicament

• svn ci
• ssh al servidor
• svn update

L'experiència amb Java és que ja directament és necessiten els 5 minuts sols per posar en marxa l'entorn, 5 o 10 minuts més per depurar i si hi ha sort i sols era un error de jsp 2 mintus més actualizar i forçar la compilació del jsp per a que el proper usuari no vegi en enlentiment en la pàgina. Normalment més del doble per a corregir el mateix tipus d'error.

Si la correcció de l'error implica canviar codi que no sigui jsp o html les diferències són encara més grans i sovint pot implicar tenir que reiniciar el servidor, la qual cosa ens obligarà a tenir sempre dos servidors balancejats si no volem tenir als usuaris aturats durant 5 minuts. L'Apache es recarrega en segons, i tot i que sempre és bo tenir-ho tot duplicat i balancejat, la necessitat no es tan forta com en el cas anterior.

Personalment m'agrada molt Java i les llibreries que s'han desenvolupat en aquest llenguatge, però si el nostre negoci depèn del ràpid que puguem actualitzar la nostra aplicació web hi ha entorns i llenguatges amb més avantatges que Java o .Net.

4 comentaris, 0 trackbacks (URL) , Tags: Gestió de projectes

Llegir codi

Escrit per Aaloy a 09 de September , 2007 a les 1:36 p.m.

Aquests darrers dies estic llegint el llibre wxPython in Action de Robin Dunn i Noel Rappin. El llibre és un tutorial de com escriure aplicacions fent servir la llibreria wxPython i com fer servir cada component (widget) que la llibreria inclou.

En el que és la explicació de cada component i els exemples hi ha una gran quantitat de llistats de codi font i comentaris damunt aquests llistats. Això m'ha fet recordar el capítol en que Glass tracta la importància de poder llegir codi. Diu, i estic completament d'acord, que a programar no se n'aprèn sols coneixent la sintaxi del llenguatge de programació, sinó també escrivint programes i sobretot llegint codi que ha escrit altra gent, i que aquesta capacitat de llegir codi s'hauria de cultivar més a les universitats i escoles tècniques.

Sense aquesta capacitat de llegir codi d'altres també ens trobam que llegir tutorials com el de wxPython es fa pràcticament impossible, si no som capaços de llegir el codi, interpretar mentalment que fa i imaginar-nos la sortida, no ens queda més remei que picar el codi i executar-ho per aprendre, la qual cosa fa que l'avanç en el domini de la llibreria sigui molt més lent.

Ser capaç de llegir el codi d'un altre ens permet aprendre noves tècniques que potser no estan explicades en el llibre, normalment perquè no és el seu objectiu, i ens permet la lectura a llocs allunyats de l'ordinador: al sofà, a la fresca a la terrassa,...

El programari lliure ens permet llegir codi que ha fet altre gent, veure com funciona, aprendre noves tècniques o veure el que s'ha fet malament o maneres de millorar-ho. Aquesta capacitat és fonamental a l'hora d'aprendre el funcionament d'una nova llibreria, de fer inspeccions de codi abans de posar en test un programa, o a l'hora de depurar o modificar codi que ha fet una altra persona.

Les èpoques del programador solitari que ho feia tot han ja queden lluny. El més normal actualment és que els programes és desenvolupin en equip i la gent acostumada a llegir codi ho té molt més fàcil per a adaptar-se a la feina en equip.

Si una persona sols ha fet feina fent servir programari tancat no haurà tingut l'oportunitat d'aprendre el que significa poder veure codi de tercers i per tant la seva evolució com a programador serà menor que aquells que estan acostumats, bé per necessitat o bé per convicció, a llegir el codi font d'altres persones.

Com vaig sentir a dir a Ricardo Gali a una conferència de Bulma, el codi és una font en sí mateixa per emmagatzemar i transmetre coneixement.En els cas dels programadors això també es tradueix en possibilitat d'aprenentatge i amb minimitzar el nombre d'errors i tasques de depuració.

1 comentari, 0 trackbacks (URL) , Tags: Llibres i revistes Gestió de projectes

Software project survival guide

Escrit per Aaloy a 14 de August , 2007 a les 8:26 p.m.

Titol: Software project survival guide Autor: Steve McConnell Editorial: Microsoft Press ISBN-13: 978-1-57231-621-8 Pàgines: 288

Sofware project survival guide és un llibre damunt la gestió de projectes en general, no entra a explicar cap metodologia concreta, sinó que és un conjunt de consells i llistes de coses a comprovar en els projectes, però sense mullar-se ni anar al detall.

Al contrari d'altres llibres de McConnell he de dir que aquest no està a l'alçada, pareix més un llibre d'aquells que es fan per pagar factures i que s'aprofita de la fama dels que l'han precedit.

Tot i això he ha coses aprofitables: alguns "survival checks", una mena de llistat de coses a tenir en compte o a fer per dur endavant el projecte, i és un recordatori del cicle de vida d'un projecte.

L'estil tampoc és el que acostuma McConnell, molt més amè de llegir. Aquest m'ha costat acabar-ho, ja que li passaven per davant tots els altres llibres que he anat comprant aquesta temporada.

En el que fa a l'edició, el llibre té una edició amb una tipografia de cos dotze amb molt de marge per tot i amb un doble espai generós. Amb una altra tipus d'edició el llibre no passaria del centenar de pàgines.

En definitiva, si us ho regalen o el trobau de segona ma agafeu-lo, però no val la trentena d'euros que costà.

0 comentaris, 0 trackbacks (URL) , Tags: Gestió de projectes

Filtres de selecció de personal

Escrit per Aaloy a 13 de August , 2007 a les 10:12 p.m.

Trobar bona gent és difícil i trobar-la que a més es pugui integrar en un equip ja format encara ho és més. A les respostes d'anuncis de feina s'hi pot presentar molta gent i en poques preguntes sovint s'ha d'intentar esbrinar si la persona que tens al davant serà bona tècnicament i a la vegada la seva manera d'entendre la feina serà per l'estil de la que hi a al grup.

Encara que soni molt a tòpic hi ha una sèrie de regles heurístiques que quan parlam de programació web ajuden a fer-se una idea d'ambdues coses:

• Adreça de correu amb domini propi : suma un punt. Per mi vol dir que al manco hi ha una preocupació per cercar-se la vida i potser haver donat d'alta un domini. Tenir un domini implica que també es pot cotorrejar abans de la selecció i veure quins temes preocupen al possible candidat o candidata.
• Adreça de correu amb Hotmail: resta dos punts. Sovint també vol dir que estàs engantxa al messenger i/o que no ets capaç de diferenciar el tenir un correu per usos lúdics d'un per usos professionals. Serveix per a diferenciar la gent que el primer que intentarà fer és posar-se el Messenger.
• Edició d'HTML. Si el sols es sap fer servir el Dreamweaver resta de cop 2 punts. Implica que d'entrada es tendran problemes quan es tracti de modificar planes webs fetes a troços, pràctica habitual en la programació web. Si utilitza un editor amb resaltat de sintaxi suma un, si a més sap fer servi el vi/vim suma dos punts. Si no ha fet mai una plana web resta cinc punts de cop.
• Coneixements de CSS. Si ha maquetat pàgines amb CSS i sap perquè ho ha fet suma 2 punts. Si no sap perquè ho ha fet sols en suma un. Si no sap què és resta un punt. Tenir coneixements de CSS ajuda a saber el que es podrà fer en la pàgina.
• Coneixements de Javascript. Si els sap fer servir mitjanament suma un punt, si a més coneix alguna llibreries de les típiques suma un altre punt. Si sols coneix el que posa el Dreamweaver lleva un punt. Tot es pot aprendre, però si un ja té experiència en Javascript vol dir que realment ha programat per la web. Si a més abans ha dit que utilitzava un editor "per programadors" començarà a agradar-me força.
• Si sap què és l'arbre DOM suma un punt. Si no ho sap i ha dit que ha manejat força Javascript ens haurem de plantejar sèriament si ha està decorant el currículum.
• Si sap què són els estàndards W3C suma un punt.
• Si sap que és un sistema de control de versions suma un punt, si a més l'ha fet servir suma un punt més.
• Utilitzar Linux suma dos punts. Per una part vol dir que encaixarà millor en el grup, però objectivament vol dir que serà capaç de modificar una plana que no està al servidor local, estarà acostumant a que els noms dels arxius són diferents en majúscules i en minúscules, sabrà què és l'UTF-8, etc. I sobretot demostra ganes de fer coses i de no conformar-se amb el que fa la gran majoria.
• Utilitzar Firefox com a eina de desenvolupament. Suma un punt. En suma un altre si coneix dos plugins indispensables per al desenvolupament web.
• Conèixer un llenguatge de programació d'script suma un punt. Si aquest es Python o Perl en suma un altra. PHP o Ruby no puntuen més. Un perquè a un que fa programació web se li suposa un mínim coneixement de PHP i Ruby perquè no es pot distingir de si es fa per moda o per convenciment.
• Conèixer el patró MVC i saber-ho explicar suma un punt. El patró MVC s'ha convertit en omnipresent per la web i conèixer-lo i fer-ho servir indica que es una formació en programar pensant en la separació entre capes.
• Conèixer SQL suma un punt. No fer-ho en resta un. No puc concebre que algú faci webs dinàmiques i no tengui idea d'SQL.
• Conèixer els bastiments i llibreries utilitzades a l'empresa suma dos punts.
• Ser membre actiu de Bulma o algun LUG suma un punt. Indica que el candidat s'implica en el que fa i contribueix amb les seves aportacions.

Hem de dir que d'entrada el possible candidat ha de conèixer el bàsic que se li demana, és a dir, si l'oferta és per programador Java-J2ee, si ja no es sap cap de les dues coses doncs el més probable és que el seu currículum ja no passi pel filtre de RRHH. Si ho fa llavors ens trobam davant un currículum que pot ser vàlid o estar especialment decorat per l'ocasió.

Un currículum amb una puntuació d'entre 17 i 20 és algú que s'ho paga entrevistar amb més profunditat. Entre 13 i 16 convé fer-hi una ullada però no hi ha massa possibilitats així d'entrada, i si és menys que aquest valor doncs potser és millor no perdre-hi més temps.

Tant les opcions com les valoracions són elegides ad-hoc sabent d'entrada el tipus de gent que m'agrada i que potser encaixarà bé en el grup, empreses i grups distints poden tenir valoracions distintes. Segurament una persona amb una puntuació de 20 no encaixarà en un ambient poc dinàmic i que no tengui capacitat d'innovació.

4 comentaris, 0 trackbacks (URL) , Tags: Informàtica Java Gestió de projectes

Programar per menjar

Escrit per Aaloy a 12 de July , 2007 a les 10:22 p.m.

N'Enrique Dans es demana a un article ¿Alguien ha visto un programador? i en Ricardo Gali li diu que yo he vistos unos pocos. Particularment he de dir que jo sí que n'he vists de programadors i de bons, però com tot el que és excepcional un bé escàs i en el cas dels programadors he d'afegir que és un bé poc valorat.

A l'article d'Enrique Dans ens diu que el desenvolupament tecnològic d'Espanya s'està alentint perquè no hi ha bons programadors de PHP, Java, Python, Perl o RoR per a dur a terme els projectes d'Internet. Ho sento, no hi puc estar d'acord, els projectes d'Internet a més de pels programes i els programadors tenen un factor limitador que és el cost del hosting i de l'ampla de banda. Si comparam el que costa hostejar un projecte ambiciós a Espanya i ho comparam amb el que costa fer-ho a altres indrets veurem que el programador Espanyol ja no es planteja desenvolupar perquè tanmateix ja sap que les seves possibilitats de créixer són molt limitades, ja que ben aviat els costs pujaran per damunt dels guanys.

L'ampla de banda de les connexions domèstiques tampoc ajuda, la velocitat de pujada de les connexions ADSL fa rialles i el cost de més velocitat és prohibitiu. Sempre ens queda la solució de fer el hosting a països més barats, però això ja està penalitzant la velocitat d'accés si el negoci ho vols fer per començar al mercat Espanyol i perds el control que te donaria tenir els programes al teu propi datacenter, encara que aquest pugui ser tan petit com un servidor o dos col·locat al destpatx de casa. En aquest moments i amb les connexions actuals l'inversió necessària per tenir un grapat de servidors dedicats amb prou ampla de banda a Espanya, fa que els costs fixes siguin tan alts que cal pensar-s'ho molt a l'hora de montar un negoci tecnològic a l'estil del que ens tenen acostumats emprenedors americans.

Així doncs, l'endarreriment en noves tecnologies no és tant per l'absència de bons programadors, sinó que tot el teixit tecnològic que hi ha a la nostra societat o l'absència del mateix, fa que encara que aquests hi siguin, no es donin les condicions per a que prosperin. Empreses poc donades a la innovació, departaments d'I+D+I inexistents, costs de les comunicacions prohibitius, empreses que donen més importància a les aparences, a l'estar que al fer i una gran mancança de cultura informàtica en el que fa al desenvolupament de programari i a la gestió d'equips tècnics són tant o més responsables de l'endarreriment que patim.

Per una altra banda quan parlam de noves tecnologies al perfil del bon programador, del tècnic se li ha d'afegir la de la capacitat de treball en equip. Avui en dia i en projectes d'Internet és impensable dur a terme alguna cosa mitjanament grossa sense la col·laboració de programadors, dissenyadors i tècnics de sistemes. Trobar perfils compatibles ajuda moltíssim (de 3 a 10 vegades) al projecte i augmenta les possibilitat d'èxit, i això xoca amb processos de selecció basats en la força bruta, és a dir, en un "pongame aquí 20 tios que ...", el nombre no és tan important com la capacitat d'autocoordinació, la iniciativa i la capacitat tant individual com del conjunt.

Potser falten bons programadors, però també falten i molt empreses que vulguin bons programadors, fins i tot empreses que vulguin un equip de bons programadors i que entenguin el perquè una vegada un equip s'ha format i funciona s'ha d'intentar mantenir i evolucionar.

La tecnologia i el programari s'ha convertit en una part fonamental de les empreses, però la figura del programador enlloc d'estar cuidada està denostada. Els cursos per fascicles de "programar es fácil" no han ajudat gens a la valoració de la professió. La capacitat de fer mals programes és infinita, la capacitat de fer-los bé està sols a l'abast de la gent amb passió per la seva professió, una passió que el motiva i que el duu cada dia a superar-se, a fer millor les coses, a aprendre.

Sovint però el que trobam és el programador que programa per menjar. És l'antítesi del tipus de gent que fa que les tecnologies de la informació passin de les idees als fets. Programar per menjar implica dedicar-se a programar sols perquè és una feina on no et banyes quan plou, on un fa el que toca i fins a on li han dit i res més, sense plantejar-se si se podria fer millor, sense cercar avançar sinó tot el contrari, procurant que la feina que fa duri molt per tal de no haver d'aprendre coses noves.

Els programadors dels que parlen Enrique i Ricardo no programen per menjar, programen per viure. L'aspecte econòmic és important per viure però encara que tinguéssin que dedicar-se a altres feines per subsistir programarien.

Un bon programador ha de ser també inconformista, crític i perquè no un tant freaky. Crec que tot va lligat, l'inconformisme ens duu a cercar altres maneres de fer les coses, a pensar alternatives. El pensament crític ens ajuda a millorar i el freakisme ens fa part d'un club selecte, forma lligams i fa equip.

Bons programadors? En conec un grapat, però on són les empreses que tenen les condicions per a que aquests desenvolupin tot el seu potencial?

1 comentari, 0 trackbacks (URL) , Tags: Gestió de projectes