cap02 finalizar traducc

chapter02.md

@@ -4,50 +4,50 @@
 
 A través de la historia de la computación ha habido personas que han demostrado increíbles capacidades a la hora de crear código. Residen en el panteón de los grandes programadores informáticos: Ada Lovelace (la primera programadora de computadoras), Dennis Ritchie (el creador del lenguaje de programación C), Rear Admiral Grace Murray Hopper (creador de COBOL y acreditado por encontrar el primer "error" (_N. del traductor: un error informático en inglés es llamado "bug" que también se puede traducir como bicho o insecto_) informático documentado) y muchos más. También tenemos desarrolladores en nuestras propias comunidades que tienen un cierto grado de notoriedad, ya sean las personas que escribieron el lenguaje de programación que usamos actualmente, las personas que mantienen el sistema operativo que usamos o alguien que saltó a la fama en nuestra comunidad preferida. Puede ser intimidante cuando nos comparamos con estas grandes personas. Después de todo, cualquier cosa en la que estemos trabajando actualmente podría no estar a la altura de lo que ellos hayan hecho. Peor aún, podemos estar trabajando en algo similar y sentir que cualquier cosa en la que estemos trabajando nunca estará a la altura de lo que estas personas han logrado. Incluso podemos ser amigos de programadores que parecen resolver las cosas mucho más rápido y de una manera más elegante que nosotros y maravillarnos de cómo parecen tener este cuerpo de conocimiento al alcance de la mano que posiblemente no podamos entender.
 
-## Backstage vs. performance
+## Entre bastidores frente a la actuación final
 
-One of the best pieces of advice I have received about comparing ourselves to others is realizing that the comparison is between our backstage versus their performance. The metaphor draws from the theater, where performers know every thing that isn't right about their own theater-group's performance and unfairly compare it with another theater-group's finished performance. This metaphor is useful to us because we tend to compare all of the things that we know (the long hours of unproductive coding, the struggles with learning, and so forth) with the finished product of someone else. We don't see their struggle in getting things to work, or their countless hours making crappy prototypes and unfinished projects before making the thing we admire. Allow yourself to have a messy back-stage and do plenty of rehearsals and understand that it takes effort and practice to put on a good performance.
+Uno de los mejores consejos que he recibido sobre compararnos con los demás es darnos cuenta de que la comparación es entre nuestra vida entre bastidores _versus_ la actuación final que ven los espectadores. La metáfora se basa en el teatro, donde los artistas saben todo lo que no está bien sobre la actuación de su propio grupo de teatro y lo comparan injustamente con la actuación final de otro grupo de teatro. Esta metáfora es útil en nuestro caso porque tendemos a comparar todas las cosas que sabemos (las largas horas de crear código improductivas, las dificultades para aprender, etc.) con el producto final de otra persona. No vemos su lucha para hacer que las cosas funcionen, o sus innumerables horas haciendo prototipos de mierda y proyectos sin terminar antes de hacer lo que admiramos. Permítete tener un lugar entre bastidores desordenado y hacer muchos ensayos, y comprende que se necesita esfuerzo y práctica para realizar una buena actuación.
 
-## The lure of the post-mortem
+## El atractivo del post-mortem
 
-There's a tradition in some programming projects (especially in game development projects where there is a clear end to the project when the product ships) of doing a post-mortem on the project. What the post-mortem does is allow the developers of a project to state what went right and what didn't go right. The better ones tend to be frank accounts of the successes and failures of a project.
+Hay una tradición en algunos proyectos de programación (especialmente en proyectos de desarrollo de juegos donde hay un final claro para el proyecto cuando se envía el producto) de hacer una autopsia del proyecto. Lo que hace la autopsia es permitir que los desarrolladores de un proyecto indiquen lo que salió bien y lo que no salió bien. Las mejores autopsias tienden a ser relatos francos de los éxitos y fracasos de un proyecto.
 
-The post-mortem can be a fascinating look into the development of a project. I've found myself reading a lot of these looking for insights into the development process. But there's a subtle trap in the post-mortem: they're a recollection of events from the vantage point of a successful (or unsuccessful) project. They're a recollection of someone who worked on a project that was successful enough for you to spend time reading about that project's ups and downs. They're written from a perspective where the success of the project is a foregone conclusion (or they're written about projects that were noteworthy in how they failed or didn't meet the expectations of those involved). It can lead to the belief that what you're working on is not as important as the things that other people are working on. But we don't know the importance of our project in real-time. Even the folks in the post-mortem didn't know if their project would work or be successful as they were working on it. Our projects may never see the light of day, or they might be something that changes the world. We can't know the value of what we're working on while we're working on it (though we can have a sense of whether or not we _feel_ our work is important).
+La autopsia puede ser una mirada fascinante al desarrollo de un proyecto. Me he encontrado leyendo muchas de estas en busca de información sobre el proceso de desarrollo. Pero hay una trampa sutil en la autopsia: son un recuerdo de eventos desde el punto de vista de un proyecto exitoso (o fallido). Son un recuerdo de alguien que trabajó en un proyecto que fue lo suficientemente exitoso como para que tu dediques tiempo a leer sobre los altibajos de ese proyecto. Están escritos desde una perspectiva en la que el éxito del proyecto es una conclusión inevitable (o están escritos sobre proyectos que se destacaron por cómo fallaron o no cumplieron con las expectativas de los involucrados). Puede llevar a la creencia de que en lo que estás trabajando no es tan importante como las cosas en las que están trabajando otras personas. Pero no sabemos la importancia de nuestro proyecto en tiempo real. Incluso la gente en la autopsia no sabía si su proyecto funcionaría o tendría éxito mientras trabajaban en él. Es posible que nuestros proyectos nunca vean la luz del día o que sean algo que cambie el mundo. No podemos saber el valor de aquello en lo que estamos trabajando mientras lo hacemos (aunque podemos tener una idea de si _sentimos_ que nuestro trabajo es importante o no).
 
-A post-mortem also has the benefit of hindsight. Decisions that were clear and definite at the time might not make much sense when viewed with data obtained later in the project's lifespan. There's also an issue with "selective memory" where something might not be remembered with the same clarity, or may be conflated with other events. Confident statements like "We knew this one thing wouldn't have worked" might actually have been "We weren't sure if this would work so we tried several things. They all didn't work.". Consider anyone writing about their past as an unreliable narrator. True, they may be the best and most knowledgeable narrator we have, but they do not have an objective perspective on whatever they were creating. They have their own biases and reasons for the stories they present in a post-mortem. Treat a post-mortem like you would treat an auto-biography of a famous person: a primary source with an agenda to show the subject in the best way possible.
+Una autopsia también tiene el beneficio de la retrospectiva. Las decisiones que eran claras y definitivas en ese momento podrían no tener mucho sentido cuando se las compara con los datos obtenidos más adelante en la vida útil del proyecto. También hay un problema con la "memoria selectiva" en la que es posible que algo no se recuerde con la misma claridad o se combine con otros eventos. Declaraciones confiadas como "Sabíamos que esto no habría funcionado" en realidad podrían haber sido "No estábamos seguros de si esto funcionaría, así que probamos varias cosas. Todas no funcionaron". Considera a cualquiera que escriba sobre su pasado como un narrador poco confiable. Cierto, pueden ser los mejores y más informados narradores que tenemos, pero no tienen una perspectiva objetiva de lo que sea que estaban creando. Tienen sus propios prejuicios y razones para las historias que presentan en una autopsia. Trate una autopsia como trataría una autobiografía de una persona famosa: una fuente primaria con una agenda para mostrar el tema de la mejor manera posible.
 
-There's nothing wrong with reading a post-mortem about a project --- we can learn a great deal about how a project is run (or shouldn't be run) and what pitfalls to be aware of if we go down a similar path, but understand that you're reading one account (whether by one person or one team of people). They have the perspective of someone deep in the conflict. You're looking at their recollections of tactics, not the overall strategy that brought that them to the place.
+No hay nada de malo en leer una autopsia sobre un proyecto; podemos aprender mucho sobre cómo se ejecuta un proyecto (o no se debe ejecutar) y qué peligros debemos tener en cuenta si seguimos un camino similar, pero comprende que estás leyendo un informe (ya sea de una persona o de un equipo de personas). Tienen la perspectiva de alguien profundamente involucrado en el conflicto. Estás mirando sus recuerdos de tácticas, no la estrategia general que los trajo al lugar.
 
-## Ranking programmers
+## Clasificación de programadores
 
-There are many metrics which folks use to rank programmers. You've likely seen these metrics manifest themselves in different ways: competition sites, numbers of commits to projects, productivity measurements, time to turn-around code, and good ol' fashioned gut feelings. We do it to ourselves and others. We compare our work against the work of our peers and folks that we admire, but that can lead us to make comparisons that aren't objective or based on all of the data. I can compare myself against folks who do low-level programming and find that I don't measure up in that realm. Never mind that I haven't done a whole lot of low-level programming; the comparison is valid. Or, I can compare myself against folks who were mentored by programmers whose names are legendary in the field. I will find gaps between my knowledge and their knowledge, because I didn't have access to those mentors (or worse: I didn't take advantage of the mentors I could have accessed. Whoops!). Comparisons like these are not helpful and lead us into punishing ourselves for not being someone else. Our assessment of our projects and history give us the conclusion that we're not that other person, nor could we ever be that other person.
+Hay muchas medidas que la gente usa para clasificar a los programadores. Es probable que hayas visto que estas medidas se manifiestan de diferentes maneras: sitios de competencia, números de _commits_ en un proyecto, medidas de productividad, tiempo para entregar el código y los buenos sentimientos viscerales que podamos sentir como se hacía antiguamente. Nos lo hacemos a nosotros mismos y a los demás. Comparamos nuestro trabajo con el trabajo de nuestros compañeros y gente que admiramos, pero eso puede llevarnos a hacer comparaciones que no son objetivas o no se basan en todos los datos. Puedo compararme con personas que hacen programación de bajo nivel y encontrar que no estoy a la altura en ese ámbito. No importa que no haya hecho mucha programación de bajo nivel; la comparación es válida. O puedo compararme con personas que fueron asesoradas por programadores cuyos nombres son legendarios en su campo. Encontraré brechas entre mi conocimiento y el de ellos, porque no tuve acceso a esos mentores (o peor aún: no aproveché los mentores a los que podría haber accedido. ¡Ups!). Comparaciones como estas no ayudan y nos llevan a castigarnos por no ser otra persona. Nuestra evaluación de nuestros proyectos e historia nos da la conclusión de que no somos esa otra persona, ni podríamos ser nunca esa otra persona.
 
-The major problem with ranking programmers (or ranking anything for that matter) is that ranking systems are based on one set of criteria. There is no real standard for ranking programmers. Sites that rank programmers based on numbers of problems solved or difficulty of problems solved have only determined that there are a set of programmers who really enjoy solving these types of problems. They've also collected a set of programmers who will spend the time and effort to solve these problems and will be competitive while solving them. It tells us little about the programmer's abilities outside of that domain.
+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.
 
-There are also other metrics to rank programmers. One classic metric is reviewing how many lines of code a programmer used in order to solve a problem (this is sometimes referred to as "code golf", where the fewer number of lines of code the better the solution). We can argue how "clean" the solution is (clean being another nebulous term). We can determine the "Big O notation", a notation used to describe the performance or complexity of the algorithms that a programmer used in their code. We can stress test the code to determine how well the code adapts to various circumstances. We can count the number of cycles a particular piece of code takes in order to run and benchmark it against similar code. Very little of this tells us anything about a particular programmer. What it does tell us is that the programmer has experience that lead them to that particular solution. It tells us that the programmer has seen these sorts of problems before and cared deeply enough about the problem to think hard enough about how to make a better solution. We learn that the programmer devoted time and energy to practice these sorts of problems. What it doesn't show us is an overall measurement of the programmer's skills or abilities. It's similar to the apocryphal tale of a brilliant professor. This professor was an absolute genius in his field and was one of the go-to people for answers about his subject, but despite his brilliance he was unable to understand how to change a tire on a car. Does that mean the professor was not as brilliant as folks claimed him to be? Hardly. It means the professor spent more time thinking about his profession than he spent thinking about changing tires. The same is true for programmers. If a programmer spends most of their time solving a particular set of problems they will eventually become skilled at those sorts of problems. But if that programmer struggles with a different sort of problem it doesn't discount their overall skills; it just points out areas they might want to work on.
+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.
 
-## Measuring programmer output
+## Midiendo el rendimiento del programador
 
-There's also a tendency to measure programmer productivity by how many contributions the programmer can make to a project.Under certain version control systems these are called "commits". They list out a set of changes that the programmer wishes to make to the code. In an era of social coding sites like Github and Gitlab we can easily review what other programmers are committing. Since we can measure the number of commits, we can use this measurement to feel that we're not generating the same number and frequency of commits as other programmers. And unlike measurements of old (lines of code in particular, which measures how many lines of code a programmer adds to a program) we can review the quality of their commits to a project. It can be daunting to see a lot of quality work done by our peers. It can also be source of frustration and feelings of inadequacy. "Why can't I be as productive or contribute as this other person?" we ask ourselves.
+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.
 
-Even more frustrating is when others use these metrics to judge productivity and code contributions. We may find ourselves being criticized for our output (or lack thereof).
+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).
 
-Commits and lines of code are the most visible measurement of coding productivity, but they don't show much about the actual practice of programming. We can't measure the amount of time thinking about the problem just by looking at a commit. We don't see the mounds of reference material the programmer used in order to figure out a solution, and we certainly don't know if this commit is the result of one afternoon of work or many days of work (unless they commit more often). We might even find out that this person is acting as the focal point of an organization and is folding the work of multiple folks into their commits.
+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_.
 
-Measuring ourselves on the quantity of others output is easy and seductive but it isn't useful for figuring out how to improve ourselves in relation to the other programmer (other than "generate more commits"). That way of thinking can lead us to believing that we're not spending enough time doing "actual programming" and lead to overwork, stress, and burn-out.
+Medirnos a nosotros mismos basándonos en la cantidad de la producción de otras personas es fácil y muy seductor pero no es útil para hacerse una idea de cómo mejorar nosotros mismos en nuestra tarea de crear código (a no ser que sea "generando más _commits_). Esa forma de pensar puede llevarnos a creer que no estamos dedicando el tiempo suficiente a la "programación real" y provocar exceso de trabajo, estrés y agotamiento.
 
-## Traveling Companions
+## Compañeros de viaje
 
-There are times when it is useful to compare ourselves with other programmers. Sometimes we can learn about new technologies or new methodologies by looking at the work of others, but it's easy to fall into the trap of thinking that because we're not at the level of other programmers we're somehow inferior to them. Rather than looking at other programmers as competition we should look at them as companions. We're all in this profession working to make our respective projects better. With Free and Open Source Software we have a unique opportunity to see how other folks do their work in public. We can learn from the code of others much in the same way that scientists can look at the papers of other scientists to see what worked (and can improve the validity of the paper with replication and repetition). No coder is completely isolated from the work of others. (It's a rare programmer that has coded their entire programming environment from scratch without the work of others.) We all learn from each other, but rather than be intimidated by the work of others we can instead take it apart and learn from it. If we're lucky we can take the opportunity to ask them how the code works and why they chose to write the code in that way.
+Hay momentos en los que es útil compararnos con otros programadores. A veces podemos aprender sobre nuevas tecnologías o nuevas metodologías mirando el trabajo de otros, pero es fácil caer en la trampa de pensar que porque no estamos al nivel de otros programadores somos de alguna manera inferiores a ellos. En lugar de ver a otros programadores como competencia, deberíamos verlos como compañeros. Todos estamos en esta profesión trabajando para mejorar nuestros respectivos proyectos. Con el software libre y de código abierto tenemos una oportunidad única de ver cómo otras personas hacen su trabajo en público. Podemos aprender del código de otros de la misma manera que los científicos pueden mirar los artículos de otros científicos para ver qué funcionó (y pueden mejorar la validez del artículo con una réplica y repetición). Ningún programador está completamente aislado del trabajo de los demás. (Es raro que un programador haya creado el código de todo su entorno de programación desde cero sin el trabajo de otras personas). Todas las personas aprendemos unas de otras, pero en lugar de intimidarnos por el trabajo de otras, podemos desarmarlo y aprender de él. Si tenemos suerte, podemos aprovechar la oportunidad para preguntarles cómo funciona el código y por qué eligieron escribir el código de esa manera.
 
-There's value in asking questions of our fellow programmers. We tend to overlook asking questions for fear that we're going to ask something obvious or ask a question that will make us feel inadequate for asking. Asking questions is very useful when we don't understand what is going on with an idea or a particular piece of code. There are programmers out there who don't mind answering questions, and my hope is that you find them. Granted there are some programmers who are very busy and might not have the time or inclination to answer questions, but if we are truly stuck and have exhausted all other avenues perhaps we can ask questions of them that don't require much of their time and effort. They may even be grateful for the question because it gives them insights into a perspective they might not otherwise have. When we ask questions we initiate a sharing of ideas in both directions.
+Es valioso hacer preguntas a nuestros compañeros programadores. Tendemos a pasar por alto hacer preguntas por miedo a que vamos a hacer algo obvio o hacer una pregunta que nos haga sentir incómodos para preguntar. Hacer preguntas es muy útil cuando no entendemos qué está pasando con una idea o una pieza de código en particular. Hay programadores a los que no les importa responder preguntas, y espero que los encuentres. De acuerdo, hay algunos programadores que están muy ocupados y es posible que no tengan el tiempo o la predisposición para responder preguntas, pero si realmente estamos atascados y hemos agotado todas las demás vías, tal vez podamos hacerles preguntas que no requieran mucho de su tiempo y esfuerzo. Incluso pueden estar agradecidos por la pregunta porque les da una idea de una perspectiva que de otro modo no tendrían. Cuando hacemos preguntas iniciamos un intercambio de ideas en ambas direcciones.
 
-There is an art to asking questions and it can be frustrating when folks don't answer our questions or come back with other questions and suggestions that are less than helpful. This manifests itself in exchanges where person A asks: "I'd like to know how to do X" and persons B and C respond "I would do Y instead". It's frustrating when folks won't answer our questions directly. It's also easy to get embroiled in exchanges with folks about the merits of doing Y where Y was suggested by someone else that has nothing to do with the original question about X. But if we re-frame the experience as "this person is trying to help me; perhaps there is something in this recommendation that might be helpful" then we can have a better conversation. Perhaps what we're asking isn't the best way to do something and pausing to listen may help us better understand why they suggested what they did.
+Hacer preguntas es todo un arte y puede ser frustrante cuando las personas no responden nuestras preguntas o nos responden con otras preguntas y sugerencias que son menos que útiles. Esto se manifiesta en intercambios donde la persona A pregunta: "Me gustaría saber cómo hacer X" y las personas B y C responden "Yo en su lugar haría Y". Es frustrante cuando la gente no responde a nuestras preguntas de manera directa. También es fácil verse envuelto en intercambios con la gente sobre los méritos de hacer Y donde Y fue sugerido por otra persona que no tiene nada que ver con la pregunta original sobre X. Pero si volvemos a enmarcar la experiencia como "esta persona está tratando de ayudarme, tal vez haya algo en esta recomendación que pueda ser útil", entonces podemos tener una mejor conversación. Quizás lo que estamos preguntando no es la mejor manera de hacer algo y hacer una pausa para escuchar puede ayudarnos a comprender mejor por qué hicieron su sugerencia.
 
-Pulling our egos out of the question allows us to be more open to the answers we receive. When people don't understand our question it becomes easy to take it personally and frame it as "they're not understanding me" or "they're not listening to me". Pulling ourselves out of the question allows us to take the merits of the answer provided "as-is" and gives us the ability to change the question as needed to get better answers.
+El sacar nuestros egos de la pregunta nos permite estar más abiertos a las respuestas que recibimos. Cuando las personas no entienden nuestra pregunta, es fácil tomarla como algo personal y protestar pensando "no me entienden" o "no me escuchan". Al abstraernos de la pregunta nos permite tomar lo valioso de la respuesta proporcionada "tal cual" y nos da la capacidad de cambiar la pregunta según sea necesario para obtener mejores respuestas.
 
-Of course there are folks who won't respond with your best interests at heart and are only interested in imposing their own world-view upon you. Instead of answering your question they question why you're doing that at all and suggest that you should be using their methodology instead. It can take a lot of energy to engage with these folks to tell them "no, I really, really intended to learn more about X." I wish I had good answers for how to handle these folks. There are plenty of them that feel that whatever they're doing is the only right path and those that stray from their chosen path are anathema to their world. My best suggestion is to thank them for their time and ask someone else for help. Perhaps they may be useful in the future when you have questions about whatever is part of their agenda, but for now be as kind as possible and wish them well on their programming journey. Technology spaces have a lot of folks who have been working with computers for a long time and have formed strong opinions about their tools and technologies. My hope is that you can find the ones that are also kind and willing to share what they know and not badger you with their strongly held beliefs. Over time you too will form your own beliefs on what works and what doesn't work and pass that knowledge on to others. Recognizing folks who are there to help educate and those who are there to proselytize is part of our growth process.
+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.
 
-If we look at other programmers as our traveling companions on this journey; as peers in our coding practice, then we can realize that we're all in this together. Even someone with many more years of experience than you have is your peer. You have knowledge and experience they won't have, and they have experience and knowledge you don't have. If we strip away the barriers of perceived rank and meritocracy we can better engage with and learn from each other.
+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.
 
-The journey to becoming a better programmer is long and hard. We need the best companions we can find to help us along the way. We need more than just the technically-skilled companions; we also need companions we can talk to when the day is done. We need companions we can sit with around the proverbial campfire where we can laugh and commiserate about our struggles together.
+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.

dudas.md

@@ -2,4 +2,12 @@
 
 Cap01
 
-- flipped a bit
+- flipped a bit ¿?
+
+Cap02
+
+Typos:
+- project.Under certain > missing space
+- the work of others.) > point at the end of the sentence outside )
+
+- the merits of the answer ¿?