cap02 revisar ortografia

chapter02.md

@@ -24,13 +24,13 @@ Hay muchas medidas que la gente usa para clasificar a los programadores. Es prob
 
 El mayor problema con la clasificación de programadores (o en cualquier caso, clasificación de cualquier cosa) es que los sistemas de clasificación están basados en una serie de criterios. No hay un estándar real para clasificar programadores. Los sitios donde se clasifica y puntúa programadores en base a un número de problemas resueltos o la dificultad de los problemas resueltos solo han determinado que hay una serie de programadores que realmente disfrutan resolviendo esa clase de problemas. También han reunido a un grupo de programadores que dedicarán tiempo y esfuerzo a resolver estos problemas y serán competitivos mientras los resuelven. Nos dice poco sobre las habilidades del programador fuera de esa materia.
 
-También hay otras medidas para clasificar a los programadores. Una medida clásica es revisar cuántas líneas de código usó un programador para resolver un problema (esto a veces se denomina "código de golf", donde cuanto menor sea el número de líneas de código, mejor será la solución). Podemos argumentar cómo de "limpia" es la solución (limpia es otro término algo nebuloso y poco concreto). Podemos determinar la "notación Big O", una notación utilizada para describir el rendimiento o la complejidad de los algoritmos que un programador utilizó en su código. Podemos hacer una prueba de _estres_ o de esfuerzo del código para determinar cómo de bien se adapta el código a diversas circunstancias. Podemos contar la cantidad de ciclos que requiere un código en particular para ejecutarse y compararlo con un código similar. Muy poco de esto nos dice algo sobre un programador en particular. Lo que sí nos dice es que el programador tiene experiencia que lo lleva a esa solución en particular. Nos dice que el programador ha visto este tipo de problemas antes y se preocupó lo suficiente por el problema como para pensar lo suficiente sobre cómo hacer una mejor solución. Aprendemos que el programador dedicó tiempo y energía a practicar este tipo de problemas. Lo que no nos muestra es una medida general de las habilidades o capacidades del programador. Es similar al cuento apócrifo de un profesor brillante. Este profesor era un genio absoluto en su campo y era una de las personas a las que acudir para obtener respuestas sobre su tema, pero a pesar de su brillantez, no sabía cómo cambiar un neumático en un automóvil. ¿Significa eso que el profesor no era tan brillante como la gente decía que era? Difícilmente. Significa que el profesor pasó más tiempo pensando en su profesión que pensando en cambiar neumáticos. Lo mismo es cierto también para los programadores. Si un programador pasa la mayor parte de su tiempo resolviendo un conjunto particular de problemas, eventualmente se volverá experto en ese tipo de problemas. Pero si ese programador se atasca con un tipo diferente de problemas, eso no descarta sus habilidades generales, simplemente señala las áreas en las que podrían querer trabajar.
+También hay otras medidas para clasificar a los programadores. Una medida clásica es revisar cuántas líneas de código usó un programador para resolver un problema (esto a veces se denomina "código de golf", donde cuanto menor sea el número de líneas de código, mejor será la solución). Podemos argumentar cómo de "limpia" es la solución (limpia es otro término algo nebuloso y poco concreto). Podemos determinar la "notación Big O", una notación utilizada para describir el rendimiento o la complejidad de los algoritmos que un programador utilizó en su código. Podemos hacer una prueba de _estrés_ o de esfuerzo del código para determinar cómo de bien se adapta el código a diversas circunstancias. Podemos contar la cantidad de ciclos que requiere un código en particular para ejecutarse y compararlo con un código similar. Muy poco de esto nos dice algo sobre un programador en particular. Lo que sí nos dice es que el programador tiene experiencia que lo lleva a esa solución en particular. Nos dice que el programador ha visto este tipo de problemas antes y se preocupó lo suficiente por el problema como para pensar lo suficiente sobre cómo hacer una mejor solución. Aprendemos que el programador dedicó tiempo y energía a practicar este tipo de problemas. Lo que no nos muestra es una medida general de las habilidades o capacidades del programador. Es similar al cuento apócrifo de un profesor brillante. Este profesor era un genio absoluto en su campo y era una de las personas a las que acudir para obtener respuestas sobre su tema, pero a pesar de su brillantez, no sabía cómo cambiar un neumático en un automóvil. ¿Significa eso que el profesor no era tan brillante como la gente decía que era? Difícilmente. Significa que el profesor pasó más tiempo pensando en su profesión que pensando en cambiar neumáticos. Lo mismo es cierto también para los programadores. Si un programador pasa la mayor parte de su tiempo resolviendo un conjunto particular de problemas, eventualmente se volverá experto en ese tipo de problemas. Pero si ese programador se atasca con un tipo diferente de problemas, eso no descarta sus habilidades generales, simplemente señala las áreas en las que podrían querer trabajar.
 
 ## Midiendo el rendimiento del programador
 
-También hay una tendencia a medir la productividad del programador por cuántas contribuciones puede hacer el programador a un proyecto. Bajo ciertos sistemas de control de versiones, estos se denominan _commits_. Enumeran un conjunto de cambios que el programador desea realizar en el código. En una era en la que existen sitios para escribir código de manera colaborativa y social como Github o Gitlab, podemos revisar fácilmente los _commits_ que están realizando otros programadores. Dado que podemos medir la cantidad de _coomits_, podemos usar esta medida para sentir que no estamos generando la misma cantidad y frecuencia de _coomits_ que otros programadores. Y a diferencia de las medidas de antaño (líneas de código en particular, que mide cuántas líneas de código añade un programador a un programa), podemos revisar la calidad de sus _commits_ con un proyecto. Puede ser desalentador ver una gran cantidad de trabajo de calidad realizado por nuestros compañeros. También puede ser fuente de frustración y sentimientos de insuficiencia. "¿Por qué no puedo ser tan productivo o contribuir como esta otra persona?" nos preguntamos.
+También hay una tendencia a medir la productividad del programador por cuántas contribuciones puede hacer el programador a un proyecto. Bajo ciertos sistemas de control de versiones, estos se denominan _commits_. Enumeran un conjunto de cambios que el programador desea realizar en el código. En una era en la que existen sitios para escribir código de manera colaborativa y social como Github o Gitlab, podemos revisar fácilmente los _commits_ que están realizando otros programadores. Dado que podemos medir la cantidad de _commits_, podemos usar esta medida para sentir que no estamos generando la misma cantidad y frecuencia de _commits_ que otros programadores. Y a diferencia de las medidas de antaño (líneas de código en particular, que mide cuántas líneas de código añade un programador a un programa), podemos revisar la calidad de sus _commits_ con un proyecto. Puede ser desalentador ver una gran cantidad de trabajo de calidad realizado por nuestros compañeros. También puede ser fuente de frustración y sentimientos de insuficiencia. "¿Por qué no puedo ser tan productivo o contribuir como esta otra persona?" nos preguntamos.
 
-Es incluso todavía más frustrante cuando otras personas utilizan estas médidas para judgar la productividad y las contribuciones con código. Podemos encontrarnos siendo criticados por nuestros resultados (o la falta de estos).
+Es incluso todavía más frustrante cuando otras personas utilizan estas medidas para judgar la productividad y las contribuciones con código. Podemos encontrarnos siendo criticados por nuestros resultados (o la falta de estos).
 
 Los _commits_ y las líneas de código son las medidas más visibles de la productividad al crear código, pero no muestran mucho sobre la práctica real de la programación. No podemos medir la cantidad de tiempo que dedicamos a pensar en el problema con solo mirar un _commit_. No vemos las montañas de material de referencia que usó el programador para encontrar una solución y ciertamente no sabemos si este _commit_ es el resultado de una tarde de trabajo o de muchos días de trabajo (a menos que se hagan _commits_ con más frecuencia). Incluso podríamos descubrir que esta persona está actuando como el punto central de una organización y está integrando el trabajo de varias personas en sus _commits_.
 
@@ -48,6 +48,6 @@ El sacar nuestros egos de la pregunta nos permite estar más abiertos a las resp
 
 Por supuesto, hay personas que no responderán pensando en lo mejor para ti y solo están interesadas en imponerte su propia visión del mundo. En lugar de responder a tu pregunta, cuestionan por qué estás haciendo eso y en su lugar sugieren que deberías usar su metodología. Puede requerir mucha energía enfrentarse con estas personas y decirles "no, realmente tenía la intención de aprender más sobre X". Me gustaría tener buenas respuestas sobre cómo manejar a este tipo de personas. Muchas de estas personas sienten que cualquier cosa que estén haciendo es el único camino correcto y aquellas personas que se desvían de su camino elegido son anatema para su mundo. Mi mejor sugerencia es agradecerles su tiempo y pedir ayuda a alguien más. Tal vez puedan ser útiles en el futuro cuando tenga preguntas sobre lo que sea que sea parte de su agenda, pero por ahora conviene ser lo más amable posible y desearles lo mejor en su viaje de programación. Los espacios tecnológicos tienen mucha gente que ha estado trabajando con computadoras durante mucho tiempo y se ha formado opiniones sólidas sobre sus herramientas y tecnologías. Mi esperanza es que puedas encontrar a los que también son amables y están dispuestos a compartir lo que saben y no acosarte con sus creencias arraigadas. Con el tiempo, también formarás tus propias creencias sobre lo que funciona y lo que no funciona y transmitirás ese conocimiento a los demás. Reconocer a las personas que están ahí para ayudar a educar y a las que están ahí para hacer proselitismo es parte de nuestro proceso de crecimiento.
 
-Si vemos a otros programadores como compañeros de viaje en esta travesía, como colegas en nuestra práctica a la hora de crear código, entonces nos daremos cuenta que estamos en esto todos juntos. Incluso alguien con muchos más años de experiencia que nosotros es tu colega. Tienes conocimientos y experiencia que ellos no tendrán y ellos tienen experiencias y conocimientos que tu no tienes. Si nos despojamos de las barreras del estatus que percivimos y de la meritocracia de esas personas podremos entendernos mejor aprender unos de otros.
+Si vemos a otros programadores como compañeros de viaje en esta travesía, como colegas en nuestra práctica a la hora de crear código, entonces nos daremos cuenta que estamos en esto todos juntos. Incluso alguien con muchos más años de experiencia que nosotros es tu colega. Tienes conocimientos y experiencia que ellos no tendrán y ellos tienen experiencias y conocimientos que tu no tienes. Si nos despojamos de las barreras del estatus que percibimos y de la meritocracia de esas personas podremos entendernos mejor aprender unos de otros.
 
 El viaje para llegar a ser un programador mejor es largo y duro. Necesitamos los mejores compañeros que podamos encontrar para ayudarnos en este viaje. Necesitamos algo más que únicamente compañeros que tengan muy buenos conocimientos técnicos, también necesitamos compañeros con los que podamos hablar cuando la jornada termina. Necesitamos compañeros con los que podamos sentarnos alrededor de la fogata proverbial e imaginaria donde juntos podamos reír y compadecernos de nuestras luchas.