¿Qué errores cometen los ingenieros de software en sus primeros años?

Pensando en solo flujos felices y probando el escenario de éxito con la creencia de que ha terminado con el código si eso se ejecuta (en realidad, lejos de eso).

Hacer suposiciones donde se necesita información y, en lugar de plantearlas, simplemente codificar las cosas con las suposiciones.

Cuando busque ayuda, pida más que una dirección general, espere que las personas hagan el trabajo preliminar y aún así esperan que lo ayuden la próxima vez.

No plantear inquietudes lo suficientemente temprano y no alzar la voz lo suficientemente alto (es perdonable, pero no te ayuda a ser un mejor desarrollador)

No probar cosas nuevas porque lo que ya sabes es suficiente. Parece difícil aprender todos esos sofisticados comandos svn / git, ¿por qué no simplemente fusionarse manualmente (pista: gran error)

Trabajando en un equipo con control de Fuente y cometiendo un trabajo descuidado (sin sangría, organización aleatoria, las variables se denominan a, b, c, d, comentarios de confirmación inútiles como “código de confirmación” o “Hice lo que me pidió”)

No estoy aprendiendo cómo configurar el código en su IDE o servidor local. No tengo idea de cómo lidiar con problemas recurrentes en el servidor localhost en su máquina)

Ignorando los errores para los que conoce una solución alternativa (hasta que sean informados por el cliente o los evaluadores).

No detectar y eliminar el código que está obsoleto debido a sus cambios y dejar que se infecte para confundir y sorprender a otros.

Escribir el mismo código, una y otra vez. No se puede crear una abstracción para ahorrar teclas y dolor cuando necesita leer, cambiar y probar en 23 lugares diferentes en lugar de 1.

Ignorando las plantillas y la generación de código para el código de plomería como Mappers que son repetitivos y tontos.

Al no tener confianza fuera de un IDE, no se puede escribir una línea de código sin la guía de asistencia de código.

Escribir código para ganarse la vida y no aprender mecanografía táctil (¿y usted escribe con qué frecuencia?) Confiando así en el mouse (y perdiendo cosas interesantes como VIM)

Comencé a diseñar y crear sitios web, por lo que centrarme en las necesidades y la experiencia del cliente no es mi área débil. Cuando hice la transición al desarrollo de aplicaciones web, tenía mucho que aprender. Cometí muchos errores sin darme cuenta, pero tuve suficientes amigos de apoyo y compañeros de trabajo con consejos para abordar problemas comunes.

1. Buscar soluciones antes de comprender el problema.

Aprenda cuál es el problema que está tratando de resolver. Me dieron el consejo de escribirlo en un lenguaje sencillo primero. Hazlo explícito. Simplificalo. “Los usuarios con permisos de edición pueden editar páginas” se desglosa en “Si el usuario tiene permiso para editar, entonces el usuario ve el botón de edición …” Este ejemplo es bastante básico, pero el método es una gran alternativa cuando no se cumplen los requisitos complejos. Dividirlo en partes simples hace que el trabajo sea particionable para el alcance del trabajo y deja en claro a otros programadores lo que se está logrando.

2. No hablar cuando está atascado. Habla, habla por el amor de todo HABLA. Este es un gran problema que he tenido. Es la naturaleza de la industria atraer a personas introvertidas e independientes que piensan que deberían aprender todo por su cuenta y tienen miedo de parecer estúpidos. Su líder / gerente / jefe ya sabe que está aprendiendo, por lo tanto, muestre iniciativa en su proceso de aprendizaje solicitando regularmente críticas, consejos y dirección. Puede avergonzarse varias veces, pero con el tiempo sabrá cuándo es el momento adecuado. Ha revisado su ortografía, ha rastreado los errores, ha persistido y realmente ha chocado con un muro. O bien, tiene una solución que funciona pero simplemente no le gusta.

3. No tomarse el tiempo para comprender el trabajo realizado antes que usted. Comprenda la estructura de la base de código en la que está trabajando, de extremo a extremo, y adáptese a ella (AKA: “no sea vaquero”). He visto muchos desarrolladores nuevos que se sumergen y ven un desastre porque no lo entienden. Forzan que las cosas funcionen de manera desordenada, y luego realmente es un desastre. Hay una estructura prevista y, aunque las personas se han desviado de ella, volver a la estructura prevista siempre es la mejor manera de interactuar con el código circundante. He visto personas con fuertes opiniones tratando de manipular la estructura de abajo hacia arriba, y finalmente se van y su código se refactoriza.

Unirse a una MNC.

Sí, has escuchado bien. El trabajo de “Sueño” que siempre quiso, Uno para el cual asaltó varias ecuaciones de Química, consideró a HC Verma como una biblia y de alguna manera logró resolver la triple integración ES SU MAYOR ERROR.

Para ser honesto, no soy diferente, hice todo lo anterior, pero la única buena decisión que tomé fue rechazar las compañías de “Camiones” o “Reclutadores en masa” y unirme a una pequeña empresa de TI.

Entonces, ¿por qué deberías hacer eso también?

• En su mayoría, aprenderá sobre todo en su proyecto / tecnología, a diferencia de las multinacionales en las que trabajará en un pequeño módulo si tiene suerte, de lo contrario, sería uno de los evaluadores.
• Aprenderá a resolver problemas por su cuenta y no confíe en que nada le enseñe más que una situación difícil.
• Si tiene talento y la compañía tiene una buena política de gestión, su crecimiento será exponencial (no solo financieramente, sino también sabio)
• Puede llegar a hacer interacciones con el cliente en una etapa muy temprana.
• Si eres innovador y trabajador, siempre puedes aportar un cambio en la forma en que funciona una empresa y ser un factor crucial en el crecimiento de una empresa.
• En su mayoría, aprenderá un poco de cada tecnología en la que trabaja su empresa y en unos años puede llamarse a sí mismo un ingeniero de software completo en lugar de simplemente un “experto” con la mitad del conocimiento de una tecnología en particular.

Pero aún diría que no es un camino que todos deberían elegir, especialmente si:

• Conseguir un trabajo estable es su única prioridad.
• El conocimiento es secundario, el dinero es primario.
• Solo quieres trabajar de 9 a 5 y es posible que en los días impares quieras que tu amigo te lance mientras disfrutas de tu cerveza en casa.
• Solo desea cumplir el sueño de su padre de que su hijo trabaje en TCS (porque aparentemente es la ÚNICA empresa de TI de la que ha oído hablar).

Por lo tanto, depende completamente de sus prioridades y de cómo evalúa a un “ingeniero de software” exitoso.

PD: aunque algunas MNC / “Big Brands” ofrecen una gran oportunidad de aprendizaje, pero el 80% de los estudiantes de primer año no están trabajando en ellas.

Si eres un novato, se supone que debes ser ayudado por tu gerente, no debes “administrarlo”.

¿Cómo puedes cometer un error? Quiero decir que todos cometemos errores, pequeños errores que se pueden encontrar en una o dos horas y se solucionan con bastante rapidez, pero ¿cómo puede cometer un error que no se encuentra más adelante en el control de calidad? ¿Cómo puedes cometer un error que realmente importa? Porque en ese caso, todos pueden ponerse histéricos por los errores, y ese es exactamente el tipo de organización en la que no trabajas.

Supongo que ya sabes programar, debes haber aprobado algún tipo de examen. Si no, entonces su organización es el problema. Significa que la mitad de los desarrolladores son bozos. Tendrás que lidiar con el código escrito por bozos.

Conoces las pruebas unitarias, ¿verdad? ¿Los proyectos utilizan pruebas unitarias o las evitan? Las pruebas unitarias no deberían ser opcionales. Si lo son, entonces su organización es el problema.

Alguien ya mencionó que no está utilizando el control del código fuente. Nuevamente, no es su problema, se supone que su organización debe proporcionarlo y capacitarlo (solo señale los documentos en línea). Y la organización debe asegurarse de que lo use a diario.

En la práctica, si un desarrollador falla, la organización es el problema por no tener claros los requisitos, el diseño, la calidad del código esperado, el proceso de desarrollo, etc. El cliente no debe hacer el diseño, el cliente solo debe proporcionar los requisitos y un programador experto debería tener el diseño más simple posible. Usando patrones de diseño si es posible. Si se deja el diseño al programador, al menos un miembro del equipo debe revisar el diseño antes de implementarlo y sugerir cambios antes de que se lleve a cabo. La revisión esperada debería sugerir MÁS PATRONES DE DISEÑO, simplificar el diseño, no involucrar más actividades que incluyan más codificación o que retrasen el proyecto.

Dejame explicar. Recientemente trabajé en un proyecto donde: no se había implementado ningún control de código fuente. La fuente se proporcionó en fragmentos y aunque intenté usar el control de origen, los nuevos fragmentos simplemente sobrescribieron mi código.

El código no tenía una compilación automática de un solo paso usando ant, maven o gradle. Tuve que improvisar e intentar compilar, pero había tanto código que era casi imposible.

Incluyeron la fuente de jBPM dentro del proyecto. Y luego me di cuenta de que incluso cambiaron jBPM. Pensé “¿qué?” … y los cambios no fueron realmente geniales, básicamente eliminaron mucha funcionalidad.

El código fue un desastre. El manejo de excepciones no existía y el código era frágil. Ninguna unidad prueba en absoluto. Se suponía que diferentes partes del sistema se compilaban de diferentes maneras.

¿Quién tiene la culpa aquí? Los desarrolladores? El gerente del proyecto? Uno de los desarrolladores fue el gerente del proyecto.

¡Camino a seguir!

La separación de roles existe por una razón. Asignar roles de PM, desarrollador, analista de negocios y control de calidad a una sola persona significa que esa persona es un superhombre o un idiota total. Mirando la fuente, es un completo idiota. Y la fuente debería publicarse en el museo sobre cómo los proyectos pueden convertirse en un desastre.

También trabajé en un lugar donde declararon que cada línea de código requería 3 revisiones de código. Pasar una revisión de código puede llevar de 3 a 20 días porque todos deben tener una opinión, e incluso los nombres de las variables tuvieron que cambiar, pero no había un estándar de codificación, por lo que era imposible hacer un trabajo útil.

Es difícil imaginar una organización de desarrollo de software que sea funcional en ese entorno, especialmente si les gustan las funciones grandes, rechazan la recursividad (¿realmente? ¿Dónde aprendiste informática?) Y rechazan las pruebas unitarias (eso es una señal de que la compañía tiene más problemas).

Si un programador escribe funciones grandes, significa que el programador tiene problemas realmente grandes para conceptualizar cosas. Si el cliente proporciona diseños en lugar de requisitos, el cliente piensa que los ingenieros de software son estúpidos y puede crear mejores diseños, lo que por supuesto no es cierto, solo significa que pagará el precio de ser dirigido por un bozo, porque por supuesto esto no trabajará.

Básicamente, no hay nada malo que un nuevo desarrollador pueda hacer, él puede aprender. Y eso es todo lo que puede hacer. Aprenderá cómo hacer las cosas si las cosas van bien, o cómo no hacer las cosas si van mal.

Después de todo, la gente está tratando de convertir el trabajo en una religión: “Usted tiene la culpa de algo que alguien más hizo hace mucho tiempo”.

No deberías aceptar esto. Existen reglas para el desarrollo: requisitos claros, numerados y por escrito, con un patrocinador claro (que lo solicitó en la organización del cliente) y un beneficio comercial (especificado en dólares). Las decisiones de diseño coincidentes se ponen por escrito (resuelven el requisito, al menos conceptualmente). Las implementaciones de prototipos de esas decisiones de diseño se colocan dentro del rastreador de problemas y dentro del administrador del código fuente (¿se puede implementar? ¿Resuelve el requisito? ¿Está claro el código? ¿Se separa lo que se pregunta con la forma en que se resuelve? )

Un requisito puede ser funcional o no funcional.

Un requisito funcional es algo que puedo especificar como dependencia funcional.

Un requisito no funcional es algo que especifica los tiempos de ejecución (como “ninguna consulta puede demorar más de un segundo”, o “el sistema debe estar disponible las 24 horas del día, los 7 días de la semana” o “una copia de seguridad de la base de datos debe realizarse a diario y el sistema no debe desactivarse”). por hacerlo “, o” el sistema debe permanecer operativo incluso si una de las máquinas se cae “, o” el sistema debe proporcionar seguridad “.

Al ser claro, significa que se puede probar el cumplimiento del requisito.

Si todo lo anterior está bien, entonces espero que cada prototipo se ponga en una biblioteca para que cualquiera lo use, y el código fuente de la biblioteca se ponga bajo control de fuente.

Luego, el resto del diseño es solo una cuestión de especificar interfaces de usuario, esquemas de bases de datos, casos de uso (historias de usuarios) y protocolos de comunicación para servicios externos.

He estado desarrollando C / C ++ (del lado del cliente) y C # / ASP. NET (lado del servidor) por más de 15 años. Aquí está mi lista de cosas técnicas importantes a considerar para cada tipo de grandes proyectos que pueda estar desarrollando:

C / C ++ ( lado del cliente ):

• Siempre documente su código fuente . Sea lo más específico posible. Copie las URL en foros en línea y otros recursos utilizados, y péguelos en el código fuente relacionado. (Se sorprendería de lo “extraño” que podría ser su propio código en unos 2-3 años).
• Usar funciones descriptivas y nombres de variables . Estos nombres deben ser fáciles de entender en el contexto del código fuente. Por ejemplo:

  int ccm = 0; // ¡Es un mal nombre!
  int CounterOfCacheMisses = 0; // ¡Es un nombre mucho mejor!

• No elija técnicas de implementación de libros de texto “inteligentes” que no comprenda lo suficientemente bien como para reescribirlas usted mismo. Siempre use un algoritmo e implementación que conozca y comprenda. Ya no estás en un salón de clases y no hay un profesor de Ciencias de la Computación inteligente que te critique por usar una declaración goto , o por no escribir tu código en ” solo dos líneas de código “. Todo eso es estúpido y se usa solo en un salón de clases para impresionar a tus compañeros geeks. Olvídate de eso en un mundo real.
• Utilice siempre el registro interno de la aplicación . Dedique algo de tiempo a escribir una clase de plantilla que pueda implementar el inicio de sesión en un archivo de texto sin formato en un sistema cliente mientras se ejecuta su aplicación. Luego incluya esta clase preescrita en sus proyectos de producción. Registre tanta información técnica sobre su aplicación como sea posible. Una pequeña advertencia aquí: ¡no registre ninguna información del cliente que pueda considerarse privada! (Me lo agradecerá más adelante en caso de un problema en el futuro, especialmente cuando está implementando una solución más grande y cuando una depuración en el lugar está fuera de la cuestión). Tener un registrador simple y la capacidad de recuperar El registro a petición de un sistema cliente después de una falla ayudará a su estrategia de depuración diez veces.
• Cuando use hilos, siempre emplee técnicas de sincronización adecuadas . Al principio puede parecer una exageración agregar mutexes y secciones críticas, pero créanme, arreglar las condiciones de carrera en el camino en una solución ya implementada puede ser un infierno. Implemente el enhebrado correctamente desde el primer momento. También asegúrese de comprenderlo lo suficiente antes de agregar subprocesos múltiples a su aplicación.
• Asegúrese de implementar versiones adecuadas de su código fuente . Esto será indispensable si decide revertir parte de su trabajo o volver a una idea implementada previamente. Existen muchas soluciones sofisticadas para el control de versiones integrado en la mayoría de los IDE. El simple control de versiones del pobre podría hacerse colocando cada nueva versión del código fuente en su propia carpeta con el nombre adecuado en un disco duro.
• Y, por último, ¡ siempre haga una copia de seguridad de su código fuente! No voy a explicar el significado de esta declaración. Sin embargo, permítanme agregar que siempre deben usar la estrategia de respaldo 3-2-1.

ASP .NET ( lado del servidor ):

• Prácticamente las mismas reglas se aplican a la programación del lado del servidor C # también (ver arriba).
• Una adición importante para una aplicación del lado del servidor que almacena sus datos en la base de datos es hacer lo siguiente:

• Pruebe su código para un mayor número de usuarios. Esto puede crear un cuello de botella obvio si su proyecto crece. También es uno de los desafíos más difíciles para un desarrollador del lado del servidor y es un tema separado.
• Pruebe sus consultas SQL para obtener mayores cantidades de datos . En otras palabras, anticipar la expansión. Afortunadamente, es algo fácil de emular: simplemente complete su base de datos con entradas generadas automáticamente y pruebe el rendimiento.
• Intente perfilar sus consultas SQL para el rendimiento y optimice los cuellos de botella . Esto es obviamente importante si su base de datos puede crecer.
• Implemente soluciones para reciclar registros de bases de datos antiguos . Los desarrolladores generalmente no piensan en ello durante las primeras etapas.

1. Ser demasiado agresivo para dimensionar y especificar proyectos.
2. No administrar su gerente / establecer expectativas.
3. Esperando que pueda leer la intención y el tono en la comunicación por correo electrónico. (ASCII no contiene expresión facial o entonación).
4. No estar dispuesto a aprender nuevos idiomas y habilidades.
5. No leer libros técnicos.
6. No centrarse en el desarrollo profesional y la creación de redes.
7. No intentar usar algoritmos adecuados.
8. No prestar atención al rendimiento.
9. No prestar atención al modelado de objetos.

Eso parece muy simétrico. 3 sobre comunicación, 3 sobre desarrollo profesional y 3 sobre ejecución.

Cuando alguien termina la escuela y en su primer trabajo, está en este gran lugar. Han tenido éxito en su educación y tienen un trabajo bastante bueno en comparación con la mayoría de los trabajos de verano o de medio tiempo. Sin embargo, el desarrollo de software y nuestra industria en su conjunto es un viaje de aprendizaje. Entonces, la idea que tienen los nuevos graduados de que ir a trabajar es diferente a la educación es solo parcialmente cierto. La realidad es que la mejor manera de tener éxito es continuar aprendiendo agresivamente y aplicando ese aprendizaje. Ese debería ser el dominio empresarial, para comprender realmente quiénes son los usuarios y por qué usan lo que construimos. Sin embargo, también comprende el oficio de la ingeniería de software y hardware. Estas son áreas temáticas profundas y amplias, así que asegúrese de profundizar en las áreas que le interesan pero que también son amplias. Algunas de las personas que más admiro en este negocio no son los multimillonarios. Los multimillonarios eran inteligentes, pero la suerte era una característica dominante de su éxito. Me atraen las personas que han hecho contribuciones realmente útiles que han ayudado a un grupo de personas lo más amplio posible. Gente como Gerald Weinberg, muchos líderes de opinión en la comunidad Agile, Linus Torvalds, y esa persona que en el futuro nos dará un lenguaje / herramienta tan útil como C ++ pero 10 veces más agradable de usar.

El mayor error sería volverse complaciente . Suponga que luchó duro y se preparó bien y se metió en una muy buena compañía. El trabajo es bueno, la paga es buena y el equilibrio entre la vida laboral es bueno. Tienes tiempo para tus pasatiempos, eres bueno en el trabajo y no necesitas aprender nada más para hacer tu trabajo diario. Te instalas en el papel y estás muy feliz de estar aquí.

La vida va muy bien hasta que de repente, un día, escuchas una palabra temida “recesión”. ¡Auge! Las cosas comienzan a ir cuesta abajo en toda la industria. ¡Las personas están perdiendo empleos pero aún confías en que estás a salvo! Entonces, de repente, su compañía probablemente vende toda su división a otra compañía o la cierra por completo. El primero es un resultado relativamente mejor, pero el segundo significa que de repente no tienes trabajo. ¡Tienes compromisos y necesitas el salario fijo! Esta es una situación terrible. Empiezas a buscar un trabajo, pero cuando ves los requisitos para los trabajos populares, te preguntas qué son todas estas palabras mágicas. Lo que estabas usando en tu trabajo diario no se ve en las carteleras. El mundo se ha movido de esa tecnología o no lo necesita, ya que ya tienen a su propia gente trabajando en ello.

Esta es una mala situación. Por lo tanto, nunca te vuelvas complaciente. Puede que tengas un buen trabajo pero nada dura para siempre. Sigue mejorando tus habilidades. He visto personas asistir a entrevistas, a pesar de que no quieren cambiar de trabajo. Estas son personas inteligentes. Periódicamente evalúan su propia valía.

Entonces, si usted es ingeniero en las primeras etapas de su carrera, le aconsejaría que haga lo siguiente:

1. Habilidad siempre. No necesita conocer el manual del idioma de memoria, pero debe poder recordar bien las herramientas necesarias para su trabajo.
2. Aprenda DS y Algoritmos y apréndalos bien. Son esenciales para las entrevistas de trabajo en la mayoría de las buenas empresas. Una vez dentro, es posible que no use todos estos directamente, pero es útil conocer bien estos conceptos.
3. Ahorre algo de dinero y comience algunas inversiones tempranas si puede pagarlo
4. Mira lo que está de moda en la industria. Puede ser un maestro de algún idioma antiguo y puede ganar elogios en su empresa actual, pero si no se usa en ningún otro lugar, se quedará agarrando pajitas cuando ocurra lo innombrable
5. Nunca tiendes a establecerte en una empresa por mucho tiempo. Una persona mayor me mencionó una vez que nunca debes estar en una empresa durante más de dos años desde que dejas de ser relevante. No recomendaría cambiar de compañía cada dos años, pero encuentro su punto óptimo (digamos 4–5 años). De esa manera, obtienes un buen aumento de salario y también puedes explorar el océano más grande.
6. Tenga algunos pasatiempos y pasiones y sígalos cuando pueda. Es posible que no obtenga el tiempo o la motivación una vez que envejezca. Sus prioridades también pueden cambiar.
7. Me encanta hacer lo que estás haciendo. Si no se está burlando de lo que está haciendo en su trabajo, trabaje en algunos proyectos de pasión personal en casa.
8. Mantener un blog o un sitio web.

Aunque la respuesta anterior no es exactamente una lista de errores que hacen los primeros ingenieros de software, puede deducirlo de esto.

Editar : Olvidé mencionar una cosa muy importante: ¡ documentar todo ! Cuando se une como estudiante de primer año, los adultos mayores pueden sostenerlo con la mano y guiarlo a través de lo que debe hacerse. Esto no durara mucho. Por lo tanto, una vez que esté solo, deberá trabajar con el equipo y trabajar para satisfacer las expectativas de todos. En las reuniones y discusiones, lo que entendió no siempre es lo que se esperaba. Asuma este escenario: en una reunión, uno de sus superiores le pide que haga que la IU sea más “llamativa”. Lo que asume es que desea poner todo tipo de colores y hacer que parezca más brillante. No preguntas por qué, no dicen por qué. Pasas una semana y luego demuestras tu versión llamativa de la IU, con todo tipo de colores. Tu superior explica con calma que cuando dijeron “llamativo”, significaban que tenías que agregar algunas animaciones a la IU existente y no hacer Es como si alguien bebiera pintura y vomitara sobre la IU. ¡El esfuerzo de toda tu semana se va a tirar a un lado!

Por lo tanto, cuando tenga alguna discusión, ya sea como una persona con más experiencia o con 20 años de experiencia, siempre asegúrese de documentar lo que se discutió y cuál es el resultado esperado. Nunca olvides esto.

Todos en la industria de TI no son santos (probablemente nadie lo sea). Por lo tanto, podrían decir algo impreciso para que hagas algo, que podría meterte en problemas. Por lo tanto, siempre documente todo. Cuando digo documento, capture su comprensión de lo que se espera y envíelo por correo . Envíelo a todas las personas interesadas. Es tan simple como decir ” Hola, gracias por la reunión. Esto es lo que entiendo de esto: …… Así es como implementaré esto: …… Comenzaré con esto ahora. Si tiene algún comentario sobre esto, hágamelo saber para que rectifique mi enfoque ”. Con este correo, usted se asegura de exponerles su comprensión. Además, les está diciendo que no está esperando una respuesta. Por lo tanto, solo si desean algunos cambios, pueden sugerirlo; de lo contrario, está asumiendo que lo que está haciendo es correcto.

Otra cosa importante para recordar mientras trabaja, especialmente como un producto más fresco. Siempre pregunte cuándo se debe algo. Pregunte cuándo es la fecha límite. Puede suponer que le han dado una tarea que puede entregar después de una semana, pero podrían esperarla al día siguiente. Por lo tanto, siempre pregunte. Dígales “Creo que podría llevar alrededor de x días hacer esto, ¿está bien?” Por lo general, los adultos mayores están de acuerdo con esto desde que está comenzando. Intente completarlo antes de ese momento, si es posible. Si siente que no va a llegar allí antes de la fecha límite, indíqueselo antes. En lugar de decir que está atrapado y necesita una semana más, cuando vengan a pedirle una demostración el día de la fecha límite, vea si puede decirles con un par de días de anticipación (o incluso antes, si puede resolverlo). ) Siempre sea claro en sus comunicaciones y asegúrese de tener todo documentado. ¡Esto resolverá muchos problemas cotidianos!

Descargo de responsabilidad : no hice algunas de las cosas que enumeré anteriormente y, por lo tanto, lo he puesto aquí para que pueda ayudar a alguien más 🙂

¡Buena suerte!

Además de todas las otras respuestas dadas aquí, me gustaría agregar algunos puntos más de mi experiencia laboral en Amazon (empresa):

(Para darle un poco de experiencia, en Amazon como SDE, tenemos que trabajar en casi todo, es decir, desde el diseño hasta la seguridad y las pruebas. Por lo tanto, esta experiencia se basa en eso).

1. Permítanme completar este proyecto, entonces definitivamente comenzaré a ir al gimnasio. Esto es un mito y nunca va a suceder. Su gerente no recibe miles de rupias para mantenerlo sentado ideal. Siempre sentirá que solo tiene que terminar esto, entonces obtendrá un poco más de tiempo libre y comenzará a hacer otras cosas.
2. Estoy trabajando muy duro mientras trabajo durante estas muchas horas extra. No deberías estar feliz en este caso. Si está trabajando durante muchas horas adicionales, debe preocuparse si no tiene la productividad o si el gerente le está dando tanto trabajo extra. Debe corregir lo que sea y trabajar solo en horario de oficina.
3. ¿Por qué debería preocuparme por comprender otros sistemas relacionados con el proyecto? Solo me enfocaré en el mío. Esta es una cosa que cualquier otro ingeniero nuevo piensa, pero esto diferencia entre un ingeniero promedio y un buen ingeniero. Comprender otros sistemas puede brindarle tres grandes beneficios: a) No está en esa empresa solo para trabajar para siempre, sino que aprende tanto como puede. Entonces, aprendelo. b) Puede evitar cualquier suposición incorrecta que haría de otra manera. c) Puedes ver cualquier defecto en toda la solución propuesta, que puede llevarte a convertirte en una estrella. d) Nadie más conoce este proyecto más de lo que usted sabe. Entonces, te conviertes en un POC para este proyecto y lo destacas.
4. Si el gerente / gerente del programa técnico / gerente de producto me pide que haga esto, él estaría en lo correcto. No le haré preguntas cruzadas: puede que venga directamente de una reunión de negocios y tenga la misma mentalidad durante algún tiempo. Es su trabajo interrogarlo si cree que está diciendo algo incorrecto porque, después de todo, el código que escribe no debería desperdiciarse más tarde y, si lo empuja a producción, no debería crear ningún problema.
5. También es un deber del gerente hacerme crecer técnicamente: a la mayoría de los gerentes no les importa una mierda. Lo único que les preocupa es que el negocio crezca, porque eso los beneficia directamente. Debe cuidar su crecimiento técnico usted mismo.
6. Cualquier código escrito ya es ideal: me enseñaron en mis primeros meses que cualquier código escrito puede no ser ideal. Esa persona hubiera pensado corregir eso más tarde o hubiera escrito solo el código incorrecto. Pero debes pensar en ti mismo, si eso es correcto o no. No desarrolles tus habilidades sobre la base de algunas cosas malas.
7. No compartiré mi conocimiento con otros, de lo contrario perderé mi importancia. Este es un mito común que muchos ingenieros nuevos creen. Recuerde que los ingenieros son famosos por no aprender los conceptos al principio, pero recuerde a la persona a quien deben acudir para cualquier pregunta en cualquier campo. Entonces, compartir el conocimiento te hará más famoso en su lugar.
8. Creo que estoy en lo correcto, pero no debería discutir con el ingeniero sénior. Él es senior, debe estar en lo correcto. Sí, hay muchas posibilidades de que el ingeniero senior tenga razón. Pero tienes que aprender y crecer, la duda detendrá tu crecimiento de aprendizaje. Los conflictos son las mejores oportunidades para crecer, ya que puedes aprender algo nuevo.
9. Esta herramienta ya está construida, no necesito preocuparme por cómo funciona: al menos, esta definitivamente será una de las preguntas de la entrevista si planea cambiar y, además, comprender los componentes ya construidos aumentará su conocimiento como Ya han demostrado ser exitosos.
10. Esta decisión ya está tomada, no necesito entender los razonamientos detrás de eso. No pierdas esa oportunidad. Más que la codificación, la resolución de problemas y el diseño son más importantes y valiosos de aprender. Obtendrá solo unos pocos proyectos de diseño o buenos problemas para resolver usted mismo, pero aún puede aprender estas cosas incluso en otros proyectos también.
11. Mi trabajo es solo desarrollar software, no preocuparme por la seguridad, el backend, las pruebas, la experiencia del usuario. Cuando aprendiste todo mientras hacía ingeniería, ¿por qué no comenzar ahora? Esto diferencia entre un ingeniero promedio y uno bueno. Ve por la cima.

Veo muchas buenas sugerencias en las otras respuestas publicadas. Aquí hay algunas ideas que no vi mencionadas por otros.

Comiendo excepciones.
Al usar excepciones, coloca el código en un bloque “probar”, pero cuando detecta la excepción, no hace nada para corregir el error o incluso para informarlo. Solo lo haces
try { ... } catch (Exception e) { ; }
Esto suprime cualquier información de diagnóstico y hace que se oculten problemas genuinos. Esto se llama “comer la excepción” y se considera una mala práctica.
Los programadores hacen esto para evitar declarar los tipos de excepciones que puede lanzar su clase / función, o simplemente no entienden cómo programar con excepciones.

En cambio, un programador debe manejar la excepción haciendo algo como corregir el problema que causó la excepción, o volver a intentar si se debió a un problema de tiempo, o al menos informar el hecho de que ocurrió la excepción y su causa.

Pero no siempre es el lugar correcto para manejar la excepción en la misma función que causó la excepción. Por lo tanto, puede permitir que la excepción haga que su función finalice y pase la excepción a la persona que llama. En algún lugar de la pila de llamadas, se espera que haga algo responsable con esa excepción, en lugar de dejar que bloquee su aplicación.

Inyección de SQL (y otros errores de seguridad).
Esto no se limita necesariamente a los nuevos programadores: muchos programadores experimentados no siguen las buenas prácticas de seguridad para las aplicaciones web. Pero la creación de vulnerabilidades de inyección SQL comienza temprano.

Codificando las cosas demasiado inteligentemente.

Todo el mundo sabe que la depuración es el doble de difícil que escribir un programa en primer lugar. Entonces, si eres tan inteligente como puedes ser cuando lo escribes, ¿cómo lo vas a depurar? – Brian W. Kernighan

No pedir ayuda cuando sea necesario.
Puedes aprender mucho de los ingenieros canosos si eres lo suficientemente inteligente como para mirar y escuchar.

Creer que un lenguaje de programación es “mejor” que otros.
Puede haber algunos idiomas que faciliten la codificación de una tarea específica, pero no son tan buenos para otra tarea. Perl requiere menos código para procesar texto que Java. Pero Java es mucho mejor para la programación multiproceso que Perl.

Escribir una gran cantidad de código complejo en una línea.
Esto hace innecesariamente difícil usar herramientas diff para ver qué cambió, o usar herramientas de cobertura de código para medir sus pruebas.

Soy afortunado. ¡Tengo la oportunidad como CEO de Aha! ( que es el software de la hoja de ruta del producto ) para trabajar y aprender de un increíble grupo de ingenieros de software. Nuestro equipo fundador también ha dirigido productos e ingeniería en seis compañías de software, por lo que tenemos mucha experiencia en este momento trabajando con equipos de desarrollo de alto rendimiento.

Conocemos los tipos de errores que son comunes a los ingenieros de software en los primeros años de su carrera. Más importante aún, hemos aprendido a hacer nuestro mejor esfuerzo para ayudar a evitar que estos errores ocurran en primer lugar.

Como el resto de nosotros, los nuevos ingenieros de software son humanos: todos cometemos errores. Pero hay una diferencia entre el paso en falso ocasional (que es comprensible) y ser propenso a errores.

Aquí hay algunas áreas comunes con las que hemos visto luchar a los ingenieros emergentes y cómo superarlas.

De ninguna manera todos luchan y esta lista simplemente destaca algunos desafíos. Obviamente, cada ingeniero es diferente.

Realimentación
Está bien documentado que muchos desarrolladores y empresarios lidian con el “síndrome impostor”, una sensación de que no están calificados o no pertenecen a su posición y solo están esperando que se descubran sus errores.

Como resultado, muchos desarrolladores jóvenes pueden ver las críticas a su código como una señal de falla inminente en lugar de un componente central de un equipo de ingeniería saludable, y se ponen a la defensiva o se frustran demasiado.

En cambio, deberían aprender a aceptar los comentarios sobre el código como una visión positiva. El “síndrome de Imposter” puede hacer que los desarrolladores sientan que están siendo atacados personalmente cuando reciben comentarios. Pero cambiar sus pensamientos sobre la retroalimentación, y concebirla como un regalo que mejorará su trabajo, puede hacer maravillas y evitar que se sientan como un fracaso.

Aprendizaje
Los desarrolladores son algunos de los profesionales más motivados que jamás conocerá. Muchos de ellos son autodidactas y aprendieron a codificar basándose en la pasión innata. Aunque este es un rasgo excelente, también es por eso que los desarrolladores toman su trabajo tan personalmente. Del mismo modo que a veces reciben comentarios demasiado duros, los desarrolladores también pueden tener problemas para hacer frente cuando su código es incorrecto.

Lo que separa a los ingenieros calificados de los ingenieros no calificados no se trata de quién comete errores, todos lo hacen. Por el contrario, los mejores ingenieros se preocupan por sus errores y se esfuerzan por aprender de ellos. Esto es para que puedan mejorar su flujo de trabajo y, en última instancia, escribir código más preciso. Este proceso de autorreflexión es crítico para el crecimiento a corto y largo plazo.

Marcos
El desarrollo web moderno es muy diferente de lo que fue durante los primeros 10-20 años de existencia de la web. Ahora es completamente posible descargar un marco, ya sea un marco de fondo (Rails, Express, etc.) o un marco frontend (React, Angular, Bootstrap, jQuery).

Un ingeniero de software puede dedicar la mayor parte o la totalidad de su carrera de desarrollo sin comprender cómo funcionan realmente las cosas, por qué las cosas se comportan como lo hacen o las razones por las que es necesaria una técnica en particular.

Estos marcos son excelentes para suavizar los puntos difíciles de un lenguaje y permitir que un desarrollador logre cosas increíbles rápidamente. Pero también evitan que los desarrolladores tengan algunas de las mejores experiencias de aprendizaje precisamente porque suavizan esos bordes ásperos. Es esencial comprender los fundamentos de una tecnología y no solo las abstracciones de alto nivel.

Confianza
Al comenzar, es muy importante que los nuevos ingenieros trabajen con personas más inteligentes y con más experiencia que ellos. Seguir y trabajar con estas personas aumentará significativamente sus propias habilidades. Pero hacerlo también les da energía y entusiasmo.

Esto significa que la barra puede estar más alta. Pero cuando los nuevos ingenieros de software trabajan con colegas a quienes quieren impresionar, estarán a la altura de las circunstancias y mejorarán en el proceso.

Los ingenieros jóvenes tienden a ser extremadamente brillantes. Por lo tanto, si usted es un joven ingeniero de software, confíe en que es un profesional inteligente que puede contribuir a su equipo de una manera única.

Trabajar con aquellos que son mejores que tú es cómo creces tu propio conjunto de habilidades.

La mejor de las suertes en tu carrera.

Si desea leer mis futuras respuestas, haga clic en ‘Seguir’ aquí y no dude en conectarse a través de Twitter .

1. Invertir demasiado tiempo aprendiendo idiomas en lugar de conceptos. Si conoce los conceptos, los patrones de diseño y los fundamentos del software, es solo cuestión de semanas aprender un nuevo idioma. ¿Sabes que los POO también se pueden implementar en C?
2. Centrarse en completar la tarea en lugar de pensar en la escalabilidad, la generalidad y la facilidad de mantenimiento del código.
3. Miedo de hacer preguntas, o peor miedo de admitir errores
4. No invertir tiempo para pensar y estimar la complejidad del código, sino saltar directamente sobre el código
5. Usar muchos marcos en lugar de crear uno.
6. No manejar al jefe adecuadamente. Como dije “No siempre se maneja hacia abajo, pero manejar hacia arriba es lo que importa”
7. No es necesario complicar el código en lugar de una solución simple y elegante.
8. Esperar a alguien les dirá qué hacer, en lugar de tomar la iniciativa.
9. No documenta el código y se centra menos en las pruebas unitarias.

1. No documentan su experiencia cuando están en un proyecto.
2. No aceptan el hecho de que el aprendizaje es un proceso continuo.
3. Rara vez se piensa y se aprende cosas nuevas.
4. Los correos rara vez se leen completamente.
5. No interactuar con sus compañeros.
6. Hacer cosas que nos hagan visibles entre las personas en los niveles superiores.
7. Esperando oportunidades en lugar de crear una.

1. Pensando más en el paquete que en las habilidades, ambos están relacionados pero no son directamente proporcionales, piense más en desarrollar su paquete de habilidades que aumentará automáticamente (Suena como una línea de película, pero es cierto).
2. Concéntrese demasiado en el trabajo o en el disfrute, haga un balance.
3. Dependiendo demasiado de Google, stackoverflow y tutoriales en línea, obtenga un buen libro y cree conceptos.
4. Sacrificar tu trabajo mientras planificas un MBA o estudios superiores.
5. No enfrentarte a tus mayores cuando sientes que no están bien. No seas tonto. A los gerentes / líderes reales / buenos les gusta si un empleado ofrece un mejor enfoque.
6. Todavía tengo problemas con la universidad. Me tomó algo de tiempo sacar la universidad de mi sistema. Todavía estaba saliendo con mis viejos amigos de la universidad, pasando tiempo solo con ellos. Haz muchos amigos en tu lugar de trabajo y respeta a tus colegas.
7. Haciendo algo que odias. Si se ve obligado a hacer algo que odia, cambie de trabajo de inmediato.
8. Tener miedo y no asumir responsabilidades. Asumir responsabilidades (¿Por qué las personas mayores se divierten tanto?)
9. Centrándose solo en su trabajo. Participe en otras actividades extracurriculares, desarrolle nuevos pasatiempos, trabaje por cualquier causa, ONG o algo así. No solo es bueno moralmente, también te ayudará en tu carrera, algo como esto es genial para tu currículum.

• Ser descuidado: se olvidan de hacer una copia de seguridad, eliminar todo System.out.print antes de que su aplicación entre en producción, tomar instantáneas, etc.
• Encontrar soluciones fáciles: intentan ahorrar tiempo y agonía mental saltando directamente en la búsqueda de soluciones. Las soluciones están a solo un clic de distancia. No solo comience la búsqueda de soluciones en el momento en que se enfrente a un problema o error. Incluso si copia de la solución de otros, no olvide aprender y comprender la solución. Esto ayudará a largo plazo
• Zona de confort: conservan su idioma o tecnología favorita. Siempre agregue nuevos idiomas o tecnologías en sus conjuntos de habilidades. Un desarrollador de Java no debería tener miedo de escribir un script Python o un script de shell si es necesario.
• Documentación de odio: piensan que la documentación es una pérdida de tiempo. La documentación es tan importante como la codificación. Habrá muchos otros programadores que recomendarán o usarán su proyecto. No hagas de su vida un infierno.
• Prueba de odio: probar su aplicación es primero su responsabilidad y luego el equipo de prueba.

Hola a todos,

Mucha gente ha respondido con tanto detalle, supongo que eso dice mucho de su propio aprendizaje personal de la industria.

A continuación se muestra lo que creo que es importante:
1. Aprende a respetar a tus mentores: esta es la clave porque no encontrarás demasiados. Si alguien se interesa en prepararte, dale una oportunidad y comprende de dónde viene.
2. Ser humilde: Comprenda que debe tener los pies firmemente plantados en el suelo y controlar su ego y su juicio personal de vez en cuando para que no se interponga en su camino mientras toma decisiones importantes que afectan a todo el equipo y no solo a su carrera propia
3. Comprender las inquietudes de los demás: cuando ascienda para liderar o administrar equipos, comprenda sus inquietudes y desafíos al hacer algo y verifique si puede resolverlos o habilitarlos.
4. Habilite equipos y comprenda las aspiraciones de las personas: cuando se convierta en líder, y tenga un equipo a su cargo, comprenda lo que puede hacer para facilitarle la vida a su equipo y también vea si puede abordar sus aspiraciones dándoles la oportunidad de realizar en un rol o tecnología que les gusta
5. Abierto al aprendizaje: es muy importante que uno no se quede atascado con una tecnología o habilidad durante toda su carrera. Es importante ser multifuncional y capacitarse en múltiples habilidades para ser útil para diversas tareas que pueden tener diferentes demandas.
6. Administrar las finanzas: Mucha gente piensa que esta carrera es para siempre, que pueden compensar el tiempo perdido, la mala administración de las finanzas, pero nada de eso es cierto. Es importante elegir sus inversiones con prudencia y planificarlas en consecuencia para que sea posible jubilarse temprano o, de ser así, renunciar a la profesión y hacer algo que sea menos estresante.
7. Aprenda a apreciar el trabajo de los demás y triunfe como equipo: comprenda cuáles son las fortalezas o debilidades de cada persona y vea si puede ayudarlos a ganar junto con usted como equipo en lugar de luchar por el éxito aislado
8. Controle siempre sus emociones: es clave que mantenga su equilibrio emocional y no haga que sus emociones se apoderen de usted cuando necesite enfrentarse a un colega o cualquier conflicto o disputa en el trabajo. Necesidad de tener una cabeza objetiva que una subjetiva emocional
9. Esfuércese por sobresalir: luchar por la perfección para llegar al segundo peldaño, pero eso es algo que debe perseverar para lograr y lograr.

Espero que esto haya ayudado. Salud.

Creo que puedo escribir una buena respuesta para esto. Este es mi propio ejemplo. Soy un ingeniero informático que una vez fue colocado en un conocido Compony de TI (en 2011). Estaba feliz y estaba listo para unirme a Compony. Estaba esperando para mi ingreso después de la graduación (2012). Pero debido a la recesión económica, mi ingreso se retrasó. Hasta entonces me presenté para los exámenes del gobierno, el examen MBA. CDS autorizado pero no pude borrar el SSB. En enero de 2013 obtuve mi fecha de ingreso como agosto 2013
* Primer error esperar 1 año.
El entrenamiento combinado fue riguroso. El grupo experimentó con el entrenamiento para nuestro lote. Después de completar el entrenamiento, se dieron 2 oportunidades para completar un examen final. En la primera oportunidad, los que hicieron trampa tuvieron éxito. Por lo tanto, para la segunda oportunidad, todos participaron en el engaño. También copié un poco. Pero hacer trampa es hacer trampa. El grupo despidió a un lote entero (de alrededor de 80 empleados) de empleados que aparecieron por segunda vez.
* Segundo error.
Después de perder el trabajo busqué trabajo. Me entrevistaron en Amazon y Barclay’s, pero no podía explicar por qué me fui de Compony anterior. No pude resistirme a hablar mal de un empleador anterior en la entrevista de Barclay.
* Tercer error.
Conseguir un trabajo fue difícil para mí. Me preparé para el examen de admisión de MBA. Obtuve la admisión en una universidad decente. Pero esos 2 años me enseñaron mucho.

No vi a nadie mencionar la codificación de caracteres:

• No usar codificación UTF en proyectos desde el principio.
• Se espera que todo el tráfico TCP entrante u otras matrices de bytes se codifiquen como texto predeterminado del sistema.

No vi nada sobre el cifrado:

• No utiliza la sal adecuada de los hashes de contraseñas.
• Uso de algoritmos hash débiles como MD5.
• Suponiendo que cifrar algo automáticamente firma cosas y verifica al remitente, etc.

Por último, pero no menos importante, no leer ¿Cuáles son los secretos mejor guardados de los grandes programadores?

Todos han hablado mucho sobre cometer errores con la codificación, algos, etc.
Los errores que me gustaría enumerar son un poco diferentes.
1. No comprometa su salud porque está trabajando hasta tarde, etc. Usted tiene mucho más dinero para gastar que podría como estudiante. Gaste en su salud sin estropearlo. La mayoría de las personas ganan alrededor del 20% de peso en el primer año de su carrera.
2. Estar emocionalmente apegado al código que has escrito o al proyecto en el que estás trabajando. No te molestes si el proyecto está enlatado o si el código que has escrito se desperdicia. Siempre es una experiencia de aprendizaje.