La fe en lo empirico

Si tienes un puesto con un minimo de resposabilidad se te exige que tomes decisiones en lo que realemente no importa la decision que tomes. Solo importa que el resultado de tomar esas decisiones sea el correcto.

En muchas ocasiones se te presenta la tesitura en la que tienes que elegir un camino para afrontar una situación a sabiendas que el elegir una opcion u otra puede tener mucho impacto en el desarrollo de un proyecto.

Por ejemplo, tengo 10 incidencias que abordar para esta semana y las 10 no pueden estar porque no hay tiempo para solucionarlas todas ¿que hago?:
- ¿Soluciono estas 3 incidencias que son de la misma funcionalidad y asi cierro esta funcionalidad?
- ¿Soluciono estas 7 incidencias y asi soluciono el mayor numero de incidencias posibles?
- ¿Soluciono estas 5 incidencias que son las que tienen mas visibilidad?

Cual es la correcta?

Pues cualquiera puede ser la correcta pero es una loteria porque todas estan basadas en la forma inicial del problema. No en el resultado. La forma correcta es empezar por el resultado. Seguimos con el ejemplo,
¿Cual es el resultado valido? Pues la experiencia me dice que las 10 incidencias tienen que estar solucionadas, no puedo dejar ninguna fuera. Me han dado una semana pero mi experiencia me dice que si empiezo por las incidencias mas dificiles al final de la semana puedo justificar que no da tiempo y conseguir mas tiempo y al final tener las 10 incidencias.

En este ejemplo, te basas en la experiencia para saber cual es el resultado valido y saber como afrontar el problema pero te estas "ariesgando" mucho porque ¿Seguro que tienen que ser las 10 incidencias si o si? ¿Como sabes que te van a dar una semana mas?. Pues muy sencillo, ten fe en lo que ya sabes.

Hablar con los subordinados

Cuando te toca hablar con los subordinados tienes que mostrarte de una manera determinada que puede ir de entre los dos extremos: dialogante  y autoritario. Vamos a analizar lo positivo y lo negativo de ambas extremos.

Dialogante:

Positivo:

Si te perciben como una persona dialogante entonces se mostraran comodos hablando contigo y potenciaras su creativadad.

Mejoras tu empatia y puedes ayudar a los subordinados a decir lo que saben pero no saben explicar.

Negativo:

Al mostrarte dialogante provocas que no tengan que tomar decisiones por lo que se vuelven mas dependientes.

Un exceso de dialogo provoca que un subordinado crea que pueda hablar contigo de todo. Muchas veces te comentara cosas repetitivas que ya deberían saber (potencia el conformismo).


Autoritario:

Positivo:

Tendrán mas cuidado en lo que te comentan por lo que auto-obligaran a estar mas preparados.

Seran mas precisos y meticulosos en su trabajo.

Negativo:  

Si empiezan a tenerte miedo pueden ocultar fallos con el proposito de no contartelo.

Pueden engendrar un resentimiento que afecte a su trabajo y  al de sus compañeros.

Son muchos aspectos y puede dar la sensanción de que hagas lo que hagas vas hacer algo bien y algo mal. ¿Que debes hacer? Mantener un equilibrio habra ocasiones que tendras  que ser dialogante y
otras que tendras que ser autoritario.

Lo que si es seguro que hay que seguir las siguientes pautas:

• Hay que saber identificar cuando y con quien debes ser autoritario o dialogante.
• No hay que enfadarse nunca. Rotundo si. Furioso no.
• No puedes equivocarte. Te pueden convencer de lo contrario de lo que piensas pero si no sabes si llevas razon, no insistas.

Saber explicarse

No saber explicarse tiene muchos aspectos que afectan al trabajo de los profesionales del software:

• Es una características que puede convertir a un buen programador/jefe/funcional/etc... parecer mediocre y viceversa (es decir a un profesional que SI sabe explicarse, que en verdad es un "vendemotos", en un profesional muy valorado).
• Supone la diferencia en que se haga lo correcto (o la mejor opcion dentro de lo correcto) o que no se haga ya que si no sabes explicarte entonces las conversaciones y/o reuniones (donde se decide que se hace en el desarrollo) las "ganará" otra persona y serán sus ideas las que se desarrollen.
• Es un motivo de frustración para el profesional. Un buen profesional sabe lo que tiene que hacer ante un desarrollo y/o problema pero si no sabe explicarse puede que en la conversacion y/o reunion donde se decide todo se decida lo que ha explicado mejor otra persona (pero que el profesional que no sabe explicarse sabe que no es correcta). Por lo que se da el caso de que el buen profesional que no sabe explicarse se vea desarrollando una solución que sabe que es incorrecta.

¿Como puedes explicarte mejor? A continuación enumero una serie de buenas practicas para mejorar la forma de explicarse:

• Practica. Practica. Practica. Ya sea en conversaciones y/o reuniones donde se decide que se hace en el desarrollo o simplemente con un compañero de trabajo que tienes al lado intenta explicarle de vez en cuando lo que estas haciendo y porque crees que es la mejor opción.
• Asegurate que todos en la reunion/conversación hablen el mismo idioma. Con esto no quiero decir que hables todos ingles, español o frances (doy por sentado que todos hablais el mismo lenguaje) sino que usais las palabras del mismo modo. Por ejemplo, si dices algo como: "el modulo A hace de interface de usuario" luego en la conversación/reunion no digas algo como "el componente A hace de interface de usuario" si en las dos ocasiones te referias a lo mismo. Es decir, utiliza siempre la misma palabra para referirte al mismo concepto.

 

Desconocer como se hace bien

Sony XPeria. BlueTooth. No se puede asociar vincular. PIN o contraseña incorrectos

He intentando asociar un SmartWatch Sony 3 con un Sony Xperia y me ha sucedido que a la hora de asociar el bluetooth me da un fallo de que no se puede asociar vincular debido a que el PIN o clave son incorrectas. Creo que esto puede suceder debido a que los dispositivos ( como el SmartWatch Sony 3) que permiten asociar sin preguntar la clave de forma explicita en verdad si que la piden solo que suelen ser del tipo 1111 o 0000 y si el dispositivo que se quiere asociar no prueba con esas claves simples entonces falla.

La forma en que he conseguido asociar los dos dispositivos es dandole la vuelta. Es decir, he asociado el SmartWatch Sony 3 con otro dispositivo que si que dejaba vincularse, una vez que el SmartWatch Sony 3 ya permitia usar sus funcionalidades he buscado el Sony Xperia y ha sido el SmartWatch Sony 3 el que se ha vinculado asociado al Sony Xperia.

Una vez conseguido esto ya estan vinculados asociados y ya se pueden usar conjuntamente.

Socket en C++. Visual Studio Express 2015

A continuación se muestra como crear un socket en c++.

Este codigo funciona correctamente en el Visual Studio Express 2015

Este codigo lo he sacado del https://msdn.microsoft.com

#include "stdafx.h"

#ifndef WIN32_LEAN_AND_MEAN
#define WIN32_LEAN_AND_MEAN
#endif

#include <windows.h>
#include <winsock2.h>
#include <ws2tcpip.h>
#include <iphlpapi.h>
#include <stdio.h>

#pragma comment(lib, "Ws2_32.lib")

struct addrinfo *result = NULL, *ptr = NULL, hints;
#define DEFAULT_PORT "27015"
int main() {

ZeroMemory(&hints, sizeof(hints));
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
hints.ai_flags = AI_PASSIVE;

WSADATA wsaData;
int iResult;

// Initialize Winsock
iResult = WSAStartup(MAKEWORD(2, 2), &wsaData);
if (iResult != 0) {
printf("WSAStartup failed: %d\n", iResult);
return 1;
}


// Resolve the local address and port to be used by the server
 iResult = getaddrinfo(NULL, DEFAULT_PORT, &hints, &result);
if (iResult != 0) {
printf("getaddrinfo failed: %d\n", iResult);
WSACleanup();
return 1;
}

SOCKET  ListenSocket = socket(result->ai_family, result->ai_socktype, result->ai_protocol);

if (ListenSocket == INVALID_SOCKET) {
printf("Error at socket(): %ld\n", WSAGetLastError());
freeaddrinfo(result);
WSACleanup();
return 1;
}

iResult = bind(ListenSocket, result->ai_addr, (int)result->ai_addrlen);
if (iResult == SOCKET_ERROR) {
printf("bind failed with error: %d\n", WSAGetLastError());
freeaddrinfo(result);
closesocket(ListenSocket);
WSACleanup();
return 1;
}

freeaddrinfo(result);

if (listen(ListenSocket, SOMAXCONN) == SOCKET_ERROR) {
printf("Listen failed with error: %ld\n", WSAGetLastError());
closesocket(ListenSocket);
WSACleanup();
return 1;
}

SOCKET ClientSocket;


ClientSocket = INVALID_SOCKET;

// Accept a client socket
ClientSocket = accept(ListenSocket, NULL, NULL);
if (ClientSocket == INVALID_SOCKET) {
printf("accept failed: %d\n", WSAGetLastError());
closesocket(ListenSocket);
WSACleanup();
return 1;
}

closesocket(ListenSocket);

char recvbuf[512];
int  iSendResult;
int recvbuflen = 512;

// Receive until the peer shuts down the connection
do {

iResult = recv(ClientSocket, recvbuf, recvbuflen, 0);
if (iResult > 0) {
printf("Bytes received: %d\n", iResult);

// Echo the buffer back to the sender
iSendResult = send(ClientSocket, recvbuf, iResult, 0);
if (iSendResult == SOCKET_ERROR) {
printf("send failed: %d\n", WSAGetLastError());
closesocket(ClientSocket);
WSACleanup();
return 1;
}
printf("Bytes sent: %d\n", iSendResult);
}
else if (iResult == 0)
printf("Connection closing...\n");
else {
printf("recv failed: %d\n", WSAGetLastError());
closesocket(ClientSocket);
WSACleanup();
return 1;
}

} while (iResult > 0);


iResult = shutdown(ClientSocket, SD_SEND);
if (iResult == SOCKET_ERROR) {
printf("shutdown failed: %d\n", WSAGetLastError());
closesocket(ClientSocket);
WSACleanup();
return 1;
}
closesocket(ClientSocket);
WSACleanup();
return 0;
}

Incertidumbre de culminación de tareas

Cuando se le asigna una tarea a un programador para que la cumpla (en general voy a hablar de  tareas que lleva varios días culminarla pero también se puede aplicar a tareas pequeñas) hay varias metricas que se usan para evaluar el grado de avance o resultado si ya esta terminada:

• Grado de avance respecto a lo planificado.
• Calidad del desarrollo.
• % de pruebas superadas.
• Revisiones de código.
• etc...

Todas las metricas que se usen se pueden ser mejor o peores para conocer el estado del desarrollo y llevar  a la culminación de la tarea dependiendo de la incertidumbre de culminación de la tarea que presenta el desarrollador encargado de la tarea.

La incertidumbre de culminación de tareas es la probabilidad de que un programador haya implementado una tarea de acuerdo a como el responsable quiere que lo haga.

Cuando el responsable de una tarea piensa (diseña) la tarea no habria mejor persona para acometerla que esa misma persona (no lo va a hacer porque lo que tiene que hacer es diseñarla para que lo haga otros y esa persona pueda hacer otra cosa) y si esa persona acometiera la tarea es casi seguro que al hacerlo se encontrara con realidades (esto es mejor asi, esto asi no sale, etc..) que variarían la forma que tenia pensada en que se acomete la tarea y posiblemente hasta cambios de diseño. Con esta premisa, es lógico pensar que otra persona (un desarrollador) presenta una incertidumbre de culminación de tareas muy alto.

Para evitarlo, es básica la formación continua de los programadores y asegurarse de que comprenden el marco de trabajo que se usa para el desarrollo del proyecto. Pero es muy optimista pensar que con esto vale, se deben usar técnicas con mas supervisión como programación extrema. Quizas la mejor opción es seleccionar un dia al azar y pasar la mayor parte del dia sentado en el sitio del programador, hablar con el, ver como plantea las cosas, que esta haciendo, que es lo que ha entendido, etc.. La claves es asegurarse de que ha entendido el marco de trabajo y que va a culminar la tarea como espera el responsable que se va a resolver.