Featured

Un final inevitable


Esta probablemente será la última publicación que haré en el blog, así que intentaré que por lo menos sea un poco más memorable que el resto. Antes de comenzar con la reflexión como tal, quiero hacer saber que estoy intentando lo de escribir con Comic Sans para ver si efectivamente redactar resulta más fácil.

“Quill” flickr photo by rachaelvoorhees https://flickr.com/photos/rachaelvoorhees/2551532922 shared under a Creative Commons (BY-SA) license

Tener un blog por primera vez fue toda una experiencia. Incluso si no decidí exactamente de lo que hablaba “cada semana”, me agradaba tener la oportunidad de redactar y dar a conocer mi punto de vista respecto a distintos temas. Me es muy entretenido expresarme e idear analogías para ayudar a explicar ciertas cosas.

De hecho, el próximo semestre comenzaré a impartir materias en el sistema de preparatoria en línea de Prep@net. Me tocará ser tutor para algún grupo y, sinceramente, estoy emocionado. Espero que todo lo que practiqué con este blog me sirva para impartir clases.

Después de la reflexión del segundo parcial solamente hice tres masteries. Haré el típico resumen de los tres temas correspondientes, pero al final tendré que darle un énfasis mucho mayor a lo que me dejó el curso en general. Iré, como siempre, en orden cronológico.

Revisión de código

Honestamente, este fue uno de los temas que más me interesó mientras lo investigaba. Ver las múltiples técnicas, prácticas o consejos para algo tan rutinario como lo es la revisión de código fue revelador.

“Incorrect vs. Correct” flickr photo by ebenimeli https://flickr.com/photos/ebenimeli/6833633182 shared under a Creative Commons (BY-NC-SA) license

Recién me doy cuenta de que mi analogía va todavía más allá de lo que pensaba inicialmente. Al principio comparé la revisión de código con los quehaceres del hogar porque son cosas que, si bien no son precisamente entretenidas y pueden dar mucha pereza, son sumamente imprescindibles para una mejor calidad de vida a largo plazo. La parte que no relacioné originalmente es que hay mucha gente que ya da por hecho ambas cosas, ya son parte de una rutina. No es necesario decir explícitamente lo que se tiene hacer porque muchos ya estamos acostumbrados a realizar ambas actividades.

Incluso si, como acabo de decir, ya acostumbramos a realizar alguna de estas labores, no quiere decir que lo estemos haciendo de la forma más eficiente. Los métodos y consejos en mi publicación original son algunos ejemplos de cómo puede mejorarse el proceso.

Las técnicas que reuní iban desde cosas muy casuales/informales como simplemente ir hasta donde tu compañero y pedirle que le eche un vistazo a tu código, hasta crear fichas para hacer un reporte completo y llevar un registro más riguroso de los cambios hechos.

Verificación y validación

Este tema fue sencillo de explicar, pues en realidad todo dependía de un par de conceptos bastantes simples en sí. Ojo, son conceptos simples por sí mismos, pero debido a su pronunciación tan similar pueden confundirse. La “comparación” de ese tema en realidad fue un par de ejemplos de palabras que de por sí se confunden entre sí, y la verdad es que muchas de esas las menciona el profesor constantemente, así que no siento que haya sido de mis mejores analogías.

“OK Blue” flickr photo by sylvar https://flickr.com/photos/sylvar/3175705552 shared under a Creative Commons (BY) license

El proceso de verificación y validación es uno comúnmente utilizado no solo en el ámbito del software, sino en todo lo relacionado a productos y servicios. Básicamente se realiza una serie de pruebas y revisiones para comprobar que lo evaluado cumpla con ciertos estándares y cierta calidad.

La parte clave para comprender este tema, o por lo menos en mi percepción, es saber qué pregunta intenta responder cada parte del proceso. La verificación se asegura de que el producto/sistema se esté haciendo correctamente, principalmente se asocia con los requerimientos y especificaciones del diseño. Por otro lado, la validación se encarga de que se esté trabajando en el producto correcto, trabaja con las necesidades del usuario y lo que se busca solucionar.

Otros detalles relacionados a cómo llevar a cabo este proceso y algunos de los beneficios que trae consigo están dentro de mi entrada original. Este tema no lo he puesto en práctica, pero pude notar que llega a ser de gran utilidad.

Pruebas en Orientado a Objetos

Lo primero que quiero decir de esto es que en el título de mi mastery escribí “OOkay”, pero no fue un error de dedo, quise meter la parte de Orientado a Objetos y lo mejor que se me ocurrió fue eso.

“testing” flickr photo by rjacklin1975 https://flickr.com/photos/rjacklin/436491997 shared under a Creative Commons (BY) license

Este tema fue muy directo, es justo lo que dice el título. Todo de lo que hablé fue de cómo se pueden realizar, sistematizar o de cierta manera automatizar las pruebas en algún lenguaje orientado a objetos.

Debido a que tanto la fase de pruebas en el desarrollo de software como el paradigma orientado a objetos tienen una fuerte presencia en el campo de computación llegué a encontrar mil y un formas de llevar a cabo estas pruebas. Comparé esta diversidad con los sistemas de numeración, pues sin importar su clasificación o funcionamiento, al final sirven para lo mismo. Lo que es importante tener en mente es que en determinadas situaciones puede ser que una manera de manejarlo sea mejor que otras.

En fin, existen muchas maneras de clasificar estas pruebas y cada una tiene sus distintos objetivos. En la página original están incluidas y explicadas varias de estas. Opino que es importante comprender algunos tipos diferentes de pruebas en caso de que uno u otro sea necesario.

Pero fuera de estos temas y de explicaciones similares, he llegado a la esperada reflexión. Este semestre he estado publicando muchas cosas respecto a varios temas relacionados al diseño de software. Si soy sincero, no creo que la parte de diseño sea una de mis fortalezas dentro de la carrera, pero debo admitir que este curso me hizo darme cuenta de lo mucho que ya empleo algunas prácticas de esta rama.

Conforme necesitaba escribir alguna entrada nueva me ponía a investigar exhaustivamente para encontrar información suficiente para hacer mi trabajo, buscaba distintas fuentes que, si bien no siempre hacía referencia a ellas, me servían para confirmar lo que leía inicialmente. Estoy muy de acuerdo con lo que Ken nos ha dicho ya un par de veces: es mejor si no se nos indica qué incluir, cuánto escribir ni de dónde obtener la información.

Me agradaba que para cada tema tuviese la oportunidad de informarme cuanto quisiese y poder ser selectivo respecto a qué poner en el producto final. Tras investigar lo suficiente podía darme una idea de qué podría ser más relevante en mi contexto; gracias a la extensión variable me decidí a imponerme un mínimo de dos cuartillas de texto por cada entrada y me forzaba a investigar más cuando no cumplía esa “cuota”; lo de obtener nuestras propias fuentes combinado con lo anterior hizo que comenzara a buscar en foros y sitios similares algunas opiniones de gente experimentada con los temas que iban surgiendo.

“Research” flickr photo by haynie.thomas36 https://flickr.com/photos/132832534@N03/18344328294 shared under a Creative Commons (BY) license

El conjunto de estas condiciones me ayudó a realmente comprender cómo funcionan numerosos procesos del diseño de software, es la primera vez en que realmente he sentido que el autoaprendizaje ha funcionado. Incluso si en alguna de las entradas que hice malinterpreté un tema o solo rasqué la superficie de lo que realmente involucra, tengo una noción de todo lo visto, y eso lo agradezco enormemente.

También relacionado con la parte de autoaprendizaje, el hecho de poder hacer estos cuando quisiéramos y las deadlines flexibles me ayudaron mucho a lo largo del semestre. Pude enfocarme en cosas más urgentes sin preocuparme por este blog. La manera de funcionar del curso me hizo reforzar mi responsabilidad y mi capacidad de búsqueda de información.

Una cosa más que quiero mencionar sobre este curso es el proyecto que estuvimos llevando a cabo a lo largo del semestre. Si bien ya di una conclusión bastante concisa de lo que me quedó en esta publicación, me gustaría agregar que además del típico trabajo en equipo (que, por cierto, se desarrolló muy bien) pudimos experimentar la parte de entrevistas y búsqueda/comunicación con los stakeholders de nuestro proyecto. Experiencias así siempre son buenas.

A pesar de haber explicado todo esto estoy seguro de que todavía se preguntan una cosa: ¿realmente funciona lo de Comic Sans? Me apena decirlo, pero no me ha funcionado en lo absoluto, mis ideas han fluido igual que siempre y en realidad no sentí ninguna diferencia fuera de lo feo que se ve mi borrador. Seguro sí es un simple efecto placebo, pero probablemente por ser consciente de eso mismo ya no funcionó conmigo. Lo único bueno es que parece ser que tanto Comic Sans como Arial (la fuente que suelo utilizar en mis borradores) tienen un tamaño similar y no tuve problemas para medir cuánto he estado escribiendo.

En fin, lo que aprendí en parciales pasados puede verse en las reflexiones del primer y segundo parcial. Si volviese a decir lo que me quedó, sería básicamente lo mismo que ya está escrito y no aportaría nada de verdad a esta entrada. El aprendizaje puede funcionar de muchas maneras, y siento que ya he plasmado en esta entrada todo lo que me pareció relevante. Me pareció muy agradable y útil la manera de llevar la clase.

“Learn” flickr photo by PlusLexia.com https://flickr.com/photos/153278281@N07/39570228664 shared under a Creative Commons (BY) license

TL; DR: El aprendizaje es maravilloso

PD: No sé por qué hay tantas fotos de Scrabble

The calm AFTER the storm


My last reflection for this semester. Not much time has passed since the last one, but I’ve been working on several of my final projects and, even though these were a couple of rough weeks, it’s mostly over now.

During this time we only had two guest speaker sessions and, in all honesty, their talks were not as interesting as previous ones. Don’t get me wrong, I know that testing and metrics are very relevant for us as developers, but I wasn’t as invested this time. The fact that final projects have been consuming a lot of my time and energy didn’t help much either.

Regarding the course as a whole, I enjoyed it very much! The opportunity to talk to experts on such different areas is not something you get anywhere. We had some great sessions and discussions.

As I’ve stated many many times, I was a lot more interested in talks related to the video game industry. All of those were useful to me, either because I got a peek at how bigger companies work or because I could get some advice that I could put into practice right away. Other talks were also very helpful: Ricardo’s got me thinking that I should really start investing soon, especially since I’m close to graduation and jobs are never guaranteed. I think that was one of the biggest lessons I learned during this course.

The activities and readings preceding each of the guest speaker sessions were very good complements. I see a lot of potential there for future semesters, especially with activities (as long as they aren’t as time-consuming as other courses’ assignments). 

The readings were always interesting and the fact that we could read others’ annotations as well made it worth it to reread all of them. Annotations also contain very good points, comments and questions, and often make you realize things that you wouldn’t on your own. This makes it even more fun to reply or start healthy discussions.

Regarding the very last reading (The Secret Life of Bugs), I couldn’t read it on time because of all my final projects, but I did read it recently and left some annotations. It brings up a very interesting topic: the lifecycle of a (software) bug. I was surprised to see how inconsistent and incomplete electronic bug histories were in a company as big as Microsoft.

Regarding the devops activities: I’m very sorry for this, but other than the very first reading, I just didn’t have either the energy or the time to work on any of them. I would like to mention that, just as the reading says, I’m often confused as to what DevOps exactly is. Thankfully, during this course we’ve touched on that particular topic here and there, so I definitely have a more concrete understanding now.

My meetings with Ken were also very very fun. 15 minutes went by super fast every time, I enjoyed all of them and I’m for sure booking some meetings next semester, so look forward to that 🙂

I am glad I decided to take another course with Ken, and I would definitely do it again if I had the chance to.

A lot has been learned


It’s finally time for another reflection. This second partial felt more interesting overall. We may not have had to read as much, but the guest speakers were all really cool! We even got to watch a very fun and totally accurate movie.


Joel Spolsky’s posts included some very relatable statements. The one about rewriting code was specially remarkable for me, since for the longest time I had been wanting to rewrite most of the scripts I made for one of the games I was working on. This reading made me realize that maybe other alternatives, such as a complete refactorization of the whole thing, would be much more convenient. This also reminded me that I still need to work on my architectural design skills.


As expected, I paid special attention to Héctor’s and Daniel’s talks on the video game industry.

Daniel’s made me realize how differently more experienced and bigger studios operate. The company I’ve been working for is still relatively new to video game development, so the whole process has yet to be polished. I could definitely understand how Daniel’s points would apply there.

I recently submitted a job application for a video game studio that has made some games I really really like, so when Héctor mentioned that he has had to go through resumes and be part of the hiring process, I had to ask for advice on what the most attractive and important things to include in one’s resume are. His response led me into buying a domain and starting working on my portfolio.


Maggie’s career and stories were really interesting. I had already heard about her when I was part of this year’s Patrones Hermosos. She was also a guest speaker there and even though I couldn’t be present, I heard really good comments about her, so I was looking forward to our session with her.

It was also pretty impressive how many . . . peculiar friends she has and all of the things they’ve done. I’d be lying if I said I didn’t feel a little intimidated by all of that.


This was the second time I got to listen to Ricardo and his advice on personal finance. To be honest, I’ve never been too concerned about investing my money, but I figured since I now own a credit card it could be a good idea to listen more carefully this time.

At the very beginning I couldn’t keep up with a lot of the things Ricardo and some of my classmates were saying since I’m not very familiar with finance terms. Thankfully, my friend Carlos does, so I asked him to explain some things as Ricardo talked about them.

By the end of the session, I did feel like I had a better understanding of my situation and now I’m exploring several investment options. I’m very grateful for getting this little push I needed, I’m sure it will be greatly rewarding in some years.


It’s been really fun lately, so I’m looking forward to the next sessions!

So this thing’s back…


It’s been a long time since I last wrote one of these entries, and this time it feels different, somehow. In previous courses I was constantly writing a new blog post once or twice a week, I had to find my own resources based on a few cues, and sessions with guest speakers felt a lot more improvised. I’m not sure if it’s because it feels different (refreshing, even) or what, but I’ve liked the new format a lot better.

Before, I had to find my own resources, read from a lot of different websites and authors, and synthesize all of it into yet another blog entry. Now we have assigned readings, and thanks to Hypothesis I feel like the whole experience has greatly improved. Being able to highlight and annotate along with all of my classmates makes the reading considerably more enjoyable. Sharing other complementary sources and points of view definitely adds to the experience. On top of it all, the readings are actually recommended by Ken, so I’m sure they will, at the very least, include relevant information to the course and whatever subject we are discussing.

With No Silver Bullet I was amazed at how many of the things written so long ago still hold up today. Essential and accidental tasks were two key concepts of this reading. We also got to learn how each of them actually affects the desired order-of-magnitude improvement, how much stuff they had tried by then and how promising (or not) some of the new things being tested were. This reading showed a lot about the context regarding software back then.

They write the right stuff was my favorite reading, for sure. I hadn’t considered how different software development and testing must be in a NASA project compared to any other. This is, once again, reaffirmation for how much software projects vary from one another. Obviously things will get very strict if so much is on the table, and it was astonishing to learn how effective their method is. The process may seem way too straightforward, but that’s just what’s better for the projects to be successful.

Dazia’s was my favorite guest speaker. I’m involved in the videogame industry and, even though we had already had a talk with her last year, this time it felt different. I think that’s probably because of the experience I’ve gained, but I feel like I absorbed a lot more this time. 

Kent’s was definitely the most unique session. Having to do the whole TCR activity sure was frustrating, but fun nevertheless. My classmates made some good points with the questions they came up with, and Kent’s way of answering mostly with Sure, why not? or You may be the one to become the best at that new thing was kinda recomforting. In the moment that even felt inspiring, in a way.

As a group, we have discussed several topics. Some were new to me, others were not. Learning new concepts, points of view and technologies is always enriching, but revisiting “old” subjects from a new (self) perspective may feel just the same. I’m glad that this has been the case.

🙂

Create your website with WordPress.com
Get started