Cómo mejorar mis habilidades de ingeniería de software

Answer 1

Tradicionalmente soy un programador de sistemas integrados. Tengo más de una década de experiencia escribiendo descripciones de hardware, firmware y aplicaciones GUI para interactuar con las cosas. Es fácil entrar en el ritmo y simplemente codificar lo que sabes. Aquí están mis caminos para continuar creciendo:

• Explora reinos desconocidos. Hice desarrollo web en mi juventud y recientemente volví a hacerlo como una exploración personal. Es un poco diferente ahora por decir lo menos. He aprendido muchísimo al explorar cómo los desarrolladores web logran la modularidad y la gestión del flujo de trabajo. Hay muchos reinos, y con todos los kits de desarrollo disponibles ahora, incluso puede incursionar fácilmente en el desarrollo integrado.
• Explore la filosofía del software . Busca libros sobre el tema. Lea sobre las opiniones de otros desarrolladores sobre software y resolución de problemas en un sentido general.
• Como dijo Chris Prakoso, aprende nuevos idiomas. Hay toneladas de ellos por ahí. Estoy aprendiendo Rust en este momento y lo entiendo hasta ahora. Realmente profundice y asegúrese de comprender el problema que el idioma intenta resolver y las aplicaciones para las que está destinado.
• Explore el código de fuente abierta. Busque proyectos que considere interesantes y mire el código fuente para descubrir cómo los desarrolladores lograron la tarea. Recientemente utilicé ArrayFire para un proyecto informático de GPU y creo que están haciendo un trabajo increíble con esa biblioteca. Cuando fueron de código abierto, fue como Navidad para mí. ¿Quieres decir que puedo ver toda la fuente de esto? Sí por favor.
• Y el santo grial: exponga su código a los demás. Espero que ya hagas esto. Encuentre desarrolladores que respete y solicite comentarios, intente contribuir a sus proyectos, etc.

Eso es lo que me funciona de todos modos. Recién estoy comenzando en la comunidad de código abierto de GitHub y estoy entusiasmado con eso. Hay tanto que aprender.

Gracias Batanayi Matuku por la pregunta.

Answer 2

Los problemas subyacentes que pude identificar son

1. Sobrecarga de información : demasiados detalles y perderse en el laberinto de código.
2. Ley de rendimientos decrecientes: apresurarse a trabajar en un problema y mantenerlo durante mucho tiempo
3. Frustración o parálisis de análisis o asfixia (y tal vez ataque de pánico): demasiadas metas / todos / objetivos inacabados que desplazan el problema inmediato.

La mejor solución para la mayoría de estos problemas que conozco hasta la fecha es este libro (también hay un curso gratuito en video disponible en Coursera):
Reseña del libro: “Una mente para los números” por Barbara Oakley. (Uso de la configuración predeterminada del cerebro para la resolución de problemas de aprendizaje, matemáticas y ciencias) por Gurudutt Mallapur en Aprender a aprender

---

1) Meseta técnica:

• “Patrones de aprendizaje: orientación para el aspirante a artesano del software” por Ade Oshineye y Dave Hoover: Libro en línea gratuito de código abierto “Patrones de aprendizaje”. Este libro está destinado a crecer técnicamente en el campo del software desde principiante hasta maestro artesano. Sin embargo, los “patrones de aprendizaje” son útiles independientemente del campo y pueden usarse en la mayoría de los otros campos.
• Salto del orden de magnitud de la productividad: la respuesta de Tony Reno a ¿Cómo puedo obtener un orden de magnitud más inteligente, más brillante, más nítido y más productivo que lo que soy ahora?
• Tiempo limitado para aprender: la respuesta del usuario de Quora a ¿Cómo puede desarrollar sus habilidades de programación cuando no está frente a su computadora?

2) Código de filtrado versus código de desarrollo:

Código de filtrado: requiere una habilidad diferente que escribir código: corrección de errores y depuración por Gurudutt Mallapur en techtalkies

Código de desarrollo:
Lo que estás haciendo (escribir y reescribir) es lo correcto. Una palabra de moda técnica para eso es ‘ReFactoring’ en la programación ágil. Lo mejor no es combatirlo, sino aprender de él escribiendo versiones pequeñas y agregando al control de versiones de Git. Continúe reescribiendo de una manera mejor y más ‘refactorizada’. Lleva algo de tiempo pero no tanto como para hundirte.

3) Unirse a proyectos de código abierto / proyectos de juguetes:

Puedes probar esto en tus propios proyectos de juguetes. Entrar en “detalles irrelevantes” está nuevamente relacionado con el perfeccionismo y la parálisis del análisis. El libro que mencioné te ayudará a salir del vórtice que estás enfrentando.

Respuesta del usuario de Quora a ¿Dónde puedo encontrar proyectos de código abierto para construir desde cero?

Las respuestas a continuación no son todas iguales, algunas solo requieren un pequeño cambio en la forma de abordar las cosas, otras pueden requerir mucho autodesarrollo del paciente y romper las barreras mentales (es decir, soluciones a corto, mediano y largo plazo). Mi sugerencia es usar primero las cosas que funcionan para usted más rápido. Esto lo ayudará a seguir adelante con buenos comentarios en cada paso.

Tomará tiempo, pero esperamos que los resultados que obtenga le ayuden a hacer su trabajo más rápido y a obtener más consejos para ahorrar tiempo y trabajo.

La respuesta del usuario de Quora a ¿Puede el conocimiento y la comprensión repetidos conducir finalmente a la síntesis?

Mis 2 blogs sobre “Aprendizaje específico de software y” Aprender a aprender “contienen preguntas variadas que he respondido en Quora. Me cansé de buscarlas cada vez que alguien hace una pregunta, así que las he reunido en estos 2 blogs.

Nota: Mis respuestas muchas veces no coinciden con la pregunta explícita, pero trato de abordar los problemas subyacentes que causan el problema y dar la solución en consecuencia.

1. Techtalkies
2. Aprendiendo a aprender (L²L)

Answer 3

Intentaré responder con comentarios específicos.

Orientación en una nueva base de código y ser productivo con ella. Paso mucho tiempo para asimilar un código.

Viene con experiencia ya que comprender el código de otros no es fácil. Supongo que cuanto más trabajas con proyectos heredados, más desarrollas esa habilidad. La mayoría de las veces no lo entendemos porque odiamos ese código y pensamos que lo habríamos hecho de manera diferente (o mejor). Comienza a leer el código fuente abierto de los proyectos que admiras.

Si leo una interfaz, me lleva mucho tiempo, a veces nunca, obtener una “sensación” intuitiva.

Podría significar que la interfaz no estaba bien diseñada o porque carece de filosofía parte del software. Viene con la comprensión del diseño y la filosofía de los proyectos de código abierto y no solo de usarlo leyendo la guía de referencia. Además, cuando más discuta con sus compañeros y superiores, más comienza a desarrollar la filosofía del código.

Cuando desarrollo, hago muchos comienzos falsos. Escribo un código Luego hay que reescribirlo, luego nuevamente.

No saltes directamente a la codificación. Tome lápiz y papel y visualice el código del problema que está resolviendo. Puede dibujar algunas cajas e involucrar a un compañero. 1 hora que pases así eventualmente será muy productiva al momento de escribir el código.

Me gustaría contribuir al código abierto. Pero las cosas que encuentro interesantes a menudo me parecen un muro de código impenetrable. Tanto es así, que termino de dejar de contribuir, simplemente porque lleva mucho tiempo entender cómo hacer las cosas y dónde.

No todos los desarrolladores terminan siendo contribuyentes de código abierto. Para contribuir no tiene que entender todo el código base. Comience desde el rastreador de problemas de ese proyecto para rectificar errores y enviar parches. Cuantos más errores resuelva, más aumentará la familiaridad con esa base de código.

Intento jugar con mis propios proyectos. Pero no equivalen a nada porque me disuelvo en mirar detalles irrelevantes hasta que eso me abruma y me doy por vencido.

Por eso se dice que codebase no es una novela. No se puede leer en su totalidad de principio a fin. La familiaridad de una base de código aumenta a medida que la apunta con una intención específica, como desarrollar una función o rectificar un error. Eso se aplica también a código abierto. Comience con el rastreador de problemas e intente solucionar un error.

Por supuesto, está el otro lado de esto. Tal vez solo fui lo suficientemente inteligente como para llegar a donde estoy ahora, que mi creencia de que puedo mejorar es falsa y no tiene sentido tratar de ir más allá de eso, porque el más allá nunca puede llegar a ser.

Esto nunca es correcto. Siempre hay capacidad de ir más allá. Si no por otra razón, simplemente porque todos los días está escribiendo código y resolviendo variantes de problemas existentes. Incluso sin saberlo, mejorarás. Solo mira el código que usaste para escribir 3 años atrás y lo sabrás.

Además, para hacerlo interesante, siempre piense desde el punto de vista del rendimiento. Incluso si está trabajando para una empresa que no recibe mucho tráfico y, por lo tanto, no requiere sistemas de alto rendimiento. El código más simple que escriba deberá escribirse de manera muy diferente si desea lograr un rendimiento mucho mayor.

Answer 4

Dé un paso a la vez, consideremos el siguiente problema tomado del juez en línea de UVa.

Juez en línea de UVa

Dado el enunciado del problema anterior, dado el conocimiento actual de la moneda de Nueva Zelanda, podemos diseñar una recursión simple para este problema

int maneras (int M [], int f, int h)
{

si (h == 0)
retorno 1;

si (h <0)
devuelve 0;

si (f <= 0 && h> = 1)
devuelve 0;

formas de retorno (M, f – 1, h) + formas (M, f, hM [f-1]);
}

Pero este es solo el conocido problema del problema de la moneda y debería ser lo suficientemente fácil de resolver dada la recurrencia anterior.

int cuenta (int M [], int f, int g)
{
int i, j, x, y;

int dp [g + 1] [f];

para (i = 0; i dp [0] [i] = 1;

para (i = 1; i {
para (j = 0; j {

x = (iS [j]> = 0)? dp [i – M [j]] [j]: 0;

y = (j> = 1)? dp [i] [j-1]: 0;

dp [i] [j] = x + y;
}
}
devolver dp [g] [f-1];
}

Es una solución en [matemáticas] O (M ^ 2N ^ 2). [/ Matemáticas]

Es un problema directo del juez de UVa Online.

Answer 5

¡Nunca habrá ningún ‘plateu’ en Ingeniería de Software! Siempre hay cosas que mejorar, incluso si crees que lo sabes todo, y cosas nuevas que aprender.
Haz un balance de lo que has conocido. Profundiza, ¿hay más que puedas aprender? Algunas características avanzadas del lenguaje de programación o metodología.
Si crees que lo sabes todo. ¿Por qué no intentas aprender otro idioma? Si has estado haciendo programación de escritorio, ¿por qué no pruebas el desarrollo web? Hay muchas cosas que aprender allí para durar otros 10 años, ¡confía en mí! O viceversa.
En términos de Ingeniería de Software en general, ¿cómo ha estado haciendo su proceso de desarrollo? ¿Qué método estás usando en tu SDLC?
Si ha estado utilizando el modelo Cascada, ¿por qué no prueba el proceso iterativo? ¿Conoces el método ágil? ¿Qué hay de SCRUM y Kanban? Hay mucho que aprender allí.

Los recursos son abundantes. Puedes encontrar todo lo que quieras aprender de la red.

Prueba estos recursos:

Gratis:
Aprende a codificar
Coursera – Cursos gratuitos en línea de las mejores universidades
Tutoriales web en línea de W3Schools
edX
academia Khan
Aprenda HTML5, CSS3, Javascript
Todo niño merece una oportunidad

O pagados:
Cursos en línea: en cualquier momento y en cualquier lugar | Udemy
Habilidad
Video tutoriales y capacitación en línea
Aprenda diseño web, desarrollo web y más
Sobre nosotros – Proyecto Euler
Aprendible

Avísame si te estás quedando sin cosas para aprender 🙂

Answer 6

Su problema se está extendiendo demasiado delgado.
Está bien leer y construir pequeños PoC para muchas áreas temáticas para que tenga una idea del paisaje del área en la que trabaja, lo que le permite saber dónde es valioso bucear en profundidad.
Pero, ¿cuál es el punto de sumergirse en un área a menos que sea de utilidad práctica para usted? Como usted dice, solo hay un cierto número de horas en el día.
Así que lea las cosas tal como están, pero en términos de mejorar sus habilidades en un área en particular: la práctica es la única forma de mejorar y sumergirse profundamente en el área en la que desea especializarse.
Si se trata de codificación, investigue la herramienta que usa todos los días: qué puede aprovechar que no conozca. Pregunte y obtenga consejos y sugerencias: la programación de pares es excelente para esto (o emparejar cualquier cosa).
Pero, sobre todo, no se obsesione con la creación de código excelente y la planificación con interfaces para futuras personas que quieran utilizar el código. Hackéalo de la manera más rápida y sucia posible para que entiendas cómo encaja todo, los problemas asociados con el área que estás mirando y cómo el método rápido y sucio causa problemas horribles cuando tratas de desarrollarlo .
Pero luego refactorice, solo entonces, cuando vea dónde están los puntos débiles y dónde está el código inútil que no necesita estar allí.
Al concentrarse en el 20% de la funcionalidad y estructura esenciales para hacer el trabajo, se ahorra enormes cantidades de tiempo.
Entonces es un 20% más de tiempo para refactorizar a algo más útil
etcétera etcétera.
En lugar de tratar de obtener el 80% de la funcionalidad, la mayoría no se utilizará.
No es la metodología de ingeniería de software de estilo cascada tradicional, pero es una realidad para las personas productivas. Negarse a hacer lo que todos los demás dicen que es importante, y hacer solo lo que sabe que es esencial.
Ágil significa fallar rápido, fallar frecuentemente, aprender y hacerlo mejor la próxima vez.
En lugar de fallar después de 18 meses, cuando el sistema cuidadosamente diseñado resulta ser algo que nadie realmente quiere.

Answer 7

Otros ya han abordado bien su pregunta; Me gustaría ampliar solo la parte sobre la elegancia. No creo que la inteligencia juegue un papel muy importante para poder crear algo elegante, al igual que el talento en realidad no juega un papel importante para poder dibujar. Es solo una gran cantidad de práctica. La mayoría de los pintores tendrán imágenes tempranas muy feas, es solo que de alguna manera persistieron y aprendieron de sus errores.

Si cree que su código es demasiado complejo, probablemente lo sea; intentar algo diferente. Por ejemplo, ¿quién dijo que incluso necesita interfaces, jerarquías mucho menos complejas? Escribir pato es divertido, y también lo es EAFP (más fácil pedir perdón que permiso).

También tenga en cuenta que cada programa debe redactarse al menos dos veces: la primera versión solo para descartarla (pero si planea desecharla, también descartará la segunda, así que haga lo mejor que pueda).

Answer 8

Entiendo de dónde vienes, pero esto parece ser más una falta de confianza que de habilidad.

Lo primero que debes recordar es que nunca dejas de aprender. Incluso los codificadores más talentosos del mundo no lo saben todo. Es imposible. Aproveche la búsqueda en Google y en cualquier cantidad de foros y sitios de codificación para ampliar su conocimiento y crear un repositorio de fragmentos de código.

A continuación, solo se vuelve “intuitivo” en el software o una interfaz al usarlo, y con frecuencia. Por ejemplo, la primera vez que usé OSX fue una curva de aprendizaje real. En ese momento era un usuario de Windows 100%, pero con el tiempo aprendí más y más sobre cómo funcionaba OSX. Encontré las similitudes entre OSX y Windows, lo que también me ayudó a tener más confianza con el software.

En general, aborde su problema de confianza. Ese parece ser su problema subyacente. Y desafíate a ti mismo. Asuma proyectos personales que desafíen su base de habilidades, y al hacerlo, aprenderá y experimentará mucho más, lo que lo ayudará a avanzar más adelante.

¡Buena suerte!

Answer 9

No estoy seguro de cuánto tiempo ha sido desarrollador, pero parece que no siempre y cuando no tenga tanta confianza en su trabajo. Lo que hace que un desarrollador sea bueno / excelente es la experiencia. Experiencia en muchos tipos diferentes de problemas desafiantes. Parece que realmente deberías esforzarte. Sal de tu burbuja y prueba algo nuevo. Te sorprendería cuánto más aprenderás sobre programación si cambias de idioma o incluso de plataformas. Especialmente, si cambia de idioma, verá cómo diferentes idiomas resuelven el mismo problema y esto le dará más ideas sobre cómo resolver aún más problemas.

Answer 10

Creo que te abrumas con leer códigos y no escribir códigos.
Solo practicar y fallar y practicar nuevamente y fallar nuevamente te hará mejorar.
Aprenda a ver los softwares como solución a los problemas … así que trate de comprender el problema que el software está tratando de resolver antes de leer los códigos.
No ponga demasiado énfasis en escribir códigos extremadamente elegantes … el desarrollo de software es continuo. Está destinado a mejorar las horas extras.

Answer 11

No estoy seguro, pero recomendaría estudiar en libros básicos que puede buscar fácilmente en Google y no ir a libros de alta gama como
“Ingeniería de software: un enfoque profesional
Libro de Roger S. Pressman ”
También hay conferencias disponibles en sitios como coursera o edx que pueden aclarar sus conceptos.
Al final, si estás en contacto con un buen maestro, esto sería como la cereza del pastel, sin embargo, si tienes un maestro increíble como el mío, seguramente te colocarán en ADOBE, incluso todo tu lote se colocará.