Pausa para el café #13: Lo que todo novato en programación debe saber; 4 formas de incorporar el Design Thinking en su proceso de desarrollo

Lo que todo novato en programación debe saber

Fuente: Stackoverflow Como desarrollador, escuchará muchas teorías diferentes sobre cómo debería verse el código. Algunas personas creen que cuantas menos líneas de código tenga una aplicación, más fácil será de leer. Pero esto es sólo parcialmente cierto. Prefiero evaluar la calidad del código utilizando los siguientes criterios:

1. El código debe ser coherente, informativo y estar bien documentado.
2. El código debe utilizar características modernas y estables.
3. El código no debe ser innecesariamente complejo ni estar roto.

Si decide reducir el número de líneas de código debido a uno de los criterios anteriores, esto se convertirá en un problema. No hagas eso.

Leer el código de otra persona es difícil

De hecho, la proporción de tiempo dedicado a leer y escribir código es de más de 10 a 1. Pero no puedes prescindir de leer el código de otras personas. Tendrás que leer el código de otra persona. Y cuanto antes mejores tus habilidades, mejor. Intente estudiar el código de otras personas utilizando repositorios abiertos de GitHub. Puedes practicar en cualquier momento: simplemente encuentra un proyecto que se adapte a ti y profundiza en cada línea. Otra forma de mejorar tu capacidad para leer el código de otras personas es comenzar a copiar el estilo. Cuando escribe código en el estilo de otra persona, no solo mejora sus habilidades de lectura, sino que también hace que el código le resulte más familiar. Darle una oportunidad.

Nunca escribirás un código "perfecto"

Fui desarrollador en solitario durante cuatro años antes de empezar a trabajar en equipo. Durante la mayor parte de este tiempo, creí que cualquier programador experimentado escribía código perfecto. En mi opinión, aprender a escribir código perfecto es sólo cuestión de tiempo y esfuerzo. Pero cuando me uní al equipo, quedó claro que nadie escribe código "perfecto". Es cierto que el código que finalmente se incluyó en el sistema casi siempre fue "perfecto". ¿Por qué pasó esto? Se trata de análisis de código. Trabajo con un equipo de ingenieros verdaderamente brillantes. Estos son algunos de los programadores más competentes y seguros que el dinero puede contratar. Pero cada uno de ellos (incluyéndome a mí) tendría un verdadero ataque de pánico si alguien alguna vez sugiriera incluir código no probado en la aplicación. Incluso si crees que eres el próximo Bill Gates, cometerás errores. Ni siquiera me refiero a errores lógicos, me refiero a errores tipográficos, caracteres faltantes. Cosas que a veces tu cerebro simplemente no capta. Cosas que sólo se pueden notar con ojos nuevos. Esfuércese por trabajar con personas que estén atentas a los detalles y dispuestas a criticar su trabajo. Al principio será difícil aceptar críticas, pero es la única forma confiable de mejorar la calidad de su código. Haga todo lo posible por no ponerse a la defensiva al revisar el código y nunca tome las críticas como algo personal. Tú no eres tu código.

No deberías escribir código 8 horas al día

Nadie puede decir exactamente cuánto tiempo al día dedican a escribir código. Pero en realidad, pocas personas escriben código más de 4 horas al día. Las personas que no están de acuerdo con esto son la excepción a la regla o trabajan para empresas que tratan mal a su personal. La programación es un trabajo intenso y agotador mentalmente. Es completamente erróneo pensar que alguien escribirá código 8 horas al día, 5 días a la semana. Habrá raras ocasiones en las que necesitarás cumplir con una fecha límite, pero cuando digo raramente, quiero decir casi nunca. No dejes que el trabajo te pese y te obligue a trabajar horas extras. No estoy sugiriendo que trabajes sólo cuatro horas al día. Por lo general, es mejor dedicar las cuatro horas restantes a cosas como:

• aprender nuevas herramientas, funciones y aplicaciones;
• discutir procesos de trabajo con colegas;
• ayudar a los compañeros que tienen dificultades en el trabajo;
• planificación de tareas;
• análisis de código;
• reuniones/reuniones de negocios.

También recomiendo encarecidamente tomar descansos regulares a lo largo del día y hacer ejercicio (al menos un poco). Los efectos positivos del ejercicio están demostrados desde hace mucho tiempo.

4 formas de incorporar el Design Thinking en su proceso de desarrollo

Source Tech Beacon Para crear un producto que satisfaga las necesidades de sus clientes, deberá considerar lo que quieren. Si ha escrito una aplicación con una navegación confusa o una interfaz de carga innecesariamente larga, prepárese para futuros fallos. Como programador, es posible que tengas que profundizar en el diseño del producto en el que está trabajando tu equipo. Este tipo de colaboración es muy útil porque cada persona nota cosas que la otra puede no notar. Te ofrezco 4 consejos sobre cómo un desarrollador y un diseñador pueden trabajar juntos.

1. Participe desde el principio

No asuma que el diseño siempre es lo primero y el desarrollo lo segundo. Esto puede ser cierto, pero no significa que los desarrolladores no deban participar en el proceso de diseño. El programador puede proporcionar información técnica importante sobre cómo se puede implementar el proyecto, mientras que los diseñadores comprenden mejor los deseos de los usuarios. Es mejor descubrir lo antes posible qué función es técnicamente imposible o no cumple con los requisitos del usuario. Si los diseñadores y desarrolladores trabajan juntos, los problemas se pueden descubrir y resolver inmediatamente en lugar de después de que se apruebe el diseño. Muchas empresas adoptan un enfoque colaborativo para el desarrollo de software. Esto significa que los miembros del equipo no solo son responsables de su propia etapa o fragmento de código, sino que asumen la responsabilidad colectiva de todo, desde el diseño hasta las pruebas.

2. Conozca el proceso de UX

Es posible que aquellos que no están familiarizados con UX (experiencia de usuario) no comprendan por qué los equipos cambian los diseños una y otra vez por detalles aparentemente menores. Cada paso en el proceso de UX ocurre por una razón: brindar la mejor experiencia posible al usuario. Por lo tanto, es importante prestar atención a la creación de un proceso de UX desde el principio. Puede incluir:

• investigar el propósito del proyecto;
• crear una estructura alámbrica: un diseño simple que le permite determinar las características principales del producto;
• agregar detalles más finos al diseño del proyecto, como la interfaz de usuario;
• Pruebas de usuario de diseños. Esta es quizás la etapa más importante del desarrollo de UX. Esto proporciona información valiosa sobre el producto antes de dedicar tiempo a desarrollarlo;
• Iteración: utilizando el análisis de los resultados de las pruebas, itere el diseño para mejorar la experiencia del usuario.

Los equipos repiten los pasos de diseño y prueba varias veces hasta que no queden cambios, o hasta que el tiempo lo permita. Por lo general, esto significa que tendrá varias versiones del diseño.

3. Seguir el desarrollo del diseño.

Es muy malo que los diseñadores creen un proyecto sin consultar a los desarrolladores. Es contraproducente. Es importante que DevOps establezca reglas para que los desarrolladores tengan acceso a planos de diseño en formatos de fácil acceso, como PNG o PDF. La colaboración eficaz entre desarrolladores y diseñadores es fundamental para la implementación exitosa de una aplicación. Evite a toda costa entregar a ciegas un diseño terminado. Es mejor corregir un error al principio que al final.

4. Acuerde en qué etapa se le mostrará el proyecto.

Cuando se pide a los desarrolladores que creen una versión mínima viable de un producto (MVP), necesitan conocer los requisitos para la versión final desde el principio. Esto es necesario para evitar problemas con expectativas injustificadas. Los diseñadores deben mostrar ambas versiones del diseño al desarrollador: tanto el MVP como la versión final. Esto ayudará a implementar el MVP, teniendo en cuenta lo que el cliente espera ver en la versión final. Cuando los diseñadores y desarrolladores trabajan juntos, obtienen muchos beneficios. Cada uno de ellos tiene conocimientos que pueden aplicarse a la experiencia del otro. Los desarrolladores pueden proporcionar información valiosa sobre qué funciones no se pueden implementar en el diseño. Por otro lado, la colaboración con un programador aliviará al diseñador de la necesidad de rehacer el proyecto, lo que, en consecuencia, ahorrará tiempo a todo el equipo.