Aquesta setmana passada vaig llegir la tèsi de Rory Tulk "Software Testing Techniques, an Empirical Approach" de l'Universitat de Toronto (una vegada més gràcies a Jordi Cabot per publicar l'enllaç). La tesi es pot trobar via la plana de Rory o bé descarregàr-se-la directament.

Rory investiga damunt les capacitat de testeig segons el grau de maduresa tècnica de qui fa el testeig. La hipòtesi és que els tècnics més experimentats són millors testejadors que els juniors. És un treball que s'ho paga llegir per la pròpia estructura de la tesi i veure com s'ha conduit l'experiment.

Però el que més m'interessa del tema són les conclusions: l'experiència no té massa a veure amb el nombre d'errors trobats però sí que pareix que té a veure amb els tipus d'errors que es troben. Encara que el nombre de casos estudiats fa que les conclusions no siguin estadísticament significatives, sí que entronca en les pràctiques més o manco habituals de fer que sigui una persona diferent de la implicada en el projecte de desenvolupament la que provi els programes, ja que sovint descobreix errors que s'han passat per alt als desenvolupadors, que en teoria són més experimentats trobant-los.

D'aquí una possible conclusió seria que els equips de testeig i qualitat han d'estar formats tant per gent senior com per gent menys experimentada, de manera que es puguin complementar mútuament. Això vol dir, però que hi ha d'haver una rotació en els equips de testeig, ja que en cas contrari així con els juniors es vagin convertint en programadors experimentats tendran tendència a trobar uns tipus d'errors concrets, i no provar coses que d'altra manera, sense els condicionants de l'experiència provarien.

L'altra conclusió marginal interessant és el bon funcionament de la lectura del codi com a eina per a la detecció d'errors. Segons Karl E. Wiegers autor de Peer Reviews in Software un lector experimentat de codi pot arribar a caçar fins al 90% d'errors en el codi. Dins l'estudi de Rory precisament qui té la taxa de detecció d'errors més grans és una persona que va fer servir el mètode de llegir el codi per a detectar els errors.

Una lectura interessant i que convida a reflexionar, ja que comença a donar una base per a estudis posteriors. El testeig no és, com moltes branques del desenvolupament, una ciència exacta, però el que pareix clar és que els equips de testejadors han de ser diversos en la seva manera de veure les coses i que no basta una manera de testejar. I tot i això segur que quedaran errors sense caçar, per saber més o manco quants ja sols ens queda anar cap a mètriques estadístiques com les corbes S o les corbes de Rayleigh. El Software Mesasurement and Estimation de Lida M. Laird an Carol Brennan ten té un bon grapat de mètodes estadístics.

Com a conclusió addicional: convé registrar els tests que es fan, els errors que es detecten i estudiar-los, no com a via per a premiar els testejadors (el típic de condicionar un pagament d'objectius) o de penalitzar els desenvolupadors, sinó com a manera d'estudiar estadísticament els tipus d'errors que s'estan trobant i poder saber quan convé renovar par de l'equip de testeig. L'estar en un equip de testeig per exemple podria ser part de la carrera professional d'un programador.

Un link passat per Jordi Cabot al Twitter anomenat Asshole driven development em fa recordar el complexe que és la interacció humana en la gestió de projectes.

Quan més gran és una empresa més possibilitats hi ha de veure's reflexat en una de les definicions que fa Scott Berkun, més que res per una qüestió de probabilitats. Personalment m'he trobat molt amb el Cover Your Ass Engineering (CYAE) ja que és el típic que es presenta quan enfrontes una solució de codi obert amb una solució propietària a un gestor més preocupat pel seu lloc de feina i cobrir-se les esquenes si hi ha el mínim risc, que per les possibilitats de benefici real de l'empresa.

L'_Asshole Driven development (ADD)_ realment m'ho he trobat poques vegades, més que res perquè quan m'he trobat en situacions on els tirs anaven cap aquí he preferit anar cap a opcions alternatives. Ja sabeu que em costa molt combregar amb rodes de molí, i l'ADD és precisament això: fer les coses no perquè són tècnicament correctes o millors per l'empresa, sinó perquè qui mana (que no és normalment l'amo de l'empresa) diu que s'ha de fer ell que ell diu i punt.

El que sí m'he troba sovint són dos estils d'entendre la gestió de projectes i la pròpia feina del cap de projecte. M'explicaré:

Per mi l'objectiu d'un projecte informàtic és sempre aportar valor a l'empresa. És a dir hi ha d'haver un benefici mesurable en el projecte, ja sigui benefici en imatge, en menor temps de feina intern per fer les coses, en un major control o el millor de tot, un benefici real en termes de negoci.

Partint d'aquesta base entenc la feina d'un cap de projecte de desenvolupament com el d'aquella persona que s'ha d'encarregar de coordinar la feina, relacionar-se amb el client i sobre tot, de prendre decisions. L'important és estar focalitzat en que la feina surti i representi un benefici pel client i per això el cap de projecte ha d'eliminar els obstacles que es presentin per tal que la gent que fa feina en el projecte pugui fer la feina que millor sap fer.

Això vol dir no convocar a reunions multitudinàries als membres de l'equip quan aquestes no aporten res. És encarregar-se d'anar a parlar amb altres departaments, amb el negoci, dur el control administratiu del projecte, fer el reporting. És a dir, totes aquelles coses que formen part de la cerimònia del projecte i que mal duites poden impedir als membres "productius" fer la seva feina.

Amb aquesta filosofia entenc que el cap de projecte ha de posar tots els recursos a la seva disposició per dur bon terme el projecte. Si el programador té problemes amb una rutina o amb el llenguatge ha de mirar de solucionar-los, bé ell mateix o cercant algú que ho pugui fer. Alguna vegada m'han dit que donar suport als programadors no és la meva feina i n'estic en total desacord. La feina d'un cap de projecte és precisament aqueixa: donar suport, i si aquest suport significa resoldre un dubte de programació, depurar en conjunt un algorisme on algú s'ha quedat enrocat, s'ha de fer si es tenen els coneixements i l'oportunitat. Perquè per damunt de tot el cap de projecte està per eliminar obstacles i donar solucions. Si un projecte ha de sortir i no puc ajudar més que en dur els cafès doncs millor llevar-se d'enmig i demanar a la gent pel sucre que vol i si els vols sols o tallats.

L'altra estil de gestió és òbviament el contrari: reunions per pressionar la gent, reunions per repartir culpes i concentració del cap de projecte en la cerimònia, és a dir, gestionar concentrant-se amb el com i no amb l'objectiu final.

Perquè està clar que tot projecte pot fallar, per les causes que siguin. Però quan falla l'excusa no pot ser anar cap a un Cover Your Ass Engineering (CYAE) i establir mecanismes burocràtics i de control absurds per a que no tornin passar les coses, sinó cercar la causa de base del problema i solucionar-la de manera que afecti de manera mínima a la cerimònia del procés.

Si un programa falla perquè no s'ha pogut provar, la solució no és tenir que redactar un document a casa passi a producció on l'equip de programadors certifica que està bé, el testejador certifica que ha provat l'aplicació i el tècnic certifiqui que ha passat el pegat que li han dit; sinó demanar-se perquè no hi ha tests unitaris, perquè no hi ha (o han fallat) les integracions contínues. Potser el que ha fallat és que la gent no té prou formació per a realitzar bons tests. Massa cerimònia mata la creativitat i far perdre l'objectiu del projecte, formar a la gent fa millors professionals.

Tot són estils de gestió, jo sé el que m'agrada i intent posar en pràctica, adaptant l'estil de gestió al client, al projecte i a l'equip. Els programadors no són els curritos del cap de projecte de torn, és el cap de projecte el qui ha de fer feia pels tècnics i programadors i procurar que ells puguin fer la seva feina.

Ahir vespre me va pegar per instal·lar l'Ubuntu Netbook Remix al Dell Latitude 2100 que vaig comprar fa uns mesos.

No l'havia actualitzat de versió i vaig trobar que era una bona ocasió per provar tant la creació d'una distribució en un USB com la pròpia distribució Netbook, a veure si aprofitaria millor l'espai.

Amb la configuració de fàbrica i una vegada instal·lades les utilitats bàsiques de programació em quedàven uns 3 GB de disc lliure dels 16 GB. Això implica tenir que anar alerta amb els documents que es decarreguen, fer neteja de tant en tant del projectes, etc.

Tampoc era res greu. Quan un compra un Netbook ja ha de ser conscient amb un disc d'estat sòlid de 16 GB es tindran unes limitacions d'espai que no hi ha a discs de Tera en que surten ara alguns ordenadors de sobretaula. Per mi el Netbook representa la mobilitat, té un configuracio mínima per fer feina i em permet dur-ho a la motxilla carregant 3 kilos menys que amb l'altra portàtil. Una eina per a cada feina!

Així que dit i fet!

• Baixam la distribució Ubuntu Netbook Remix
• Posam un llapis USB (que formatejarem així que al tanto amb les dades que hi teniu).
• Executam el programa usb-creator-gtk, que ens demanarà l'ISO d'origen i l'USB de destí i formatejar l'USB destí. Ho feim i seleccionam la partició de l'USB. Nota mental: el diàleg de l'usb-creator es petit i no es veu la partició amb la qual cosa quedava seleccionat tot el disc i em deia que no hi havia espai lliure. Quan fas la instal·lació a les dues del vespre en el darrer que pensava jo era en redimensionar la finestra! :) Així que fora fer aquestes coses amb són.
• Anam al Netbook. En arrancar pitjarem F12 per entrar a la configuració i canviar l'ordre d'arrencada per a que agafi primer l'USB. En acabar hem de pensar en deixar-ho tot igual. En el meu cas perquè tenc a més una tarjeta SD de 4GB addicionals i no vull que perdi temps en arrancar cercant el sistema operatiu que ja sé que no hi és.
• Una vegada arrancat amb l'USB ja sols es cosa de dir-li que instal·li. Li deim que faci servir tot el disc (es perdran totes les dades!) i a esperar una estona.
• Quan acaba la instal·lació tornam a deixar la prioritat de dispositius d'arrancada amb el disc dur com a primera opció i realitzam un sudo apt-get dist-upgrade per deixar el sistema amb totes les actualitzacions i pegats.
• Després convé actualitzar els controladors de maquinari per a que ens vagi millor la tarja WIFI.
• Gairebé ja està. Sols configurar les aplicacions preferides i instal·lar vim, virtualevn per Python, Chrome, yolk, git, shutter i trapassar la configuració de Vim. Amb això ja tenc un entorn de feina més que complet.
• Com que el Dell 2100 té pantalla tàctil convé fer-ne la configuració. Cosa de cinc o deu segons tocant creuetes i després ja tindrem un entorn on les aplicacions es poden engegar amb el dit i amb 11 GB liures.

La distribució per ara i amb poc menys de 5 hores que duc amb ella pareix força usable amb la pantalla tàctil funciona molt millor que amb la versió de fàbrica de Dell. Això sí ens hem d'acostumar a la manera de presentar les aplicacions: totes surten a pantalla completa, que amb el poc espai que hi ha disponible tampoc és cap mala cosa, però es fa un poc estrany al principi.

Encara que faig servir distints editors i entorns integrats (IDE) per programar en Python i Django hi ha sempre la constant de retornar cap a Vim i gVim.

La cosa està però, en que per al desenvolupament normal no vull renunciar a un parell de coses que fan la vida més fàcil:

• Resaltat de sintaxi amb colors personalitzables i/o una paleta de colors còmoda per fer-hi feina.
• Autocompletat (dins cert límits, que això és un llenguatge dinàmic) i ajuda integrada.
• Plantilles per no haver d'escriure molt. Per exemple els shebangs, o els models de Django.
• Distints tipus de tabulació segons el llenguatge, quatre per Python, però 2 per HTML i Javascript.
• Possibilitat de tenir oberts molts arxius a la vegada i accedir-hi fàcilment
• Navegació pel sistema d'arxius integrada

I poca cosa més. Després quant més potent sigui l'editor millor, i per això Vim n'és de potent!! El problema és que ja m'agradaria poder fer servir amb agilitat un 20% de les seves capacitats.

En la meva recerca de l'editor perfecte he anat modificant el .vimrc i afegint plugins diversos, i configuracions que anat trobant d'aquí i d'allà. Per si a algú li va bé, he posat el meu .vimrc i .vim amb els plugins a l'appusedjango. Ja me contareu!

Eines per a la isntal·lació de plugins

Si feis un apt-get vim-addons obtindreu una petita utlitat que us permetrà veure quins plugins teniu instal·lats al vostres sistema i activar-los pel vostre usuari. En el meu cas tenc:

bufexplorer                 installed     
markdown-syntax             installed            
matchit                     installed            
python-indent               installed            
python_bike                 installed            
supertab                    installed            
surround                    installed            
taglist                     installed            
utl                         installed            
winmanager                  installed            
xmledit                     installed

En local (i instal·lats a mà) tenc també:

• ftplugin
• nerdtree_plugin
• snippetsEmu
• taglist
• mathit
• supertab
• vcssvn

Hi ha altres plugins interessants com el nerdcommenter i altres, però encara m'he d'anar acostumant al altres.

Referències

La veritat és que em costa dir d'on ho he tret tot, la configuració és una feina orgànica, he anat agafant coses d'aquí i d'allà, així que pos els darrers consultats.

• Llibre, tutorial de Vim
• pycopia
• vim-config-python-ide

Disclaimer: NO sóc cap expert amb vim, així que moltes coses van per assaig i error.

Download

• El subversion: http://code.google.com/p/appfusedjango/source/browse/#svn/trunk/myvim

• El .vimrc

• El .vim

Al svn trobareu un .vimrc que heu de posar al vostre home i un arxiu comprimit amb .vim que conté plugins, plantilles i demés, descomprimiu-lo també al vostre home.

No he de recordar la impirtància de fer còpies de seguretat de la configuració antiga abans de res, veritat?

Pels debianites i ubuntaires

Per a tenir l'entorn funcional necessitareu instal·lar

• sudo aptitude ctags
• sudo aptitude vim-addons-manager
• sudo aptitude vim-python (segons versions...)

comprovat per bibigeek (gràcies!) pels ubuntaires amb PPC com jo, no hi ha vim-python i convé recompilar vim amb suport per Python.

Esper que us sigui d'utilitat!

Entre lectures informàtiques i altres herbes aquests dies m'he estat llegint Nocturna, una història de vampirs i zombies de Guillermo del Toro y Chuck Hogan.

Al principi la novel·la comença amb poc ritme, però després de les cent primeres planes la cosa s'anima i quan l'acabes ja veus que la història quedarà incompleta, que potser és sols un començament.

La mà de Guillermo del Toro es nota en el desenvolupament de la història i la presentació dels personatges, tant que ben bé podría ser un guió.

Supòs que el llibre no serà mai considerat com una de les joies de la literatura però entretén.

Nocturna
Guillermo del Toro i Chuck Hogan
Círculo de Lectores
ISBN 978-84-672-3689-7

Avui he acabat de llegir The Medici Effect, un llibre que em va recomanar fa unes setmanes Greg Garrison, un de les persones amb més idees que m'he trobat fa temps.

The Medici Effect tracta de la innovació, dels camins que duen a les noves idees. De com la mescla de conceptes, experiències i gent dóna lloc a noves idees, a nous productes que trenquen amb tot el que hi havia fins al moment. Es creen nous negocis, nous camps d'investigació, noves empreses no de manera evolutiva sinó disruptiva, fruit d'una combinació de factors i de gent.

El llibre tracta de com poder conseguir aquest factor disruptiu, de com trobar el Frans Johansson, l'autor, anomena la intersecció. El punt de trobada on les corrents i les idees es mesclen i donen lloc a una cosa nova.

Johansson ens mostra amb exemples com distintes persones i empreses són conscients d'aquests tipus de combinacions i de com els cerquen activament en els seus negocis.

El llibre és prou interessant, motivador fins i tot. Alguns dels consells que dóna són prou bons. Tot i això les idees que presenta es poden resumir en pocs conceptes:

• Cerca la intersecció.
• Reconeix la innovació
• Assumeix el canvi i no tenguis por a trencar barreres i xarxes socials.
• Assumeix el risc

Amb això vull dir que és un llibre que es podria haver estalviat un 50% de les 190 planes de text. Sovint es fa repetitiu ens alguns exemples i es perd un poc per les bardisses a l'hora de focalitzar el tema.

En resum, un llibre interessant, que convé llegir, especialment si ja us heu convençut de que la innovació és una bona cosa, sou capaços de generar idees o simplement voleu una visió de com altres gestionen projectes i idees que canvien el món.

Fitxa Tècnica
The Medici Effect
Frans Johansson
Harvard Business Scholl Press
ISBN-13: 978-1-59139-186-9

L'autisme es caracteritza per una escassa interacció social, problemes en la comunicació verbal i no verbal, activitats i interessos greument limitats, inusuals i repetitiu. Viquipèdia

Aplicat a l'activitat laborar podem parlar de l'oficina autista, aquell entorn de treball en que les condicions ambientals, d'organització i de feina fan que la gent es retragui en ella mateix, minimitzant la comunicació i la interacció a nivells mínims, interessant-se sols pel que passa pel seu redol i intentant frenar i minimitzar qualsevol tipus de canvi.

Un dels símptomes de l'oficina autista és entrar i veure que molta gent té els auriculars posats i es sent el remor de la música sonant a les seves orelles. Això i un entorn renouer i amb una densitat de gent molt gran.

De Marco a Peopleware ja tracta el problema de la densitat de gent i la productivitat. Encara que una persona pugui fer feina en un espai reduït, posar molta gent mantenint la proporció d'espai fa que el renou i la sensació d'agobi augmentin. Suposem que una persona necessita 5 m² per fer feina, no és el mateix tenir 4 persones a un despatx de 20 m² que tenir 40 persones a una oficina de 200 m², la quantitat d'interaccions, renous, gent anant amunt i avalls, ... La productivitat es ressent.

Els tècnics però som gent que ens agrada fer feina i que la feina surti. De Marco diu que en aquests casos la gent intentarà fer feina de la millor manera que pugui, escapant-se a sales de reunions i a altres espais menys problemàtics. Avui en dia tenim tota casta d'aparells electrònics que ens permeten aïllar-nos d'un entorn poc apte per a la feina.

Aquest aïllament, però, té un problema fonamental, l'oficina es converteix amb una oficina autista. La gent no participa del que es cou ni tant sols amb el seu grup de treball. Els comentaris i la comunicació informal no existeixen. Per comunicar amb la gent del mateix equip i que està a pocs metres es necessari l'enviament d'e-mails i convocar reunions. La productivitat decau, es perd la sensació d'equip i de grup.

Potser algú ara dirà que ell es posa els cascs perquè fa feina millor amb música. Això no hi té res a veure, encara que trobem estudis que diguin que això no és veritat en tasques que requereixen molta concentració també segurament en trobarem que diuen tot el contrari. Aquests tipus d'estudis poden estar desviats per mor del que s'anomena Efecte Hawthorne. El fet però, que fins i tot en els casos de que hi pugui haver un petit augment de la productivitat personal, es perd la productivitat del grup, que és molt més important.

Si l'oficina és autista és quelcom que s'ha de millorar. Si no ho és hem de procurar que no s'hi convertesqui (sobretot si no hi ha factors ambientals associats). La comunicació ha de ser fluïda, les comunicacions formals s'han de deixar per coses formals. Si volem gaudir de la productivitat i eficiència que dóna fer feina amb grup hem de crear els factors ambientals que la facin possible. Si els factors ambientals són bons, no hi ha excusa per a deixar que l'aïllament autoimposat impedeixin una comunicació eficaç.

Tercera edició del creant bits, aquesta vegada amb un convidat d'excepció, Ricardo Galli, quen ens xerrà de como havien passat el meneame des d'una instal·lació clàssica a una configuració damunt Amazon AWS.

Com sabeu gràcies a la iniciativa del Parc Bit, a les empreses incubades com la nostra, APSL ens deixen disposar d'algunes sales per a les reunions, conferències, etc.

A les 14:15 aproximadament arribàrem al Parc Bit i la gent de seguretat ens obrí la sala. Deixàrem els portàtils i començarem a deixar llesta la sala. En Guillem, el tècnic, del Parc Bit i el personal de seguretat com sempre ens donaren totes les facilitats possibles, sense ells iniciatives com aquesta tampoc serien possibles.

L'aforament de les sales és limitat, però tot i estar un poc estrets i després de reordenar cadires i taules sortírem a menjar un poc. Entrepà ràpid i a les 15:30 a la sala a deixar les quatre coses que faltaven llestes: aigua, caramels i com no les gominolas que s'estan convertint en una tradició. Potser l'associació de dentistes i dietistes ens hauria de patrocinar alguna jornada, després de tot els durem molts clients! :)

Arriba Ricardo i comprovam que tot va bé. Vol fer l'experiment de fer streaming de video amb Ustream des del mòbil amb Android. Jo també havia fet experiments a casa amb el meu i es veia prou bé, però no n'estava del tot convinçut.

Al final podem configurar un "soport", mont un bastiment amb els seu mòbil amb una capseta per dur els disc dur portàtil. El disc dur fa de contrapès i la capsa té el tamany ideal, connectam el cable d'alimentació per USB al portàtil d'En Pau, que ens dona l'autonomia que necessitam sense tenir que passar allargadors per les taules.

La sala està plena, l'atenció és màxima, En Ricardo es un crack explicant i contant les coses. La gent pel twitter ens diu que l'streaming va prou bé. Fantàstic! Així ho podrem anar fent a propers actes.

La xerrada amb Ricardo no pot ser més interessants: aspectes tècnics, aspectes de configuració, exemples, aspectes econòmics i projeccions de futur.

Particularment de la xerrada he sortit amb idees addicionals:

• fer servir un entorn al núvol com a entorn de desenvolupament i proves
• entorn d'integració contínua. El Hudson per exemple permet distribuir la càrrega en molt de servidors. L'AWS ens permetria passar els tests d'integració amb un temps molt curt a un preu més que raonable.
• Consolidació de servidors. A partir de 4 servidors dedicats (segons els meus càlculs) és econòmicament rentable anar cap al núvol, no hi ha pràcticament diferència de preu i l'escalabilitat i flexibilitat és molt gran.

Qued estorat de les capacitats de l'AWS, del ben pensat que està tot. Està fet per ser usable i provat en condicions reals, la de tenir que escalar un lloc web com Amazon. La gent d'Amazon ha convertit una despesa en un negoci. Ells haurien de tenir quelcom semblant a l'AWS per el seu propi lloc. Amb un cost marginal que supòs que deu ser molt baix han creat un negoci nou.

També me n'adon del que està passant: Ricardo ens està contant no tan sols com ho han muntat amb pels i senyals, sinó que a més ens diu les dificultats que ha tingut, els perquès de cada cosa i ens presenta els cost real del que paguen, desglossat amb cada concepte. No és gens habitual i és una cosa més que fa que la xerrada sigui tant interessant.

Acabam com a quatre hores després. La xerrada ha estat molt bé, hem après coses noves i ens hem divertit. Què més es pot demanar?

Gràcies a tots els que heu vingut al Parc Bit a compartir un horabaixa amb nosaltres, als voluntaris que ens han ajudat a muntar i desmuntar i a tots els que ens heu segui per Ustream i el twitter, i obviament moltes gràcies a Ricardo per ser així com és i compartir amb nosaltres la seva experiència.

Enllaços

El hashtag de la jornada ha estat #creabits o bé i gràcies al cromo de DZPM twetchat, el genèric és #creant_bits.

Els vídeos: video de la primera part i a video de la segona part i la presentació en pdf.

La frase "I will code for food" és un acudit que un és pot trobar referint-se al mal pagat que estam la gent que es dedica a la informàtica en general, i també per a indicar que un programador vocacional pot voler fer la seva feina a canvi de no res (i el problema és que sovint ho fa).

En el meu cas el code for food s'estava convertint en una sensació. La sensació d'estar de florero i de estar a un lloc veient passar les hores sols per a poder dur un sou a casa.

No ho puc fer jo això. Potser me trobaré amb la necessitat del "I will code for food", però la realitat és que m'agrada massa aquesta professió com per a ser un simple espectador, així que ha arribat l'hora de emprenndre noves aventures i deixar una pseudo-comoditat per anar cap el desconegut, cap a l'aventura de dur endavant nous projectes i reptes.

No puc dir que per una part no em sàpiga greu, he conegut gent molt bona durant aquests sis darrers anys (i també vertaders ineptes, tot s'ha de dir) i estic encantat l'equip de gent amb la que he fet feina, des de la gent que em va aguantar en els temps difícils de reestructuració com a cap de suport i instal·lacions, fins als distints equips de gent que m'han tingut de cap de projecte de desenvolupament web. Hem fet moltes coses, duit a terme molts projectes, hem rigut i ens hem indignat plegats, ... És una experiència que m'ha enriquit com a persona, perquè se'ns dubte, de la professió el més important no és la tecnologia en sí, ni els ordinadors més o menys ràpids, el més important és la gent.

En la nostra cultura no estam acostumats a que la gent deixi una feina segura, potser perquè internament hi ha molta gent que aspira a ser funcionari. Personalment crec que deixar una feina (tenguis o no un altre projecte) ha de ser una decisió meditada, però que ha de ser una opció que ha d'estar allà. Consider que una feina com la informàtica pot i ha de ser quelcom més que una feina, jo l'entenc com a una vocació.

Deix una feina "segura" perquè em va la marxa, perquè vull sentir-me bé amb jo mateix, perquè m'agrada massa la feina que he triat com a professió, perquè vull aixecar-me als matins amb ganes d'anar a fer feina i no amb la sensació que he d'anar a passar l'estona a una cadira. Vull que la meva feina servesqui per a generar negoci, tenir el convenciment de que el que faig contribuirà a donar valor. Potser és mal d'entendre però cada un és com és.

Eps! I'll code for food :)