1. En boca cerrada no entran moscas.
2. Nunca discutas con un idiota porque la gente puede no notar la diferencia.
3. Al hablar estás colocando en bandeja de plata al adversario tus intenciones y lo que estás pensando. Cuando hablas, tú única intención es demostrarte a ti mismo que tienes razón, o demostrárselo a tus adláteres: tu adversario se reirá muy ufano de tí, bien sea abiertamente, o para sus adentros.
4. Cuando atropellas con las palabras revelas cuanto te hace falta que te oigan: seguramente tus padres, tus maestros, o tus amigos no te dejaban hablar o simplemente no te prestaban atención: en consecuencia te sientes inferior y lo demuestras al hablar.
5. Según Pedro Emilio Coll se puede llegar a ser presidente de la república simplemente permaneciendo en silencio: otros lo logran ladrando, mugiendo y balando: por lo tanto, las palabras y los rugidos no son necesarios: el león ruge cuando tiene hambre o cuando desea sexo: cuando se trata de defender o atacar son las garras y los colmillos los que hablan.
6. Es preferible callarse la boca: si hablas todo el tiempo, la gente deja de prestarte atención aun cuando lo que estás diciendo sea algo diferente o algo importante: no te tomarán en cuenta por lo que hablas, sino por lo que haces.
7. Al hablar siempre corres el riesgo que te manden a callar.
8. Una oración es un sujeto, verbo y predicado: para algunos una oración es un “yo” un predicado y otro predicado: así que éstos habladores lo que deberían es callarse la boca y regresar a la escuela.
9. No lo diga, escríbalo: si lo que hablas es 10 veces más que lo que escribes, revísate: eres un hablador de gamelote.

Y Finalmente la razón número 10 de porqué debemos callarnos la boca:

10. Nunca te llamarán sabio: los sabios no hablan, sino que prestan atención.

Genial, no tengo más palabras.

Sacado de micronosis

We build your digital business,
even while you’re up and running.

Ver video en Youtube

Los programadores nos negamos a borrar el código fuente que hemos estado escribiendo por dos razones: nos parece que hemos producido una pequeña obra de arte, y porque no queremos pasar nuevamente por el dolor, el parto de producirlo de nuevo. Creemos que si lo intentamos de nuevo, no nos va a quedar igual. Así que nos empeñamos en continuar con él, con la esperanza de hacerlo funcionar. Pero la realidad está en nuestras narices: será muy elegante y le hemos dedicado mucho tiempo, pero no funciona. No sirve. No hace lo que se supone debe hacer. Podemos continuar intentándolo, revisándolo, leyéndolo una y otra vez. Quizás nos vayamos a dormir. Quizás el día siguiente como por arte de magia funcione. Pero no. Si en algo así como 4 horas no has conseguido el error (el bug en la jerga de los programadores) las probabilidades de que lo consigas en las siguientes 40 horas son mínimas.
…

Y estoy de acuerdo. A veces da pena y optamos por comentar grandes cantidades de código que hemos rehecho, por si acaso queremos volver atrás. Pero no. Hay que borrar, cortar, operar, coser y desechar lo malo. Además, siempre podemos tirar de copia de seguridad ¿no?

Sigue leyendo la regla #37 del programador en micronosis, un blog que acabo de descubrir de un programador hiperactivo, aficcionado como yo a las aventuras conversacionales.

Si trabajas programando, seguramente hayas oido más de una de estas frases.

• Si compila, funciona
• Si compila, el codigo es correcto.
• Si ejecuta, es que no tiene bugs
• Si no los bugs no aparecen inmediatamente, es perfecto
• Si un bug no aparece, es que no existe
• Si parece que funciona, entonces funciona
• Hacer las cosas bien es facil. Para evitar los errores solo hace falta un poco de concentracion
• A menor tamaño de codigo, mas velocidad
• Es obvio como optimizar un programa
• Los programadores no comenten fallos
• Los errores en tiempo de ejecucion (runtime error) nunca ocurren
• Los usuarios no cometen fallos
• Yo no cometo fallos
• Los errores de cualquier tipo son raros
• La gestion de errores para la version 2
• Es correcto que se cuelgue si los datos de entrada son malos
• Es correcto que devuelva datos malos por si los datos de entrada son malos
• La portabilidad no es útil
• Lo que importa es el tamaño de la lista de features (caracteristicas)
• La velocidad es buena, pero las features (caracteristicas) son mejor
• La lentitud se arregla ampliando hardware
• Cuanto mas grande es un programa, mejor es
• Los cambios aleatorios en el programa arreglan los bugs.
• Para probar solo hace falta muy poco tiempo
• Encontrar fallos es facil, arreglarlos es trivial
• Los bugs arreglados no necesitan ser probados
• Los cambios triviales no necesitan ser probados
• La primera idea, aproximacion o version es siempre la mejor
• El codigo es autoexplicativo, no hace falta comentarlo.
• Los comentarios estan hechos por y para otra gente distinta del autor.
• Las features sin documentar son utiles y divertidas
• Siempre se puede arreglar para la siguiente version
• Usuarios sorprendido, usuario feliz
• La mejor manera de depurar es en la demostracion con el cliente

La versión original está aquí. La traducción la he hecho yo mismo, pido disculpas si no está del todo bien (o si la cosa ha perdido gracia con respecto a la versión inglesa)

Para que vaya quedando clara la cosa. Todos aquellos que mitifican la labor del informático, analista, programador o lo que quieran ustedes llamarme, que todas esas cosas juntas (y ninguna) soy, tomen un pequeño baño de realidad. No dudo que haya sitios mejores que el mio (a veces pienso que todos lo son), pero por si acaso algún joven descarriado sigue interesado en dedicarse a este tema, le menciono de pasada cómo es mi trabajo real:

• La gestión de proyectos es inexistente.
• No hay documentación
• Las especificaciones de usuario te las inventas
• El análisis se basa en lo que cada uno le da a entender su musa interior
• Los directivos son del modelo: “no hay que saber, hay que hablar como si se supiera”
• La informática sirve para solucionar los problemas del mundo
• No hay inversión en seguridad ni en licencias de software
• Formación inexistente para el departamento de informática o los usuarios
• Jodido Burócrata
• Los incentivos a la productividad se basan en la conocida técnica del management denominada: “el palo sin la zanahoria”
• Los servidores de pruebas son los mismos que los de producción

Lee el artículo completo con cada punto ampliado (lo que lees es solo un resumen mío) en Velocidad de escape. (Vía Microsiervos)

Increíble análisis que hace álvaro J. Iradier sobre esta novedosa metodología de desarrollo que utilizan las pymes (y no tan pymes) a la hora de afrontar nuevos proyectos.

Es muy importante que todos los recursos estén debidamente separados en capas bien diferenciadas, mínimo un número de 4, cuyos nexos de unión están vagamente definidos, permitiendo que la desinformación fluya casi desde cualquier punto hacia cualquier punto. De este modo el conocimiento se reparte de manera homogénea pero caótica, mientras que el dinero y el trabajo están perfectamente repartidos de manera heterogénea, determinista e inversamente proporcional. En las capas superiores debe concentrarse la mayor cantidad de dinero y la menor de trabajo, y en las capas inferiores donde se lleva a cabo el desarrollo el dinero se reparte en forma de limosnas.
Leelo entero aquí: Metodolodía: Xtreme Time-Wasting

Via 86400.es, me encuentro con una lista de posibles preguntas (algunas bastante complicadas) que te pueden hacer en una entrevista. Esperemos que nadie las pregunte todas, pero estad seguros que si que pueden caer algunas, asi que no viene mal estar preparados, sobre todo si el puesto realmente nos importa.
Personalmente, en casi todas las entrevistas que me han hecho me han preguntado cual era mi mejor y mi peor cualidad o como me definiria. Creo que en estas preguntas tan “especiales” se valora casi lo mismo lo que digas y como lo digas.. o quiza la capacidad que tienes para salir del paso en preguntas complicadas.
?Alguien tiene alguna anecdotas en entrevistas de trabajo?

1. Háblame de tí
2. ?Qué sabes de nuestra empresa?
3. ?Por qué quieres trabajar con nosotros?
4. ?Qué puedes hacer que no sepan otros?
5. ?Que te parece más atractivo de tu puesto? ?y qué menos?
6. ?Por qué deberíamos contratarte?
7. ?Qué buscas en un trabajo?
8. Por favor, defíname su puesto de trabajo
9. ?Cuánto tiempo tardaría en realizar una contribución considerable a nuestra empresa?
10. ?Cuánto tiempo estaría con nosotros?
11. Su currículum sugiere que puede estar sobrecualificado o con demasiada experiencia? ?qué opina?
12. ?Cual es su forma de trabajo?
13. ?Es Ud un buen encargado? Dénos algunos ejemplos. ?Siente que tiene un poder especial para dirigir?
14. ?Qué busca cuando contrata gente?
15. ?Ha tenido que despedir a alguien? Díganos las razones y cómo resolvió la situación
16. ?Qué cree que es lo más difícil de ser un buen encargado o ejecutivo?
17. ?Que tendencias ve en nuestra empresa?
18. ?Por qué dejó su último trabajo?
19. ?Cómo se siente dejando todo lo anterior para buscar un nuevo empleo?
20. En su actual posición, ?qué características le gustan más? ?y cuales menos?
21. ?Qué piensa de su jefe?
22. ?Por qué no está ganando más con su edad?
23. ?Cómo cree que debería ser remunerado su puesto?
24. ?Cuales son sus metas a largo plazo?
25. ?Cuánto éxito ha tenido hasta ahora?

Mi buen amigo kotrina, nos comenta en su ultimo post unas atrevidas y muy acertadas conclusiones sobre las consultoras de informática en este país. Copio y pego:

Tras cinco años dedicados al mundo de la consultoría dentro de unos días lo dejaré, por lo menos de momento, y espero que por muchos años, o qué carajo, espero no volver nunca. En estos 5 años y pico he pasado por 4 empresas, cada una totalmente diferente a la otra; desde el más infame chiringuito en un piso del centro de Madrid hasta el megaempresón con cientos y cientos de empleados.
Mis conclusiones después de todo este tiempo son las siguientes:

• Las consultoras son el el fondo ETT’s de la informática, ngañan a los empleados y engañan a los clientes.
  Es decir, te envían a un cliente, al que le dicen que tienes 14 años de experiencia que has trabajado para la Nasa y que hablas 5 idiomas. Cuando en realidad ese es tu segundo trabajo, el primero fue de becario. A ti te pagan una mierda y al cliente le cobran un pastón.
  Un ejemplo claro es mi situación actual, en mi contrato figuro como analista, pero para el cliente para el que trabajo soy consultor, y de acorde a ello le cobran, claro. La empresa está en Tres Cantos, al lado de la estación, todos sabeis cúal es.
• Para que hablar de las empresas de carne, es decir, las que no hacen nada de nada, sólo te venden a un cliente, que suele ser otra consultora grande. En algunas ocasiones esas empresas son un tío con un móvil y un mercedes; qué vergueza.
• Volviendo al engaño al cliente. Es lamentable la forma que se lleva el negocio en este mundo, siempre se hacen planificaciones perfectas del trabajo y luego nunca se cumplen. Al cliente
  se le presentan proyectos de x años con x personas, se les cobra en base a eso pero luego, en la realidad los tiempos y recursos se dividen entre dos. Yo he vivido algunas situaciones inauditas en una de mis empresas, vasca y con el nombre de una universidad (oro parece, plata no es).

Digamos que al fin y al cabo son todas iguales: lamentables. Estas empresas están llenas de charlatanes y vendemotos. Parece que todos los buscavidas han encontrado su filón de oro en este segmento, ya que lo de vender crecepelos milagro cada vez es menos creible y respetable.

Directo y al grano, y además estoy con el al 100%, la mayoría (no todas, porque no he trabajado en todas) de las consultoras engañan a sus clientes, no tratan bien a sus empleados y se lucran con tu trabajo.

Cuando más hacemos, más podemos hacer; cuando estamos más ocupados es cuando tenemos más tiempo para divertirnos.

Pitágoras de Samos (582 a.C.- 496 a.C.)

Vía CPI, uno de mis blogs favoritos:

Oído por ahí:
- ?Cuánta gente trabaja en tu empresa?
- Más o menos un tercio

Qué real!