Material del evento: Asentando las bases

Ayer tuvimos el último evento del año en AndorraDotNet. Mientras llegan las fotos que hicieron algunos de los asistentes, aprovecho para publicar el material del evento, tanto la presentación como los proyectos de ejemplo.

 image

La presentación la encontraréis aquí:

Y la solución de Visual Studio aquí:

Gracias por todo y nos vemos pronto!

10 cosas que me gustan de C# respecto a VB

peleaAntes de empezar a leer este post, un aviso: En ningún modo pretendo crear polémica o abrir el viejo debate otra vez, si no más bien enumerar algunas cosillas que hacen que *yo* me sienta más cómodo trabajando con C# que con VB, tanto a nivel de lenguaje como del propio editor. Lo remarco porque quiero que quede bien claro que es una opinión personal, ok? No se trata de comerle el coco a nadie…

Algunas de estas cosillas ya las he compartido con algunos de vosotros en algún evento de los grupos de usuarios, o simplemente delante de unas cervezas (aquí la conversación suele tornarse más pasional y tiende a alargarse un poco), jejeje…, y a decir verdad pocas veces nos ponemos de acuerdo ¿eh agüelo?. Parece ser que antes de empezar a hablar cada cual ya se ha posicionado y de aquí no nos movemos… lo cual es hasta cierto punto normal. Uno sabe con qué herramienta se encuentra más cómodo, aunque pueda usar ambas de forma indistinta.

De hecho he tirado más líneas de código con VB que con cualquier otro lenguaje, y eso que empecé en este mundillo con C y posteriormente con C++, para luego pasar a los lenguajes ‘más productivos’ como Delphi o finalmente VB en sus primeras versiones. No fue hasta 2002 y las primeras versiones de .NET que volví a usar la vieja sintaxis del punto y coma. De modo que VB en-todas-sus-variedades me es muy querido, y debo reconocerle sus ventajas… Sin embargo, codificar, al igual que leer o hablar, es algo que siempre haces mejor o te sientes más cómodo en uno de los lenguajes que dominas, y aquí reconozco que C# (como antes de conocerlo lo fue Java) es mi predilecto. Siempre que YO decido el lenguaje a utilizar en un nuevo proyecto, lo escojo, y en caso contrario intento convencer a la otra persona (ya sea compañero, cliente, etc.).

Os enumero a continuación una lista de cosas que me gustan de C#, o más bien que no me gustan cuando al cabo de un tiempo de trabajar con C#, me pongo a codificar con VB. No siguen ningún orden ni patrón y las voy a ir enumerando conforme se me vayan ocurriendo:

1) Escribo menos código && código más limpio:

En este punto, un desarrollador de VB acostumbra a decirme que esto no es cierto. Que si bien la sintaxis de VB es en alguno puntos ‘rocambolesca’ es para aclarar, y además el propio editor de código se encarga de escribirlo. Sin embargo tengo comprobado que con el editor de C# en la gran mayoría de las situaciones tecleo menos para decir lo mismo, y queda más claro (al menos para mí). Ojo! Es importante destacar que en ningún momento me mueve el afán de teclear menos, sino que el código resultante sea más legible. Comparemos los siguientes ejemplos:

Declarar una variable:

C#:

int x = 5;

VB:

Dim x As Int = 5

Bloques de código (ends por todas partes :-P).

C#:

if(Nombre == "Pepe" && Sueldo <= 500)
{
...
}

VB:

If Nombre = "Pepe" AndAlso Sueldo <= 500 Then
...
End If

Operador AddressOf

C#:

Thread t = new Thread(CountSheep);

VB:

Dim t As New Thread(AddressOf CountSheep)

Expresiones lambda:

C#:

Func<int, Func<int, int>> mult = (int x) => (int y) => x * y;

VB:

Dim mult As Func(Of Integer, Func(Of Integer, Integer)) = _    
Function(x As Integer) Function(y As Integer) x * y

Implementar una interfaz (no es preciso Implements):

C#:

interface ITest 
{ 
    string getValue();
}
 
class Test : ITest { 
    string getValue() 
    { 
        Random r = new Random(); 
        return r.Next().ToString(); 
    } 
}

VB:

Interface ITest    
    Function getValue() As String
End Interface 
 
Class Test    
    Implements ITest     
 
    Public Function getValue() As String Implements ITest.getValue
        Dim r As New Random
        Return r.Next().ToString()
    End Function
End Class

Podriamos seguir con Overridable, Overrides y unos cuantos más… Pero mejor vamos al siguiente punto que si no, no acabo el post hoy… :-)

2) No más underscores!

Cuantas veces he tenido que escuchar “no tengo porque terminar cada línea de código con un punto y coma!”. Pues precisamente, el delimitador de línea es lo que permite que en los lenguajes derivados del viejo y bueno ‘C’ no tengamos que hacer algo tan antinatural como partir las líneas de código con underscores (_). Además suele pasar que es una de las cosas que olvido con mayor rapidez, y cada vez que escribo en VB una query con LINQ acabo por soltar un “AAAAARGH!!! OTRA VEZ!!!”.

C#

List<int> nums = new List<int>(new int[] { 1, 2, 3, 4 });
var mynums = from n in nums
             where n < 5
             orderby n
             select n;

VB:

Dim nums As New List(Of Integer)(New Integer() {1, 2, 3, 4}) 
Dim mynums = From n In nums _ 
    Where n < 5 _ 
    Order By n _ 
    Select n 

3) Matrices y Listas: [] en lugar de ():

Cuando estoy picando o leyendo código me gusta saber con exactitud si estoy llamando a una función, a una propiedad u obteniendo el valor de una matriz o colección. Precisamente por eso prefiero usar corchetes en lugar de paréntesis para acceder a los miembros de una matriz o lista. En el ejemplo siguiente en la llamada a nums(i) en VB, podría ser tanto un método como una matriz, como una propiedad que devuelve una matriz o lista:

C#

List<int> nums = new List<int>(new int[] { 1, 2, 3, 4 });
Console.WriteLine(nums[2].ToString());

VB:

Dim nums As New List(Of Integer)(New Integer() {1, 2, 3, 4}) 
Console.WriteLine(nums(2).ToString()) 

4) Parámetros de salida (out):

Tipos de parámetro de salida. Estos son muy parecidos a los parámetros por referencia (ref), pero no necesitan ser inicializados. Resultan particularmente útiles en algoritmos recursivos. Visual Basic no dispone de nada equivalente, aunque si permite el paso de valores por referencia.

C#:

static void Method(out int i)
{
    i = 44;
}
static void Main()
{
    int value;
    Method(out value);
}

5) Los códigos de escape y las cadenas verbatim:

Otra cosa que me molesta es que VB no reconoce los carácteres de escape contenidos en un string. Esto es particularmente útil cuando deseamos mostrar un retorno de línea ‘n’ o una tabulación ‘t’ dentro de una cadena. En Visual Basic hay que recorrer a la concatenación de Environment.NewLine o artimañas parecidas como concatenar directamente el carácter. Por ejemplo el código siguiente se muestra así:

MessageBox.Show("holanquental");

 
C#:
 
MsgBox1

VB:

MsgBox2

En este punto más de uno se preguntará ¿y que pasa si no quiero tratar estos caracteres de escape como especiales?, ¿o si quiero mostrar una ruta de acceso que contiene varios caracteres ‘’? Bien, para ello tenemos varias alternativas: Podemos anteponer un carácter ‘’ a todo símbolo que deseemos mostrar literalmente o podemos usar cadenas verbatim (también llamado ‘literal de cadena textual’):

MessageBox.Show("C:\Windows\system32\Calc.exe");

 
MessageBox.Show(@"holanquental");

Las cadenas verbatim van incluso un poco más allá y permiten incluso poder partir una cadena en varias líneas, lo que clarifica en mucho el código:

MessageBox.Show(@"SELECT O.OrderID, O.CustomerID, O.EmployeeID, 
                O.OrderDate, O.RequiredDate, O.ShippedDate, 
                O.ShipVia, O.Freight, O.ShipName, O.ShipAddress, 
                O.ShipCity, O.ShipRegion, O.ShipPostalCode, 
                O.ShipCountry, C.CompanyName, C.Address, 
                C.City, C.Region, C.PostalCode, C.Country
                FROM dbo.Customers AS C 
                INNER JOIN dbo.Orders AS O 
                ON C.CustomerID = O.CustomerID");

6) Propiedades autogeneradas:

Algo tan sencillo como crear una propiedad para una clase, lo es todavía más en C#, ya que permite el uso de propiedades autogeneradas. Esto hace que el compilador maneje internamente una variable privada a nivel de clase para almacenar el valor, quedando esta parte oculta al desarrollador. Esta característica estará disponible en la próxima versión de Visual Basic, pero de momento todavía tenemos que conformarnos con representarlo así:

C#:

class Foo
{
    public int id { get; set; }
    public string name { get; set; }
}

VB:

Class Foo 
    Private _id As Integer 
    Public Property id() As Integer 
        Get 
            Return _id 
        End Get 
        Set(ByVal value As Integer) 
            _id = value 
        End Set 
    End Property 
    Private _name As String 
    Public Property name() As String 
        Get 
            Return _name 
        End Get 
        Set(ByVal value As String) 
            _name = value 
        End Set 
    End Property 
End Class

7) Refactoring:

Hoy en día, al igual que el uso de pruebas unitarias, empieza a ser impensable no refactorizar el código para una mejor comprensión, que repercute en un mejor índice de mantenibilidad (o Maintainability index, vaya usted a saber cómo se traduce) del código. Bien, pues el menú ‘Refactor’ del editor de C# no aparece en VB. Y la única información acerca de refactorizar el código VB nos enlaza con un Add-In de terceros, la cual a decir verdad es una gran utilidad. Lo sé, porque he usado la versión PRO de este producto durante bastante tiempo. Pero el hecho es que Visual Studio no incorpora ninguna utilidad ‘de fábrica’ para refactorizar el código, lo que no deja de ser sorprendente…

RefactorMenu

8) Posibilidad de desactivar ‘Strict on’:

Al ser VB la evolución de un lenguaje no tan ‘estricto’ como C#, nos ofrece la posibilidad de desactivar la opción Strict On, y de este modo dejar que el compilador se encargue de realizar muchas conversiones implícitas. Pero lo más peligroso de todo es que la opción viene desactivada ‘de fábrica’ y en cambio no conozco ningún buen programador de VB (que los hay, y muchos) que no sea lo primero que active. Muchos errores en tiempo de ejecución podrían ser evitados si el propio compilador nos obligase a codificar correctamente, en lugar de actual de este modo más ‘relajado’:

VB (con Option Strict Off):

Dim s As String
s = DateTime.Today

VB (con Option Strict On):

Dim s As String
s = DateTime.Today.ToString()

Observar que con Option Strict activado, el compilador no permite asignar una fecha a una variable de tipo cadena (con razón!), de modo que para poder compilar debemos realizar una conversión explícita.

Recomiendo dar un vistazo a este artículo de coding horror:

http://www.codinghorror.com/blog/archives/000355.html

9) Microsoft.VisualBasic:

Son legión los programadores que provienen de versiones anteriores de .NET (6 o anteriores), de modo que para facilitarles el camino los proyectos de VB incorporan el espacio de nombres Microsoft.VisualBasic, el cual a su vez incorpora muchas de las funciones de estas versiones anteriores. El hecho de incorporarlas no es un error en sí, lo malo es que estas funciones tienen su equivalente en el modelo de objetos del framework, y si seguimos usando estas funciones ‘antiguas’ no aprenderemos las nuevas, y el día en que debamos trabajar con otro lenguaje del Framework (que no tiene porque ser C#, hay unos cuantos más :-P) nos encontraremos con que estamos usando funciones propias de VB y no conoceremos su equivalente.

ObjectExplorer

Por ejemplo, en lugar de llamar a la función Len para averiguar el número de caracteres de una cadena, es mejor usar el método Lenght de la clase String, lo mismo para Trim(), y todavía es más flagrante con Mid(), que equivale al método SubString del objeto String:

Dim n As Integer = Len(DateTime.Now.ToLongDateString)    'NO
Dim n As Integer = DateTime.Now.ToLongDateString.Lenght  'SI


No son pocos los esfuerzos de muchos compañeros, fantásticos programadores como Jorge Serrano o Harvey Triana para eliminar esta librería de nuestras aplicaciones, de modo que la recomendación siempre acaba siendo “no la uses, no la mires, haz como si no estuviera…”. Por cierto, os recomiendo una lectura de ambos artículos.
10) Hay más, y no se por cual decidirme…

Hay muchas otras cosas que se quedan en el tintero, porque algunas de ellas son demasiado largas (como el manejo de eventos), y otras no son precisamente de uso diario, como la ejecución de código no seguro (unsafe). Pero estaremos de acuerdo en que la mayoría de las novedades aparecen primero para C# (inicializadores de colecciones, propiedades autogeneradas, soporte para expresiones lambda ‘de verdad’, etc.) e incluso los compiladores de C# del proyecto MoNo van siempre por delante de los de VB. Aunque este último punto reconozco que no es demasiado importante… o sí?

En fin, vaya chapa me ha salido! Pero por lo menos ahora tengo una lista de cosas para cuando me pregunten “¿porque te gusta más C# que VB?”.

Un saludo desde Andorra,

Mi primera revisión de BillG

Spolsky-Small

Siempre me ha encantado leer los artículos de Joel Spolsky, y ayer mientras buscaba otra cosa me topé con un artículo que había leído hace un tiempo (por aquel entonces en su versión original) y que me había gustado mucho. En este artículo Joel nos cuenta la história de su primera revisión con el tío Bill, allá por 1994 cuando trabajaba en Microsoft. Os dejo el artículo traducido al español y os animo a darle una ojeada al resto de artículos de Joel. Vale la pena…

Mi primera revisión de BillG

En la ‘antigüedad’, Excel tenía un lenguaje de programación sin nombre bastante incómodo. Lo llamábamos “Excel Macros”. Era un lenguaje de programación gravemente disfuncional, sin variables (tenías que almacenar los valores en celdas de una hoja de cálculo), sin locals, sin llamadas a subrutinas: en resumen, era completamente insostenible. Tenía características avanzadas como “Goto” pero las etiquetas eran físicamente invisibles, en realidad.

Lo único que lo hacía parecer razonable era que se veía genial comparado con las macros de Lotus, que no eran más que una secuencia de pulsaciones de teclado introducidas como una larga cadena en una celda de una hoja de cálculo.

El 17 de junio de 1991, empecé a trabajar para Microsoft en el equipo de Excel. Mi título era “Jefe de programa”. Se suponía que debía aportar una solución a este problema. Y que la solución tendría que ver con el lenguaje de programación Basic

¿Basic? ¡Puagh!

Pasé algún tiempo negociando con varios grupos de desarrollo. Visual Basic 1.0 acababa de salir, y era jodidamente guay. Había un esfuerzo descaminado en proceso con el nombre en código MacroMan, y otro esfuerzo para crear Basic Orientado a Objetos con el nombre en código “Silver”. Al equipo de Silver se le había dicho que tenían un cliente para su producto: Excel. El jefe de marketing de Silver, Bob Wyman, si, ese Bob Wyman, solo tenía una persona a quien vender esa tecnología: a mí.

Macroman, como he dicho, iba descaminado, y costó un poco de persuasión, pero finalmente fue cancelado. El equipo de Excel convenció al de Basic de que lo que realmente necesitábamos era una especie de Visual Basic para Excel. Conseguí que se añadieran cuatro características que me gustaban a Basic. Hice que añadieran Variantes, un tipo de dato unión que podía almacenar cualquier otro tipo, porque en otro caso no podrías almacenar los resultados de una celda de hoja de cálculo sin una sentencia switch. Hice que añadieran ‘late binding’, que luego se llamó IDispatch, también conocido como COM Automation, porque el diseño original de Silver requería de un profundo conocimiento de sistemas de tipos del que el tipo de gente que programa macros no se preocupa. Y conseguí que incluyeran dos características sintácticas que me gustaban en el lenguaje: For Each, robado de csh, y With, robado de Pascal.

Entonces me senté a escribir la especificación de Excel Basic, un documento enorme que creció hasta tener varios centenares de páginas. Creo que cuando se terminó tenía 500 páginas.(“Vaya montón”, te ríes por debajo; ya, ya, cállate).

En aquella época, solíamos tener estas cosas llamadas revisions de BillG. Básicamente, cada característica principal importante era revisada por Bill Gates. Me dijeron que mandara una copia de mi especificación a su oficina como preparación para la revisión. Era básicamente un taco de folios impresos a láser.

Me apresuré a imprimir la especificación y la mandé a su oficina.

Más tarde ese día, tuve un poco de tiempo, así que empecé a trabajar intentando comprender si Basic tenía suficientes funciones de fecha y hora para realizar todo lo que podías hacer en Excel.

En la mayoría de entornos de programación modernos, las fechas están almacenadas como números reales. La parte entera del número es el número de días desde una fecha acordada del pasado, llamada la ‘epoch’. En Excel, la fecha actual, 16 de junio de 2006, se almacena como 38884 días desde el 1 de enero de 1900, que sería 1.

Empecé a investigar las diferentes funciones de fecha y hora de Basic y las de Excel, probando cosas, hasta que me dí cuenta de algo extraño en la documentación de Visual Basic.: Basic usa como ‘epoch’ el 31 de diciembre de 1899 en vez del 1 de enero de 1900, pero, por alguna razón, la fecha actual era la misma en Excel y en Basic.

Ein?

Busqué un desarrollador de Excel lo suficientemente viejo como para recordar por qué. Ed Fries parecía conocer la respuesta.

“Oh,” me dijo, “Prueba el 28 de febrero de 1900”.

“Es 59”, le dije.

“Prueba ahora el 1 de marzo”.

“¡Es 61!”

“¿Qué le ha pasado al 60?” preguntó Ed.

“El 29 de febrero. ¡1900 fue un año bisiesto! ¡Es divisible por 4!”

“Buen intento, pero no”, dijo Ed, y me dejó pensando un rato.

Ups. Investigué un poco. Los años que son divisibles por 100 no son años bisiestos, a menos que también sean divisibles por 400. 1900 no era un año bisiesto.

“¡Es un bug en Excel!” exclamé.

“Bueno, en realidad no” dijo Ed. “Tuvimos que hacerlo así porque necesitábamos poder importar hojas de cálculo de Lotus 123”.

“¿Así que es un bug en Lotus 123?”.

“Sí, pero probablemente uno intencionado. Lotus tenía que caber en 640K. Eso no es mucha memoria. Si ignoras a 1900, puedes calcular si un año dado es bisiesto mirando si los dos bits más a la derecha son cero. Es muy rápido y sencillo. Lo tipos de Lotus probablemente pensaron que no importaba equivocarse para esos dos meses tan antiguos. Parece que los tipos de Basic quisieron ser meticulosos con esos dos meses, así que movieron la ‘epoch’ un día hacia atrás.

“¡Argh!” dije, y me fui a estudiar por qué había un checkbox en el cuadro de diálogo de opciones con el nombre Sistema de Fecha 1904.

El día siguiente era la gran revisión de BillG.

30 de Junio de 1992.

En aquella época, Microsoft era mucho menos burocrática. En vez de las 11 o 12 capas de gestión que tienen hoy en día, yo dependía de Mike Conte que dependía de Chris Gram. que dependía de Pete Higgins, que dependía de Mike Maples, que dependía de Bill. Unas 6 capas desde arriba hasta abajo. Nos reíamos de compañías como General Motors ,con sus 8 capas de gestión, o las que fueran.

En la reunión de mi revisión de BillG, toda la jerarquía de dependencias estaba allí, junto con sus primos, hermanas y tías, y una persona que vino de mi equipo cuya única función durante la reunión era contar cuántas veces decía Bill la ‘palabra J’. Cuanto menor fuera la cuenta-j*d*r, mejor.

Bill entró.

Pensé lo extraño que era que tuviera dos piernas dos brazos, una cabeza, etc. Casi como un ser humano normal.

Tenía mi especificación en la mano.

Tenía mi especificación en la mano.

Se sentó e intercambió con un ejecutivo que yo no conocía bromas que no tenían sentido para mí. Unas cuantas personas se rieron.

Bill se giró hacia mí.

Me di cuenta de que había comentarios escritos en los márgenes de mi especificación. ¡Se había leído la primera página!

¡Se había leído la primera página de mi especificación y había escrito pequeñas notas en el margen!

Considerando que sólo le habíamos dado la especificación 24 horas antes, debía habérsela leído la noche anterior.

Él hacía preguntas. Yo las respondía. Eran bastante sencillas, pero por mi vida que soy incapaz de recordar cuáles eran, porque no podía evitar darme cuenta de que él estaba hojeando la especificación…

¡Estaba hojeando la especificación! [Cálmate, ¿qué eres? ¿una niña?]

… y HABÍA NOTAS EN TODOS LOS MÁRGENES. EN CADA PÁGINA DE LA ESPECIFICACIÓN. SE HABÍA LEÍDO TODA LA MALDITA COSA Y HABÍA ESCRITO NOTAS EN LOS MÁRGENES.

¡Se la había leído entera! [¡OH DIOS MÍO SIIIIIIIIIIII!]

Las preguntas se fueron haciendo más difíciles y detalladas.

Parecían un poco aleatorias. En ese punto me había acostumbrado a pensar en Bill como mi colega. ¡Es un tío majo! ¡Se ha leído mi especificación! ¡Probablemente sólo quiere hacerme algunas preguntas sobre los comentarios en los márgenes! ¡Abriré un bug en el bug tracker por cada uno de sus comentarios y me aseguraré de que se solucione, pronto!

Finalmente, la pregunta trampa.

“No sé, tíos” dijo Hill, “¿Alguien ha mirado realmente todos los detalles de cómo hacer esto? Como todas esas funciones de fecha y hora. Excel tiene tantas. ¿Basic va a tener las mismas funciones? ¿Van a funcionar de la misma forma?”

“Si,” dije, “excepto para enero y febrero de 1900.

Silencio.

El contador-de-j*d*r*s y mi jefe intercambiaron miradas de asombro. ¿Cómo supiste eso? ¿Enero y febrero QUÉ?

“OK. Bueno, buen trabajo” dijo Hill. Cogió su copia anotada de la especificación

…¡espera! Quiero eso…

y se fue.

“Cuatro”, anunció el contador-de-j*d*r*s, y todo el mundo dijo “Guau, es el número más bajo que puedo recordar. Bill se está suavizando con la edad”. El tenía, ya sabes, 36.

Más tarde me lo explicaron. “Bill no quiere revisar realmente tu especificación, sólo quiere asegurarse de que lo tienes bajo control. Su modus operandi estándar es hacer preguntas cada vez más y más difíciles hasta que admitas que no sabes la respuesta, y entonces él pueda gritarte por no estar preparado. Nadie estaba realmente seguro de que pasaría si respondías la pregunta más difícil que se le pudiera ocurrir, porque no había pasado antes.”.

“¿Os imagináis si Jim Manzi hubiera estado en esa reunión?” preguntó alguien. “Habría preguntado: ‘¿Qué es una función de fecha?’”.

Jim Manzi era el MBA que estaba hundiendo a Lotus.

Era algo importante. Bill Gates era increíblemente técnico. Entendía los Variants, y los objetos COM, y IDispatch, y porqué Automation es diferente de las vtables y porqué podría llevar a interfaces duales. Se preocupaba de las funciones de fecha. No se entrometía en el software si confiaba en la gente que estaba trabajando en él, pero no podías engañarle ni un minuto porque era un programador. Un verdadero programador.

Ver a no-programadores intentando dirigir empresas de software es como ver a alguien que no sabe hacer surf intentar practicarlo.

“¡Está bien! ¡Tengo grandes consejeros diciéndome qué hacer!” dicen, y luego se caen de la directiva, una y otra vez. El grito estándar del MBA que cree que la gestión es una función genérica. ¿Es Ballmer otro John Sculley, que casi llevó a Apple a la extinción porque la directiva pensó que vender Pepsi esa una buena preparación para dirigir una empresa de computadoras? Al culto del MBA le gusta creer que puedes dirigir organizaciones que hacen cosas que no entiendes.

A lo largo de los años, Microsoft se hizo grande, Bill se dedicó a demasiadas cosas, y algunas decisiones éticamente turbias hicieron necesario dedicar demasiada atención de la gestión a luchar contra el gobierno de los Estados Unidos. Steve cogió el puesto de CEO porque en teoría permitiría a Bill dedicar más tiempo a lo que hace mejor, dirigir la organización de desarrollo de software, pero eso no pareció arreglar problemas endémicos causados por esas 11 capas de gestión, una cultura de reuniones permanentes, perpetuas, una terca insistencia en crear cada posible producto, fuera como fuera,(¿Cuántos miles de millones de dólares ha perdido Microsoft en Investigación y Desarrollo, costes legales y daño a su reputación, porque decidieron que no sólo tenían que crear un navegador web, sino además darlo gratis?), y un par de décadas de contrataciones descuidadas y apresuradas ha asegurado que la capacidad intelectual del empleado de Microsoft medio se haya hundido (Douglas Coupland, en Microsiervos: “Contrataron a 3.100 personas sólo en 1992, y sabes que no todos fueron joyas.”).

Oh, bueno. La fiesta se ha movido a otra parte. Excel Basic se convirtió en Microsoft Visual Basic para Aplicaciones para Microsoft Excel, con tantos (TM)’s y (R)’s que no sé dónde ponerlos. Dejé la compañía en 1994, creyendo que Bill me había olvidado completamente, hasta que descubrí una pequeña entrevista a Bill Gates en el Wall Street Journal en la que mencionó, casi de pasada, algo en la línea de lo difícil que era contratar, digamos, un buen jefe de programa para Excel. No crecen en los árboles, o algo así.

¿Podría estar hablando de mí? Naaa, probablemente era sobre otra persona.

Aunque…

Artículo traducido al español por David Vilches:
http://local.joelonsoftware.com/mediawiki/index.php/Mi_primera_revisi%C3%B3n_de_BillG

Artículo original en inglés:
http://joelonsoftware.com/items/2006/06/16.html

Saludos desde Andorra,