Lo tomare muy en cuenta.

Saludos.

Este tipo de feedback, aunque sea para algo tan sencillo (que no simple) como decir qué te ha parecido el artículo, ayuda a la hora de elegir qué cosas pueden resultar más interesantes para los lectores de Ludosofía.

Cuando releí el artículo me di cuenta de que ese concepto podría no haber quedado muy claro

Trato de explicarme a posteriori:

El principio de uniformidad enuncia que, una vez observamos varias veces que A tiene como resultado B, asumimos que A siempre dará como resultado B.

El CV como medio de transmisión de información es muy limitado a la hora de garantizar la seguridad de que seremos competentes de cara al desarrollo de las tareas requeridas. Esto es un problema que tiene que solucionar la persona encargada de la selección de personal.

Considerando esto, podremos aumentar nuestras posibilidades de éxito si conseguimos transmitir a esta persona que poseemos valores que habitualmente conllevan (resultan en) otros valores / actitudes /habilidades que sí resultan directamente aplicables al puesto solicitado. Estos valores, al ser universales y muy generales son mucho más fáciles de transmitir en un CV.

Ahora, a la luz de estos razonamientos, copio el párrafo donde se explica esto en el artículo:

“Por ejemplo, en el ejemplo mencionado más arriba podrían tomarse el tiempo de navegar por el código de tu motor, lo cual les daría la información que necesitan, pero es algo que rara vez harán porque en un proceso de selección no suele sobrar el tiempo. En lugar de eso, tendrán que reunir el resto de datos que posean y aplicar el principio de uniformidad. Llegados a este punto, si se pueden intuir tendencias positivas o negativas en tu trayectoria no profesional, la empresa frecuentemente asumirá que te comportarás del mismo modo si te contratan. Así pues, algo que podemos hacer para suplir una falta de experiencia profesional es asegurarnos de que nuestros proyectos rebosan de tendencias positivas y promesas de rendimiento.”

Espero haber respondido a la pregunta.

Estoy de acuerdo en que una buena parte del tiempo, los programadores estarán desarrollando los componentes que se ocuparán de las operaciones transaccionales, lo que viene siendo crear los cimientos y el framework dentro del cual trabajarán.

Por otro lado, son muchísimas las veces que un programador viene a tu mesa a explicarte que, al realizar el despiece lógico que conlleva analizar una funcionalidad para traducirla a código, ha encontrado un fallo. Yo en particular he encontrado valiosísima la ayuda que puede proveer un programador cuando está viendo el producto desde las entrañas hacia afuera.

Así pues, ¿es necesario que el programador tenga cultura de juegos? No, no lo es. ¿Es conveniente? Yo pienso que sí. El tipo de visión que tiene el programador es difícilmente asumible por un diseñador, no por los conocimientos necesarios (ya que muchos diseñadores somos también programadores) sino porque frecuentemente es una tarea inabarcable el intentar conocer todos los entresijos del proyecto. En este sentido, sus aportaciones pueden ser inestimables.