Sergio Gago

1) Always ask a person, “What have you shipped in the last two years?”
That’s all you should really ask. If they haven’t shipped anything in
the last two years, ask, “So what’s your excuse?”

2) The “job-as-life phase” lasts for maybe ten years. Nab ‘em when
they’re young, and make sure they never grow old.

3) You can’t trust a dog that’s bitten you. You wouldn’t want to
employ someone who you could steal away from another company in the
middle of a project.

4) The industry is made up of either gifted techies or smart
generalists - the people who were bored with high school - the sort of
people the teacher was always telling, “Now, Abe, you could get As if
you really wanted to. Why don’t you just apply yourself?” Look for
these people - the talented generalists. They’re good as project and
product managers. They’re the same people who would have gone into
advertising in 1973.

5) One psycho for every nine stable people in the company is a good
ratio. Too many maniacally-driven people can backfire on you. Balanced
people are better for the long-term stability of the company.

6) Start-up companies beware: kids fresh out of school invariably bail
out after a few years and join the big tech monocultures in search of
stability.

7) People are most ripe for pilfering from tech monocultures in their
mid- to late 20s.

The upper age limit of people with instincts for this business is
about 40. People who were over 30 at the beginning of the late 1970s. PC revolution missed the boat; anyone older is like a Delco AM car radio.

Microserfs - Douglas Coupland

Tengo que recomendar ver el video de la siguiente conferencia, a todos aquellos que trabajen para desarrollos web, o que estén interesados en cómo estos funcionen.

En esta conferencia, Jeff Rothschild nos abre los ojos sobre cómo facebook maneja su ingente cantidad de datos a nivel de escalabilidad. Muchas lecciones que nunca se me habrían ocurrido.

Web seminar for high perfomance facebook.

Ocurre de vez en cuando, que uno se pregunta… ¿Cómo he llegado aquí?
En mi vida, parte de mi jornada la dedico a programar. Aunque ahora tienda más al desarrollo de negocio y mi vena “empresario” tire más, quiero mantenerme a pie de cañón. Quiero seguir programando, pero… ¿Por qué? ¿Cómo he llegado a esto?

Haciéndo memoria, recuerdo que de pequeño quería ser paleontólogo. Mucho antes de parque juráisco, de hecho. Sin embargo mi padre apareció un día por casa con un spectrum (supongo que sería un geek de la época). Lo malo (o lo bueno), es que antes de pensar en chicas, programaba mejor que jugaba al fútbol (esto era fácil, la verdad), así que inconscientemente, fui gestando esa profesión en mi interior.

Ahora me pregunto: ¿De verdad es el trabajo de mi vida, o simplemente me autoconvenzo fantásticamente?

Ocurre que más o menos hasta nuestra generación, hemos vivido el nacimiento-crecimiento de la profesión y su “semi-profesionalización”. Hemos vivido carreras de informática (aunque no las hayamos cursado), y hemos sufrido consultoras. Pero la pregunta es: ¿Cómo nos entró el virus inicial?

Algunas ideas de por qué hacerse programador:

• Es una forma de ser artista sin tener ni idea de arte. Puedes CREAR.
• Puedes socializar y conocer a las personas, si llegar a llamarlas tus amigos
• Whenever - Whatever: Movilidad como en ningún trabajo.
• Es relativamente fácil encontrar trabajo pagado decentemente, en comparación con otras profesiones. Ahora, hay trabajo
• No es un trabajo de riesgo: Salvo en contadas excepciones, tu responsabilidad no va más allá de un par de pantallas azules, o de fatal errors en la aplicación.
• No hay barreras de entrada. Cualquiera puede ser programador. Ser un fiasco, o convertirse en una estrella depende de uno mismo.
• Hay retos, pero suelen ser con uno mismo. Impuestos por nuestro ego. “Esto sale por mis narices”.

¿Por qué sois programadores? ¿Si pudiérais ser otra cosa, qué seríais?

Hablemos del problema del vendedor viajero (Travel Salesman problem). Sin entrar demasiado en teoría computacional, digamos que es un problema NP-Completo, que ha dado muchos dolores de cabeza a matemáticos, programadores e ingenerios en general. Veamos por qué.

Supongamos que somos un comercial, que a lo largo de un mes, tiene que recorrer 50 ciudades distintas alrededor del mundo. Cada conexión entre ciudades tiene un coste (ya sea por tiempo, o por coste del billete de avión). ¿Cómo ayudamos al pobre comercial a trazar su ruta de forma óptima? Debería hacer Madrid - Londres - Nueva York - Los Ángeles - Pekin, o quizá Madrid - Nueva York - Los Ángeles - Pekin - Londres?

La solución parece evidente a simple vista, pero en realidad no es nada trivial. Y la solución de fuerza bruta es válida para 4, 5 o 6 combinaciones, pero no más (en combinatoria, sería el factorial del número de ciudades). Se puede interpretar como un problema de grafos, pero cuidado! No son algorítmos de búsqueda del camino más corto! Dijsktra no es válido aquí, ya que nuestro comercial tiene que recorrer TODOS LOS PUNTOS.

Bien, en este tipo de problemas, se suelen utilizar soluciones heurísticas. Es decir,  no será la solución óptima algorítmica al 100%, pero si una “válida” que tenga un porcentaje de error probablemente menor del 5%. No será la óptima en cuanto a resultado, pero si en cuanto a otros factores, como tiempo de computación, coste para generar la respuesta, y dolores de cabeza del ingeniero.

¿A qué viene esto?

En la empresa nos encontramos todos los días con problemas del viajero comercial. Y no me refiero a que los comerciales estén todo el día de parranda (que lo están), sino a que muchos de los problemas que nos encontramos no requieren nunca la solución perfecta. La respuesta óptima. Sino que dedicando menos tiempo, se puede llegar a una solución más rentable e igualmente válida. Muchos programadores pecan de esto. De ser extremadamente puristas, tener el algoritmo perfecto, la solución infinita, cuando en realidad, el objetivo estaba mucho más abajo que todo eso.

Así que recuerden: No busquen solo lo óptimo, sino también lo rentable y lo eficiente.

Algunos recursos:

• The travel salesman problem
• Problemas NP-completos

Maravilloso artículo - recopilación en devtopics. How to tell if you are a programmer geek. Que como vengo haciéndo en algunas ocasiones, resumo, traduzco y amplío.

• 256 es un precioso número redondo
• 10K no siempre significó 10.000.
• Empiezo a contar en 0, y termino siempre con uno antes que los demás.
• Termino las frases siempre con punto y coma.
  SG: Y tiendo a hacer sangrías e indetar cuando no hace falta.
• Escribo “igual” como ==, distinto !=.
  SG: Y no me asusto con ===
• Puedo teclear { llaves } si mirar al teclado.
  SG: Y el $ de mi teclado está muy gastado. Por suerte, más que el %
• A las frases las llamo “strings”.
  SG: Si te encuentras hablando de tu array de cromos panini, entonces tienes un problema.
• Uso habitualmente palabras como iteración, contiguo, trivial, versión, array, polimorfismo, parsear y WTF en conversaciones.
  SG: Los programadores no “hacemos”. “implementamos”.
• ¿Qué idiomas hablo? C#, Java, PHP, Python…
• Uso camelCase para los nombres.
  SG: Aunque algunos_prefieren_asi
• Leyendo un libro, me frustro cuando no puedo pulsar Ctrl + F para encontrar lo que estoy buscando.
• Me dan ataques de nostalgia cuando pienso en mi antiguo commodore 64, sinclair ZX-81, spectrum o amiga.
  SG: Y a pesar de tener un pepino de equipo para los mejores juegos del momento, aún tengo el ejecutable del Wolfenstein
• Asumo que la mayoría de la gente ama su trabajo tanto como yo.
• Creo que xkcd es el mejor webcomic que ha existido nunca.
• Tengo más de 1 monitor
  SG: Y uno de ellos está en posición vertical.
• Tengo más direcciones de correo que pares de zapatos
• Tengo un servidor web en casa
  SG: Y descargando 24h
• Me envío mails a mi mismo para recordarme cosas.
  SG: Y mi bandeja de entrada es una implementación propia de GTD

¿Alguna otra sugerencia?

Esto es muy viejo, pero comentándo con un amigo hace poco, no lo conocía. Así que lo pongo para cultura de todos

Si amigos, los consultores, esas personas que llegan a nuestra empresa y sueltan su sabiduría acumulada a lo largo de los años, y que multiplican por números inconsistentes los beneficios de nuestro negocio. Hay muchos tipos, claro. Los consultores de empresa, de marketing, tecnológicos, los pseudo consultores, los gurús, etc. Pero al final todos se pueden dividir en el mismo grado.

Claro, como estamos hablando de consultores, utilizaremos el archiconocido e infalible método de la matriz 2×2, conviértase en guru en 7 minutos. Click en la imágen para ampliar.

Procedamos a describir un poco mejor a los actores del sistema, nuestros distintos tipos de consultores:

• El Pepito grillo: Es la voz de tu conciencia. Te dice lo que deberías hacer pero que él sabe que no puedes. Típico caso: “Deberías comprar esta máquina tan cara y buena, aunque ya se que no tienes presupuesto”.
• El pirata cojo: En homenaje a la canción de Sabina. Solo sabe hablar de sus otras vidas y de lo mucho que ha hecho y la experiencia que tiene. Ejemplo: “Recuerdo cuando fuí crupier en Las Vegas, que tuve un caso similar al tuyo”.
• El experto: Solo sabe de una cosa. Sabe mucho, pero de nada más. Caso: “Para mejorar este proceso tienes que cambiar esto de aquí, no se si te cargarás otros procesos críticos de la empresa, pero lo mío, funcionará”. O también… “a alguien le suena SAP?”
• El Steve Urkel: Cuando algo sale mal, él no la ha cagado. Habrá sido un problema de la implementación, seguro.
• El bibliotecario: Su know-how se basa en una gran colección de libros que no para de recomendar. Probablemente varias veces. Hará referencia a su amistad personal con los autores y lo mucho que le han ayudado en la vida esos libros.
• El bricomanía: Cuando te explica algo parece muy fácil, pero una vez ya no está ahí todo es mucho más complicado.
• El auditor tocacojones: Solo sabe decir lo que tienes mal, pero rara vez aporta una solución práctica. Caso: “Uy uy uy, esto es imposible, no puede ser así, tenéis que cambiarlo”.

Así que ya sabéis amigos. A la hora de gastar el presupuesto de 5 trabajadores en el salario de un consultor que os resuelva la vida, pensáos muy bien si vosotros mismos no podéis hacerlo, y sino, aseguráos de qué tipo lo contratáis.

¿Alguna clasificación más al sistema?

Darwin se está revolviendo en su tumba. Resulta que las especies ya no sobreviven según su capacidad para sobrevivir tal y como se había pensado, sino según su capacidad para evadir la estupidez. Y es que después de cierto tiempo, uno piensa que las personas nacemos estúpidas, y poco a poco, algunos nos quitamos la lacra que supone llevarlo.

Resulta que nos quejamos de lo mal que funciona la sociedad, la hipocresía de la gente, de sus gobiernos, etc. Por ejemplo, los engañabobos de mandar SMSs para conseguir suculentos premios o hacerse rico, o los concursos donde si llamas a un 905 y respondes al color del caballo blanco de san pedro, conseguirás dinerín fresco y sin esfuerzo.

Ya no me meto en si el dinero fácil te dará o no la felicidad, sino en lo fácil que resulta engañar a alguien hoy en día.

La cuestión es, que al fin y al cabo, estos engañabobos son negocios, y como tales no se harían si no fueran rentables. Un programa de mierda, que ocupa 45 minutos entre las 9 y las 10 de la mañana de un día laborable cuesta dinero e infraestructura de montar. Lógicamente no se haría si no tuviera una rentabilidad bien elevada. Por tanto, como dicen en algunos sitios… si me engañas una vez es culpa tuya, si me engañas 11, bueno… igual sigue siendo culpa tuya.

Dialers, SMSs para suscripciónes, príncipes nigerianos que necesitan sacar el dinero de su país, hazte rico con tu móvil, ganáste un coche, eres el visitante 1 millón, conoce chicas calientes cerca de tu casa… La oferta de esta morralla nunca ha faltado, y aunque la prohiban, surgirán nuevos modos, porque siempre hay primos a los que engañar.

Yo he decidido dejar de quejarme sobre esto y, comprender, que, al final, se trata de selección natural. Ellos existirán siempre que los alimenten. Tenemos lo que nos merecemos. Nuestros políticos, nuestra televisión basura, nuestros cotilleos, nuestros timos, etc. ¿Puedes hacer tú algo para cambiarlo?

En áRes:desarrollo estamos cambiando nuestro modelo, de ser una agencia de diseño Web 2.0 a ser asesores de estrategias en la red, pero han sido unos cuantos años que nos han enseñado muchas cosas. Una de las cuales es, cuándo no aceptar un proyecto, aunque estés escaso de clientes. Y es que un mal cliente es mucho peor que no tener clientes.

Sin embargo, Jeffrey Zeldman la ha clavado en su post 20 signs you dont want that web design project.

Parece un post irónico, de coña, pero señores… la cosa va muy en serio. Si tu cliente va por estos lindes, es mejor no aceptarlo!

Voy a traducir algunos de los mejores puntos de la lista:

• El cliente tarda seis meses en responder tus bocetos y propuestas, pero no cambia la fecha final de entrega.
• En la primera reunión del proyecto, después de un análisis previo y de haber viajado bajo tus propios costes, el cliente te dice que no tiene presupuesto, pero que está abierto a hacer un intercambio de servicios.
• El cliente no puede articular un solo objetivo de usuario. Tampoco una estrategia de negocio, una estrategia online, una razón para la mera existencia de su sitio Web un una única métrica para mejorar su Web. Pero a pesar de todo, ha diseñado un increiblemente detallado boceto.
• El cliente te asegura que aunque él, que es un “hombre de visión”, no se involucrará en el diseño de la web, su empleado, el contacto, estará dedicado completamente para aprobar cada entregable.
• En la reunión de entrega, el anteriormente mencionado “hombre de visión”, entrega dibujos de su idea de cómo debería ser la estructura de la Web. Estos dibujos no tienen nada que ver con la investigación que has hecho, con las recomendaciones aprobadas, con los bocetos aprobados o con el diseño final aprobado.. Tampoco con el diseño final de las páginas, ni siquiera con las plantillas HTML que estás integrando en el CMS.
• Justo antes de llegar, la empresa despide a tu cliente. Un asistente sobresaturadose encarga del proyecto. El site nunca llega a nada. Dos años después, una nueva persona al cargo te envía mails para que rediseñes el site.
• El cliente te envía un request for proposals de 40 páginas, incluyendo diagramas de flujo aprobados por el comité hechos en Microsoft Art.
• El cliente te dice que ha realizado un estudio de usabilidad con su mujer.
• Cuando elt rabajo del back-end está a punto de terminar, el cliente se replantea la arquitectura.

Lo peor de todo es que muchas de estas cosas, son completamente impreisibles, y te pueden fastidiar entero. Cuando la empresa cliente es de más de 10 personas, hay que evitar que todo el mundo opine, y que todo el mundo proponga funcionalidades que no estén cerradas. Intentar que el contrato esté bien cerrado y las fechas de pago bien señaladas en el calendario.

En fin, un artículo muy recomendable. Y en breve os mostraremos el nuevo camino que está tomando áRes!

Ojalá hubiera tenido este video cuando empecé a programar en C, años ha.

Un puntero (o apuntador) es una variable que referencia una región de memoria; en otras palabras es una variable cuyo valor es una dirección de memoria. Si se tiene una variable ‘ p ‘ de tipo puntero que contiene una dirección de memoria en la que se encuentra almacenado un valor ‘ v ‘ se dice que p apunta a v.

(wikipedia)

Gracias Tomy!