Breakthroughs de una agencia digital (una serie)
Tenemos un equipo pequeño y muy unido aquí en Brolik. Hemos experimentado un crecimiento sólido año tras año desde nuestro inicio en 2004, pero 2013 se sintió diferente del resto. La compañía celebra 10 años en el negocio el 14 de enero de 2014. Pero no es solo este hito que estamos celebrando ... este año la compañía alcanzó un nivel de madurez del que podemos estar orgullosos. Como una pequeña agencia, los desafíos de flujo de efectivo, los cuellos de botella de producción, los procesos ineficientes y los picos y los valles en nuevos negocios son comunes. Este año, nuestro talento, experiencia y ejecución se alinearon mejor que nunca. Para poner un límite en el año, y para poner este concepto algo vago de "madurez" en términos más tangibles, cada uno de los miembros de nuestro equipo presentará sus avances personales durante el último año. En el proceso, esperamos que conozcas a las personas que inventan a Brolik un poco mejor.
Como desarrollador, siempre veo cosas que dicen: "No tomes atajos desde el principio de un proyecto porque te arrepentirás más tarde". Sin embargo, de alguna manera, todavía tomé atajos, y siempre volvían a morderme más tarde. ¿Alguna vez has tenido esa sensación, donde recuerdas algo que hiciste cuando era niño y luego simplemente te estremecías y te preguntas qué demonios estabas pensando? Bueno, puedes tener esa sensación al desarrollar también, y es un dolor de cabeza masivo.
Después de volver a varios proyectos este año para solucionar problemas para los clientes, finalmente decidí tomar el mensaje de no tomar atajos en serio. Sin embargo, no solo eso, le agregué un poco: anticipar problemas. Estoy seguro de que muchos desarrolladores han oído hablar de la idea de que el usuario es estúpido; Pero eso no es cierto. El navegador es estúpido, el usuario está impaciente y no siempre harán lo que quieras que lo hagan.
Entonces, ¿qué comencé a hacer en la segunda mitad de 2013 para salvarme los dolores de cabeza futuros? Comencé a planificar y anticipar cosas que debería haber hecho todo el tiempo. Por ejemplo, ¿qué pasa si el usuario puede cargar una imagen a través de su CMS? Bueno, ¿qué sucede si no suben uno? ¿Cómo debería cambiar el diseño? ¿Qué le hace eso al diseño? ¿Qué sucede si la imagen está dañada? O perdido? ¿Qué pasa si suben una imagen realmente pequeña o una imagen realmente grande?
Estas son el tipo de preguntas que comencé a hacer mientras trabajaba en un proyecto para ahorrarme no solo dolores de cabeza con interacción involuntaria del usuario, sino también con código desordenado. Cuando comienza a incluir cheques más intuitivos en su código, le obliga a pensar más en lo que está escribiendo, y al menos para mí, ha reducido la cantidad de código desordenado en nuestros proyectos.
Practicar los problemas anticipados no me ayudará solo, pero ayudará a mi colega, nuestros clientes y sus usuarios en el futuro.