tl; dr: en un mes puedes construir mucho o muy poco.
Determinado por:
¿Quién eres tú?
- Estoy aprendiendo desarrollo web. Quiero ser un desarrollador de back-end. ¿Tengo que ser un desarrollador front-end primero para entrar en el campo?
- ¿Puedo escribir un backend complejo usando R?
- ¿Cuál es un mejor marco para que un desarrollador web back-end aprenda, reaccione o sea angular?
- ¿Cuál es el lenguaje de fondo más popular (excepto PHP) y el marco para escribir web-gui?
- ¿Cuánto CSS debo aprender para el desarrollo de backend?
La experiencia general ayuda a recoger cosas más rápidamente, pero lo más importante es cuán similar es lo que quieres construir a las cosas que has construido anteriormente.
Por ejemplo, mi principal experiencia es en el desarrollo de aplicaciones web b2b, por lo que puedo resolverlos muy rápidamente en el caso general. Pero si me pide que cree efectos de audio no triviales para el navegador, me costará mucho más. Podría tener un fuerte conocimiento de JavaScript pero muy poco sobre el procesamiento de señales digitales. Sepa lo que no sabe. No pienses que es fácil solo porque es fácil para los demás.
¿Cuál es tu edificio?
- Cuanto más similar sea su proyecto a las soluciones existentes y cuanto más extendida sea una idea, menos código tendrá que escribir. La mayoría de las partes ya existe en forma de marcos y bibliotecas, la mayoría de los problemas ya están resueltos. Para una versión inicial, es lo suficientemente bueno como para unir algunos de ellos y escribir un poco de lógica de negocios en la parte superior. Si, por otro lado, realmente quiere impulsar la tecnología e ir audazmente a donde nadie ha ido antes, probablemente no escribirá una sola línea de código durante muchas semanas o meses.
- Según el tipo de proyecto en el que esté trabajando, los problemas tienen un impacto diferente. ¿Es el peor caso de un error que un usuario se molesta un poco o que alguien muere? En uno de los dos extremos, es posible que no desee ser súper ágil y desplegar sus lanzamientos.
En que etapa estas
Antes de tener un producto mínimo viable (suponiendo que no sea uno que, como se mencionó anteriormente, podría dañar a las personas), debe ir muy rápido. Cuanto antes saque su producto, más pronto aprenderá de usuarios reales y podrá adoptarlos. No necesita la implementación más estéticamente agradable, más eficiente y extremadamente escalable. No importare
Una vez que tenga un producto que funcione y esté creciendo, debe reducir la velocidad un poco y comenzar a estabilizarse y limpiar para mantener bajo control el departamento técnico.
Pero no arregles cosas que aún no están rotas o que están a punto de romperse. A nadie le importará si optimiza una velocidad de carga de páginas de 1 segundo a 10 ms si el producto no es útil para ellos de ninguna manera, si no está resolviendo sus problemas.
Entonces, su pregunta no debería ser “¿Cuánto podemos construir en ese tiempo?” Sino “¿Cuánto deberíamos construir en ese tiempo?”
Pase una cantidad significativa de tiempo lejos de su computadora, pensando en los problemas (desde la perspectiva de los usuarios) que está tratando de resolver, no en qué patrones de diseño, lenguajes de algoritmos, marcos, herramientas que podría usar.
Si no comprende el problema, la solución apestará, no importa cuán bien esté escrita. Muchas personas simplemente escriben clones de sitios o aplicaciones populares x. Sin entender por qué x está trabajando para sus usuarios.
Lo veo mucho, que las personas están completamente sin ingeniería o con demasiada ingeniería. Cortando sin cabeza, ignorando los problemas que se están resolviendo, sin decir nunca que no a ninguna característica, ahogándose en el departamento técnico más tarde. O personas que intentan prepararse para cada caso extremo posible e imposible por adelantado y poder atender a millones de usuarios desde el primer día.
La verdad es que es mucho más probable que, poco después de su lanzamiento, que en lugar de tener los millones de usuarios esperados, tenga diez amigos y su madre se haya registrado. Pero si su producto está lleno de errores y es tan lento que es completamente inutilizable, incluso los perderá, en lugar de aprender de sus valiosos primeros once usuarios. Encuentra el equilibrio. Sé ágil, pero no tan ágil, tus brazos y piernas se caerán.
Cada línea de código, cada pieza de infraestructura o herramienta tiene su costo. Con el tiempo, el tiempo de mantenimiento es casi siempre mayor que la implementación original. Tenga mucho cuidado al decir cosas “Es una característica pequeña que puedo agregar rápidamente” o “Es solo otro servicio que es muy fácil de configurar e integrar”. Tendrá que mantenerlo, corregir errores, actualizarlo, los nuevos miembros del equipo deben aprenderlo, etc. Una solución subóptima con infraestructura ya utilizada es a menudo mejor que una solución mejor con una nueva infraestructura que agrega complejidad.
Y, por último, en su caso específico, si lo entiendo correctamente, usted es un desarrollador front-end y un back-end. Asegúrese de que al menos uno (mejor ambos) esté razonablemente cómodo en el otro, incluso si esto lo frena. De lo contrario, tiene un alto riesgo de que si alguien no está disponible (enfermo, vacaciones, abandona el proyecto, …) su parte del proyecto se detendrá por completo.
