6 cosas esenciales que desearía saber cuando comencé a programar
Tabla de contenidos
ToggleProbablemente podría lograr un 300% más en seis años como programador si supiera estas cosas cuando comencé
Programar no se trata de programar
¿De qué crees que se trata la programación?
¿Escribiendo código?
¿Escribiendo un buen código?
No.
Es solo una parte de la verdad.
La programación no se trata de codificar, la programación se trata de resolver problemas con la codificación.
A los clientes finales no les importa qué tecnologías, lenguajes, marcos o metodologías utilice. Solo les importa una cosa: si su producto resuelve su problema o no.
Es por eso que a nadie le importa qué tecnologías utiliza la búsqueda de Google bajo el capó. Hasta que las personas puedan encontrar información relativa con él, lo usarán.
Es la cosa número uno que desearía saber cuando comencé a programar.
Pasaría menos tiempo escribiendo el «mejor código» y más tiempo resolviendo mejor los problemas del cliente.
Las habilidades de comunicación son más importantes que las habilidades de programación
Cuando recién comencé mi carrera, la falta de habilidades sociales no era mi principal problema. Pero cuando me moví más alto, a la posición intermedia, superior y de liderazgo, mis débiles habilidades blandas se convirtieron en mi talón de Aquiles.
Cuando trabaja en un producto con un grupo de personas diferentes (ingenieros, diseñadores, gerentes), la comunicación es lo único que lo convierte en un “equipo” y lo ayuda a desarrollar el producto de manera efectiva.
La falta de habilidades sociales hace lo contrario: disminuye el tiempo de desarrollo del producto y la productividad general.
Aquí está la situación real que podría enfrentar:
El equipo de liderazgo le dice a su gerente de producto que desea crear una nueva función de producto y ponerla en el próximo lanzamiento del producto. No es urgente, solo quieren publicarlo lo antes posible (como siempre).
El gerente de producto lo llama a Zoom, le dice lo que necesita construir y le pregunta: «¿Cuánto tiempo necesita para construirlo?»
Está haciendo un cálculo aproximado y dice: «Necesito 20 horas».
El gerente de producto no está satisfecho con su respuesta. Quiere publicarlo lo antes posible y mostrarle a la gerencia que puede entregar resultados rápidamente (esta es una situación muy común).
Entonces te pregunta: “¿Puedes construirlo durante 10 horas? ¡Realmente necesitamos esta función en el próximo lanzamiento del producto! «
Y sabe que puede hacerlo si corta las esquinas (sin pruebas, código desordenado) pero luego deberá refactorizarlo, y tomará 30 horas adicionales. Porque otros ingenieros trabajarán con su código desordenado cuando lo publique. Y después de la refactorización, deberá integrar su código con el suyo.
Así que esto es lo que sucederá a continuación. Si tiene malas habilidades sociales, no convencerá al gerente de producto de que realmente necesita 20 horas para crear esta función.
¿Por qué?
Los gerentes de producto a menudo tienen buenas habilidades sociales, según mi experiencia. Entonces, si no puede convencerlos de que refactorizar más tarde es peor que pasar 20 horas en este momento, fácilmente discutirán con usted y lo convencerán de que «refactorizar más tarde está bien». Y todo el equipo perderá 30 horas adicionales por esta refactorización (no cuento el tiempo para corregir errores impredecibles después).
Pero si tienes buenas dotes de comunicación podrás convencerlos de lo contrario.
Así que mejora tus habilidades sociales y tus habilidades de codificación (envía memes en los chats grupales de Slack o algo así).
Y recuerda una simple verdad:
La gente trabaja con personas, no con máquinas.
Los descansos regulares ayudan a programar mejor
Durante cuatro años siempre me siento agotado después del trabajo. De alguna manera pude trabajar productivamente solo por un par de horas. Después de eso, no tuve mucha energía. Hasta que aprendí sobre la técnica Pomodoro.
Es muy sencillo. Trabaja durante 25 minutos y toma un descanso de cinco minutos.
Tu rutina de trabajo se convierte en:
8: 00–8: 25 – Trabajo
8: 25–8: 30 – Receso
8: 30–8: 55 – Trabajo
8: 55–9: 00 – Receso
…
Lo probé durante una semana y me sorprendió lo concentrado, enérgico y productivo que me volví .
Luego fui más allá e implementé el sistema 52 + 17 y mis niveles de productividad se dispararon en un 200%.
Por lo tanto, tome descansos regulares si desea operar a su máxima capacidad.
No existe el "mejor lenguaje de programación"
No hay mejor «algo» en nuestro mundo. Solo lo mejor en algo.
Cojamos los coches. ¿Cómo podemos elegir el mejor coche del mundo? ¿Por velocidad? ¿Por seguridad? ¿Con qué criterios?
Es imposible.
Solo podemos elegir el mejor auto en una categoría determinada. Como el auto más seguro. O el mejor coche todoterreno.
Y si miramos más a fondo, cada categoría resuelve algunos problemas.
Por ejemplo.
Problema: Tenemos niños y los llevamos a la escuela todos los días; queremos que nuestros hijos estén seguros de camino a la escuela.
Solución: Compre el auto más seguro.
Problema: vamos a acampar todos los fines de semana, por lo que necesitamos algún vehículo que nos lleve fácilmente a lugares de difícil acceso.
Solución: Compre el mejor automóvil todoterreno.
Lo mismo ocurre con los lenguajes de programación. Algunos lenguajes y herramientas son mejores para resolver algunos problemas que otros.
Si queremos construir un sitio web interactivo, elegimos JavaScript.
Si queremos ir con ML / AI, elegimos Python.
Recuerde, no existe el mejor lenguaje de programación, existe el mejor lenguaje de programación para …
Así que empieza primero con un problema y luego elige un lenguaje para resolverlo.