Soy un desarrollador de copiar y pegar, ¿cómo me convierto en un verdadero desarrollador de software?

Ser un desarrollador de software tiene que ver con copiar y pegar. Solo piense en la realidad del trabajo:

• Raramente comenzamos desde cero. Casi siempre está trabajando con el código existente en lugar de crear un nuevo proyecto vacío en el IDE.
• Lo que sea que esté haciendo ahora, lo más probable es que se haya hecho hasta la muerte durante años. ¿Cuántos calendarios ha implementado el mundo? ¿Los motores de búsqueda? Bases de datos? ¿Sistemas de información? Inventarios en el juego? Calculadoras?

• En referencia a lo anterior: no reinventes la rueda. Hay una razón por la que copiamos y pegamos: si el código está disponible y no es propietario, entonces, ¿por qué no usarlo? Está ahorrando tiempo, esfuerzo y, por lo tanto, dinero para el proyecto. Tiene sentido comercial.

Así que no menosprecies lo que estás haciendo ahora. Sin embargo, es cierto que eso no es todo lo que hace un buen desarrollador de software.

No se trata de lo que copiaste sino de cómo usas lo que pegaste.

Recuerde: no está escribiendo código, está desarrollando software. Y hay más que código: el SDLC lo dice todo. Requisitos, arquitectura, diseño, algoritmos, implementación, pruebas … todo eso antes de la implementación real.

Digamos que nos centramos únicamente en la implementación, parte de la codificación. Tome la analogía de construir una casa, por ejemplo. Puedes mirar la casa de tus vecinos y decir “Hola, quiero su techo y su césped” y así sucesivamente. Esta bien. Ahí es donde se detendrá una simple copiadora. Un buen constructor de casas se hará más preguntas (suponiendo que ya estamos en la fase de implementación):

• ¿Su techo realmente hace lo que yo quiero que haga mi propio techo?
• ¿Cuán efectivos y eficientes son sus diseños de vivienda en realidad?
• ¿Se integrarían bien estas piezas de las casas de todos para formar una casa en la que esté dispuesto y pueda vivir?
• ¿Estas piezas siguen buenos principios de diseño?
• Si quiero modificar mi casa en el futuro, ¿cuánto tiempo, recursos y esfuerzo me tomaría si uso estas piezas?

Estos son solo algunos puntos. Como desarrollador de software, su cliente potencial probablemente le dará una tarea para implementar algo. El enfoque más fácil (generalmente el más preferible) es usar el código existente que hace el trabajo: el código escrito desde cero, especialmente cuando se vuelve complejo, como suele ocurrir con el código del mundo real, tiende a ser más erróneo que los existentes. código en el mundo real. La pregunta es si DEBE usarlo. No es diferente de elegir entre algoritmos u opciones de diseño: también hay un montón de código para elegir al copiar y pegar.

En primer lugar, es genial que sepas que hay una diferencia, aunque tampoco seas demasiado duro contigo mismo. Personalmente, no creo que haya un “desarrollador de software real”, porque lo veo como una habilidad en la que cada individuo difiere.

Pero creo que también sé lo que significa, y para mí las respuestas son relativamente simples:

1. Concéntrese en “Habilidades para resolver problemas”, y eso es 100% independiente de una computadora. Poder dividir las cosas en tareas cada vez más pequeñas y fáciles de resolver es una de las habilidades principales de un desarrollador y poder hacerlo lógicamente es una habilidad muy importante.
2. Eso conducirá a la segunda parte, que es:
   Tenga un buen “juego de herramientas” de habilidades de desarrollo “base” – no se convierta en un programador tipo “I program in Language XYZ”. Comprenda los conceptos más en lugar de implementaciones específicas de los conceptos.
   es decir, comprender los principios y las ventajas y desventajas de la “programación orientada a objetos”; no aprenda la implementación específica de lenguaje de OOP en un idioma.

No sé si eso lo convertirá en un desarrollador “real”, pero comenzar con esto y seguir con lo que otros han dicho lo convertirá en un mejor desarrollador, y ese es el objetivo real: constantemente ser un poco mejor de lo que era antes .

Buena suerte !

Como desarrollador de software, entiendo la usabilidad de copiar y pegar. Pero definitivamente tiene pros y contras como decimos “La moneda tiene dos lados”

Pros:

Si el código realmente vale la pena copiar, como algún algoritmo (búsqueda binaria o fusión, clasificación, etc.) o algún código o funcionalidad que debe codificarse de manera particular para ganar eficiencia, escalabilidad y no olvide considerar la complejidad. Definitivamente vale la pena copiarlo porque tiene que estar codificado de esa manera.

Contras:

Pero en algún momento la funcionalidad existente puede causar otro impacto, como cada cambio de versión en las API, consideremos que Java está inventando o mejorando algunas otras API en cada versión que lanzan, por lo que su antiguo código debe cambiarse en función de la nueva API o conjunto de versiones. no aprovechará esos cambios en la API.

En algún momento, el viejo codificador realmente no ha pensado bien en todos los escenarios requeridos para la funcionalidad existente, si está copiando este tipo de funcionalidad sin pensar que está dando la alarma roja.

Copiar y pegar puede obstaculizar las posibilidades de mejorar el código según las nuevas tecnologías o las API que se inventan cada año.

Entonces, en mi opinión, depende de lo que esté copiando y de cuánto comprenda la funcionalidad existente antes de copiar.

También me he enfrentado, el desarrollador (mi ejemplo :)) no tiene la posibilidad de cambiar o argumentar los cambios requeridos en el código existente, por lo que todo depende del líder del equipo o el gerente para comprender sus pensamientos. Pero definitivamente diría que piense en hablar antes de copiar a ciegas cualquier código existente.

Primero, eres un verdadero desarrollador de software. Se le paga dinero para crear software, bienvenido a la carrera.

Segundo, no estás solo. De hecho, no eres una minoría. Ni siquiera estoy sugiriendo que lo estés haciendo mal.

Creo que lo que realmente está llegando es que su carrera llegará a un obstáculo si se limita al “desarrollo por Google”, es decir, solo puede resolver los problemas que alguien más ha resuelto antes (y se tomó el tiempo para documentar de alguna manera puedes descubrir). Eso es probablemente cierto.

Supongo que su proceso es algo como esto:

1. Lea sobre el problema en un boleto JIRA
2. Encuentra palabras clave o mensajes de error y google
3. Encuentre una pregunta sobre Desbordamiento de pila similar
4. Encuentra la respuesta que se ve bien (probablemente la aceptada)
5. Copie la solución de SO a su base de código
6. Probar que la solución funciona
7. Cometer

Sigue haciéndolo. Pero agreguemos algunos pasos:

1. Lea sobre el problema en un boleto JIRA
2. Escriba una descripción de lo que cree que podría ser el problema antes de buscar la solución.
3. Escriba una (s) prueba (s) que reproduzca el problema.
4. Regrese al paso 2: ¿cree que comprende el problema lo suficiente como para resolverlo sin copiar / pegar? Si es así, salte al paso 9.
5. Encuentra palabras clave o mensajes de error y google
6. Encuentre una pregunta sobre Desbordamiento de pila similar
7. Lea todas las respuestas, no solo la aceptada.
8. Encuentra la respuesta que se ve bien (probablemente la aceptada)
9. Escriba la solución en su código base C̶o̶p̶y̶ ̶t̶h̶e̶ ̶s̶o̶l̶u̶t̶i̶o̶n̶ ̶f̶r̶o̶m̶ ̶S̶O̶ ̶t̶o̶ ̶y̶o̶u̶r̶ ̶c̶o̶d̶e̶ ̶b̶a̶s̶e̶ ̶
10. Si está escribiendo algo que no entiende, tómese el tiempo para entenderlo.
11. Demuestre que la solución funciona (ejecute la prueba que escribió en el paso 3). Si esto falla, regrese al paso 1.
12. Solicitar una revisión de código. Por eso dije que entendiera su código en el paso 10. Debe estar preparado para explicarlo.
13. Cometer
14. Revise el paso 2: ¿qué tan cerca estuvo de adivinar la causa?

El objetivo aquí es hacer tres cosas:

1. Dedique tiempo a pensar en el problema antes de resolverlo. La ingeniería de software es largos períodos de pensamiento marcados por breves momentos de mecanografía.
2. Cree una prueba para reproducir y validar el problema. Simplemente escribir la prueba a menudo es suficiente para resolver el problema. Eso tiene sentido. Escribir una prueba fallida significa que comprende la ruta de falla, lo que a menudo hace que la ruta correcta sea obvia.
3. Escribir a mano la respuesta te obliga a pensar más sobre la solución. Buscar en Google las partes que no entiendes llena los vacíos de conocimiento. Este nuevo conocimiento, con el tiempo, lo ayudará a refinar su intuición de lo que está mal antes en el proceso.

Sigue haciendo esto y con el tiempo. Hará que algunas cosas tarden un poco más, pero con el tiempo serás un ingeniero mucho (mucho) más productivo (y conocedor).

Aquí hay algunas formas de convertirse en un mejor desarrollador de software:

1. Recuerda cuánto tienes que aprender

El primer paso para aprender algo es reconocer que no lo sabes. Eso suena obvio, pero los programadores experimentados recuerdan cuánto tiempo llevó superar esta suposición personal. Demasiados estudiantes de ciencias de la computación se gradúan con una arrogante bravuconería “Yo sé mejor”, una certeza sólida de que lo saben todo y la intensa necesidad de demostrarlo a cada nuevo compañero de trabajo. En otras palabras: tu actitud de “¡Sé lo que estoy haciendo!” Puede obstaculizar el aprendizaje de algo nuevo.

2. Deja de intentar demostrar que tienes razón

Para ser grandioso, no solo bueno, tienes que aprender de la experiencia. Pero tenga cuidado, la experiencia puede enseñarnos a repetir el mal comportamiento y crear malos hábitos. Todos nos hemos encontrado con programadores con ocho años de experiencia … el mismo año de experiencia, repetidos ocho veces. Para evitar ese síndrome, mire todo lo que hace y pregúntese: “¿Cómo puedo mejorar esto?”

Los desarrolladores de software novatos (y demasiados experimentados) miran su código para admirar su maravilla. Escriben pruebas para demostrar que su código funciona en lugar de intentar que falle. Los programadores verdaderamente buenos buscan activamente dónde están equivocados, porque saben que eventualmente los usuarios encontrarán los defectos que se perdieron.

3. “El código funciona” no es donde te detienes; es donde comienzas

Sí, su primer paso es siempre escribir un software de calidad que cumpla con las especificaciones. Los programadores promedio renuncian en ese punto y pasan a lo siguiente.

Pero detenerse una vez que está “hecho” es como tomar una instantánea y esperar que sea una obra de arte. Los grandes programadores saben que la primera iteración es solo la primera iteración. Funciona, ¡felicidades! Pero no has terminado. Ahora, hazlo mejor .

Parte de ese proceso es definir qué significa “mejor”. ¿Es valioso hacerlo más rápido? ¿Más fácil de documentar? ¿Más reutilizable? ¿Más confiable? La respuesta varía con cada aplicación, pero el proceso no.

4. Escríbelo tres veces

Los buenos programadores escriben software que funciona. Los grandes escriben software que funciona extremadamente bien. Eso rara vez ocurre en el primer intento. El mejor software generalmente se escribe tres veces:

1. Primero, escribe el software para probarse a sí mismo (o a un cliente) que la solución es posible. Otros pueden no reconocer que esto es solo una prueba de concepto, pero usted sí.
2. La segunda vez, lo haces funcionar.
3. La tercera vez, haces que funcione bien .

Este nivel de trabajo puede no ser obvio cuando nos fijamos en el trabajo de los mejores desarrolladores. Todo lo que hacen parece tan brillante, pero lo que no ves es que incluso los desarrolladores de estrellas de rock probablemente tiraron la primera y segunda versión antes de mostrar su software a nadie más. Tirar el código y comenzar de nuevo puede ser una forma poderosa de incluir “mejorarlo” en su flujo de trabajo personal.

Por lo menos, “Escríbelo tres veces” te enseña cuántas maneras hay de abordar un problema. Y evita que te quedes atrapado en una rutina.

5. Leer el código. Lee mucho código

Probablemente esperabas que liderara con este consejo, y de hecho es la sugerencia más común y más valiosa para mejorar las habilidades de programación. Lo que es menos evidente son las razones por las que leer el código de otros es tan importante.

Cuando lees el código de otros, ves cómo alguien más resolvió un problema de programación. Pero no lo trates como literatura; Piense en ello como una lección y un desafío. Para mejorar, pregúntate a ti mismo:

• ¿Cómo habría escrito ese bloque de código? ¿Qué harías diferente, ahora que has visto otra solución?
• ¿Que aprendi? ¿Cómo puedo aplicar esa técnica al código que escribí en el pasado? (“Nunca hubiera pensado usar descenso recursivo allí …”).
• ¿Cómo mejoraría este código? Y si es un proyecto de código abierto en el que está seguro de tener una mejor solución, ¡ hágalo!
• Escribe el código en el estilo del autor . Practicar esto te ayuda a meterte en la cabeza de la persona que escribió el software, lo que puede mejorar tu empatía.

No solo piense distraídamente en estos pasos. Escriba sus respuestas, ya sea en un diario personal, un blog, en un proceso de revisión de código o en un foro comunitario con otros desarrolladores. Así como explicar un problema a un amigo puede ayudarlo a resolver la solución, escribir y compartir su análisis puede ayudarlo a comprender por qué reacciona ante el código de otra persona de una manera determinada. Todo es parte de esa introspección que mencioné anteriormente, que te ayuda a juzgar desapasionadamente tus propias fortalezas y debilidades.

Advertencia: es fácil leer una gran cantidad de código sin convertirse en un gran programador, del mismo modo que un aspirante a escritor puede leer una gran literatura sin mejorar su propia prosa. Muchos desarrolladores miran el código abierto u otro software para “encontrar una respuesta” y, muy probablemente, para copiar y pegar código que parece resolver un problema similar. Hacer eso en realidad puede convertirte en un peor programador, ya que aceptas ciegamente la sabiduría de los demás sin examinarla. (Además, puede ser más molesto que un picnic de verano, pero como no te tomaste el tiempo para entenderlo, nunca reconocerás que acabas de importar una fábrica de insectos).

6. Escribir código, y no solo como tareas

Trabajar en proyectos de programación personal tiene muchas ventajas. Por un lado, le brinda una forma de aprender herramientas y tecnologías que no están disponibles en su trabajo actual, pero que lo hacen más comercializable para el próximo. Ya sea que contribuya a un proyecto de código abierto o realice un trabajo pro bono para una organización comunitaria local, obtendrá habilidades tecnológicas y confianza en sí mismo. (Además, sus proyectos personales demuestran a los posibles empleadores que usted es un emprendedor que nunca deja de aprender).

Otra ventaja de escribir código por diversión es que te obliga a resolver las cosas por tu cuenta. No puede dejar las cosas difíciles a otra persona, por lo que le impide pedir ayuda demasiado pronto.

Consejo profesional: no elijas solo proyectos personales donde nunca fallas. ¡Necesitas fallar! Pero probablemente no quiera fallar en el trabajo o cuando tenga una fecha límite.

7. Trabaja uno a uno con otros desarrolladores de cualquier forma que puedas

Ayuda a escuchar a otras personas. Eso podría significar programación de pares, o ir a un hackathon, o unirse a un grupo de usuarios de programación (como Vermont Coders Connection). Cuando contribuyas a un proyecto de código abierto, presta atención a los comentarios que recibes de los usuarios y de otros desarrolladores. ¿Qué puntos en común ves en sus críticas?

Es posible que tenga la suerte de encontrar un mentor personal en quien pueda confiar para guiarlo en todo, desde técnicas de codificación hasta decisiones profesionales. No desperdicies estas oportunidades.

8. Aprende técnicas, no herramientas

Los lenguajes de programación, las herramientas y las metodologías van y vienen. Es por eso que vale la pena obtener tanta experiencia como sea posible con tantos idiomas y marcos como sea posible. Concéntrese en los fundamentos de la programación, porque lo básico nunca cambia; Presta más atención a la arquitectura que a la programación. Si está seguro de que solo hay una manera correcta de hacer algo, es probable que sea hora de realizar una verificación de la realidad. Dogma puede obstaculizar tu capacidad de aprender cosas nuevas y hacerte lento para adaptarte al cambio.

Los desarrolladores de software son solucionadores de problemas .

Hay dos formas de resolver problemas:

1. Pruebe todas las soluciones posibles que pueda obtener hasta que funcione.
2. Aprenda el sistema y comprenda la fuente del problema. Luego reconfigure el sistema para que el problema ya no exista.

Copiar y pegar es un mecanismo de búsqueda de soluciones. Sí, es malo cuando eso es todo lo que haces.

Como de costumbre, el enfoque correcto es usar ambos métodos .

El mejor enfoque para la resolución de problemas es rebotar de un lado a otro entre los dos tipos. Y use cada uno para apoyar al otro.

Cuando me encuentro con un nuevo problema, empiezo con el número 2, pero solo un poco, lo suficiente como para poder orientar las soluciones que encuentro en línea, las que pienso o una de otra parte del código. Luego, independientemente de si la solución funcionó, vuelvo a 2.

Cuando era más joven me detendría en 1 si funcionaba, si no, volvería a algunos más. Parar allí es lo que yo llamo suficiente . Es suficiente. Hace el trabajo

La batalla para mí es dejar de minimizar lo suficiente , siempre que no perjudique la necesidad comercial.

Buena suerte.

Vi esta pregunta en mi camino al trabajo y tuve que comentar. Escribí una publicación sobre esto en una fecha anterior, pero creo que es relevante: ¿cómo puedo dejar de ser un desarrollador de software promedio?

Me alegra que quieras convertirte en algo un paso por encima de las masas, incluso si no quieres convertirte en un maestro en eso. Escribí un algoritmo que estaba en proceso de publicación para ayudar a crear una herramienta para advertir a dichos “copiar y pegar” del uso de publicaciones X en StackOverflow para ayudarlos a evaluar su riesgo dada la similitud con el código en un proyecto de código abierto. No hay vergüenza en mirar o referirse a referencias en línea; esto puede ayudarlo a ser más rápido y liberar los recuerdos internos de su cerebro para almacenar información más relevante. Diablos, incluso lo hago todo el tiempo, pero miro las páginas del manual 😉 (lo siento, no hay barba de mago). El problema está en la mentalidad de copiar y pegar: va en contra de lo que debería ser un buen código, que es no reutilizar el código y codificar por diseño.

Vi otra gran publicación en este hilo que dice que debe mirar varios otros factores que simplemente copiar y pegar: por ejemplo, rastreadores de errores, código de ejemplo, documentación, etc., de una manera que realmente comprenda este problema. Este es un concepto interesante con el que hemos estado luchando con nuestros nuevos empleados recién salidos de la escuela o todavía en la escuela. La escuela y la sociedad actual en general son recompensas por hacer algo lo suficientemente bueno; en otras palabras, funciona, sigue adelante. Si bien esto es bueno de una manera que no te conviertes en un perfeccionista, es importante tener en cuenta la buena calidad y el esfuerzo.

Hacer que funcione algo que tiene pocas posibilidades de romperse más tarde es mucho más valioso que un programa prototipo rápido destinado a funcionar solo una vez. Entonces, para llegar a ese punto, debe comprender las variables en juego. Es como investigar un poco, obtener un montón de datos y sacar conclusiones sin numerosos controles para explicar la validez de sus datos; sin eso, terminas con afirmaciones sensacionales como que A es mejor que B porque lo es. No porque A sea mejor que B debido al factor C que causa el efecto Z 😉

Entonces mi lista rápida de sugerencias son:

• Educación formal hasta cierto punto para que hable el mismo idioma que el resto del dominio.
• Lea sobre la resolución de problemas / iniciativa , o intente resolver algo por su cuenta con solo páginas man / info y SIN otras herramientas que el código fuente de una biblioteca. Vea qué tan bien va eso … o incluso intente cambiar los frenos de su automóvil (solo tome fotos).
• Basándose en paralelos y reflexionar sobre por qué se toman decisiones en otros softwares
• Participe en algo con lo que no esté familiarizado : prototipo, únase a hackatones, etc. Trate de mejorar todo lo que hace, imagine cómo podría mejorarlo (y hágalo)

Bon chance.

PD. Mi único desacuerdo con las otras respuestas: no vayas a la academia si quieres aprender a programar mejor. He visto innumerables programas terribles como resultado de la “investigación”, por lo que existe la posibilidad de que solo esté expuesto a eso, a menos que arregle todo el código existente 😉

En primer lugar, el hecho de que uno copie y pegue algún código no significa que sea un desarrollador de software “falso”.

Sin embargo, diré una cosa muy importante, y no tiene nada que ver con reinventar la rueda ni aprovechar los conceptos de sonido. El verdadero problema subyacente aquí es, y he visto esto una y otra vez, que muy a menudo la persona que busca una respuesta nunca ha entendido realmente lo que está haciendo. No aprendí este concepto a través de la programación, sino a través de un profesor de Física que nos criticó (a sus alumnos) por hacer lo mismo con los problemas de la tarea. Básicamente dijo que si haces esto, nunca aprenderás realmente los conceptos y resolverás problemas ingeniosamente para obligarnos a ir más allá de encontrar problemas similares y adaptar la solución a la pregunta.

No estoy diciendo buscar una respuesta en términos de encontrar algo que haga que un método en particular haga “clic”, sino simplemente una aplicación ciega de algo que funciona en un caso dado, sin comprender cómo encaja el fragmento de código en el resto del código. imagen.

Inevitablemente, esto suele aparecer como un error cuando se arroja algo al código que no estaba destinado a manejar, y esto a menudo se debe a que ese fragmento de código simplemente se movió de un lugar a otro sin respetar el resto del código. En escenarios de casos solitarios, el código a menudo funcionará y puede continuar haciéndolo durante un tiempo o durante mucho tiempo, quién sabe.

La clave aquí es volver siempre a los fundamentos del lenguaje con el que está trabajando. Si ya es un solucionador de problemas, una gran parte de lo que falta a menudo se extrae del poder que un idioma dado ya ha incorporado.

Si se encuentra simplemente buscando una solución en todos los sitios en lugar de intentar crear uno usted mismo, puede terminar pasando más tiempo buscando de lo que realmente tomaría por su cuenta. Esfuércese por formar una solución haciendo referencia a la documentación en línea del idioma en lugar de buscar una.

En el caso de que encuentre una solución a través de la búsqueda, un aspecto realmente importante es comprender por qué esta solución funciona en su caso. ¡No te conformes con solo hacerlo funcionar, persigue el dominio!

Respuestas por todo el lugar …

Entonces, rompo la perilla de mi estufa. Lo miro, no reparable, necesito uno nuevo.

Opción 1: me siento en mi programa cad 3D, diseño la pieza por un par de horas, la envío a la impresora 3d y después de otras dos horas tengo un reemplazo. (Suponiendo que lo diseñé 100% correctamente en el primer disparo)

Opción 2: busco en línea, encuentro la pieza de reemplazo, la solicito y me la entregan. Ahora hago algo más con las 4 o 5 horas que no usé para diseñar y hacer la pieza.

Claramente, la opción 2 es una solución más eficiente. Pero…. Miremos más allá. En primer lugar, pude identificar el problema y determinar que no podía repararse. En segundo lugar, tengo el conocimiento para poder construirlo desde cero si es necesario. Tercero, pude determinar que construir desde cero no era la solución más efectiva.

Copiar / pegar no tiene nada de malo si comprende completamente lo que está haciendo. El problema es que si eso es todo lo que está haciendo, su código probablemente apestará cuando se trata del proyecto general. Copio / pego o reutilizo el código según sea necesario. Pero lo he pensado y determinado que es la solución adecuada en ese momento. Y sé lo que está haciendo el código.

¿Cómo te conviertes en un verdadero desarrollador de software? Abra su IDE favorito en su idioma preferido. Haga clic en “Nuevo proyecto” o cualquier variante que su IDE lo llame, y comience a escribir algo. El concepto no tiene que ser original; Podría ser algo común. Puede buscar en Google su referencia de software, incluso leer el código de ejemplo, pero no lo copie y pegue. Escribelo. Escribir te obliga a aprender no solo la sintaxis, sino también los detalles de cómo funciona. Cometerás errores, pero cada uno de ellos es un momento de enseñanza. Si algo no funciona, pruebe e investigue por qué está roto. Quédese hasta que su proyecto esté terminado.

Lo que encontrará es que algunos de esos 30 segmentos de código de línea que copió y pegó en el pasado podrían reducirse a unas pocas líneas. Otros que verás son buenos como son. Pero entenderás la diferencia.

Copiar y pegar código es copiar y pegar errores.

Ahora, en la industria del software, muchos problemas se resuelven de esa manera. Supongamos que tiene una aplicación web con miles de páginas web y le piden que haga un par más. No sería práctico comenzar desde cero, así que lo que debe hacer es copiar una de las páginas y modificarla. Así de simple; y no digo que no esté copiando ni pegando errores, solo digo que es una forma práctica y segura de resolver un requisito de software.

Ahora, si quieres avanzar en tu carrera, entonces necesitas aprender lo básico. Debes entender qué es OOP, UML, quién es la Banda de los Cuatro, quién es Donald Knuth, cuál es el principio KISS, el principio Hollywood, … quién es Dijkstra, qué es un bloqueo, qué es un punto muerto, qué es el problema de los filósofos, qué es una expresión regular, etc., etc. Luego debe saber sobre arquitectura de software, SOA, arquitectura de integración, cuando tiene un monolito completamente apropiado y no necesita transformarlo en (mencionemos el tendencia de facto) microservicios, etc., la nube, IA, seguridad, inyección de SQL, …… etc, etc, etc, etc, etc …… Computación cuántica, etc.

PD: Y sí, como muchos ya te explicaron, normalmente reutilizas en lugar de copiar y pegar. Identifica el código repetitivo, identifica patrones, hace interfaces y crea una biblioteca o investiga sobre uno existente.

Todas las respuestas aquí son buenas, solo agregaría una técnica que uso. En primer lugar, eres suficiente desarrollador de software para al menos encontrar la parte del código que tiene el problema que estás tratando de solucionar. Eso es más de la mitad de la batalla.

Antes de saltar a SO, pase un tiempo de calidad con su depurador. Paso a través del código. Entra en funciones y mira lo que hacen. En cada paso, preste especial atención a los valores de las variables como se muestra en la salida de depuración. Busque uno de los siguientes para cambiar a algo anómalo.

Agregue algunos registros alrededor del área sospechosa.

Es posible que no necesite SO en este punto, ¡puede ver el error sentado allí! O al menos puede ver que una API de sistema o marco devuelve algo inesperado. Como desarrollador de Windows, he visto esto muchas veces.

Digamos que su producto no siempre establece el Factor de deformación correctamente. Has revisado tu código y notas un retorno extraño de ClockTimeWarpLevelSet a veces.

AHORA vaya a SO y busque preguntas relacionadas con ClockTimeWarpLevelSet.

¡Ahora estás usando SO de la manera prevista por Joel!

Respondiendo: “Soy un desarrollador de copiar y pegar, ¿cómo me convierto en un verdadero desarrollador de software?”

Supongo que ya eres uno, pero no muy bueno. Puedes ser mucho mejor.

Mira el código que estás copiando y pegando:

1. Averigua cómo funciona; ¿Cómo resolvió el autor original el problema en cuestión?
2. Decidir si podría mejorarse; ¿Cómo lo haría mejor, más rápido, más legible, más fácil de entender?
3. Decida si podría haber resuelto el problema de una manera diferente, de una mejor manera. Piénsalo.

Y lea acerca de cómo otras personas resuelven problemas. Esta es realmente la forma en que la mayoría de los desarrolladores de software mejoran: observando el trabajo de otros, viendo cómo resolvieron los problemas, pensando en cómo la solución podría haber sido mejor y, a veces, haciéndolo mejor.

Aunque todavía no soy desarrollador de software, he realizado algunos proyectos de software y he visto a personas como tú en mi entorno. En realidad, al comienzo de mi carrera de codificación, también copio y pego mucho el código, pero luego me doy cuenta de que no estoy aclarando mis conceptos y solo estoy copiando y pegando a ciegas el código. Copiar y pegar puede ayudarnos mucho cuando sabemos perfectamente qué es el código y cómo funciona. Ahorrará mucho tiempo al copiar y pegar esa parte del código mencionado anteriormente. Ahora, si su hábito es copiar y pegar, ¿cómo podría detener esto …?

Intente desarrollar el algoritmo o la lógica del código por su cuenta al principio. Para esto, sus conceptos de codificación y conocimiento del tema deben ser buenos. Comprenda claramente estos temas. Intenta duro y codifícalo. No copie y pegue a ciegas. Y después de eso, si tiene que usar esa parte del código en cualquier otro lugar en cualquier momento, copie y pegue. Así es como funcionan los grandes desarrolladores. Tomará algún tiempo o podría frustrarse al escribir código, pero tarde o temprano será un buen desarrollador. Buena suerte

^ Eso podría ser una opción;). (fuente de imagen)

Pero seamos serios: ya estás en camino de convertirte en un buen desarrollador de software al reconocer que el desarrollo de copiar / pegar es malo.

Copiar / pegar generalmente resulta de no entender el código que está utilizando. Entonces podría comenzar a tratar de comprender de qué se trata el código que copia. Luego intente extenderlo o cambiar su funcionalidad ligeramente. ¡No tengas miedo de romperlo! Jugar ayuda a entender, por eso los niños juegan todo el día.

Para apoyar su comprensión de los bloques de código copiados, es posible que desee ver transmisiones de pantalla en el idioma y / o marco en el que codifica. Hay un montón de material de aprendizaje fantástico por un precio decente. Pagar por los screencasts te dará una mayor calidad y te permitirá aprender más rápido; pero también puedes encontrar millones de recursos gratuitos.

Copiar / pegar también a menudo significa que no comprende el contexto en el que está operando. Realmente no conoce ninguna “arquitectura” de software más amplia que no sean funciones o métodos. Este conocimiento del desarrollo de software en piezas más grandes no es tan fácil de aprender como un lenguaje o tecnología, pero se puede aprender. Tendrá que buscar en los campos de “ingeniería” de software , patrones de diseño o “arquitectura” de software.

¡Mirar el código (tanto en el pequeño como en el grande) de otros desarrolladores también es una excelente manera de aprender! Puede encontrar casi cualquier proyecto de código abierto en github.com. Compruébalo e intenta ver cómo estas personas organizan su código.

Los katas de código también son un gran dispositivo para aprender. Simplemente busque “code kata” en google y encontrará muchas fuentes. Los katas son pequeños ejercicios que te enseñan a codificarte.

Si puedes, ¡ aprende en equipo con uno o dos amigos! Es mucho más divertido y progresarás mucho más rápido.

Estos fueron solo algunos consejos. Espero que algo de esto te ayude. ¡No dudes en hacerme más preguntas!

“Siempre codifica como si el tipo que termina manteniendo tu código sea un psicópata violento que sabe dónde vives. “(Rick Osborne)

Sígueme en Twitter para obtener más consejos sobre programación, negocios y vida.

La mayor parte del tiempo dedicado a la programación no es escribir código, está analizando el problema que está tratando de resolver, probablemente incluso está escribiendo en un papel los pasos que debe seguir para resolver el problema y después de todo el trabajo de preparación, entonces usted continúe y comience con la implementación. Así es como funciona un buen desarrollador.

Si hace esto y aún copia / pega y sabe que está copiando / pegando, podría ser un buen desarrollador pero muy poco probable.

Muy poco probable porque al copiar / pegar no entiendes la lógica de lo que estás haciendo, lo que me dice que no has analizado el problema correctamente.

Copiar / pegar podría funcionar y, por supuesto, todos lo hemos hecho, pero si siempre copiamos / pegamos las soluciones de otras personas, ninguno de nosotros podría explicar qué hicimos para resolver el problema y por qué elegimos esta solución y no otra.

¿Entonces quieres convertirte en un verdadero desarrollador de software?

Comience por tomar más tiempo para analizar adecuadamente el problema que desea resolver, comience por tomar más tiempo para enumerar la posible solución, modulirizar las soluciones en minipasos, escribir pseudocódigo si lo desea, así que, en general, intente minimizar el trabajo mecánico como copiar / pegar o comenzar un proyecto sin siquiera analizar los requisitos, las tecnologías a utilizar, etc. y aumentar el pensamiento lógico.

Por supuesto, aprenda mucho más de lo que está leyendo en su área de especialización y manténgase al día con las últimas tendencias.

Otro método que podría ayudarlo con respecto al pensamiento lógico, es una técnica llamada depuración de pato de goma.

Una vez que haya terminado de escribir un fragmento de código, intente explicar lo que le hizo a un pato de goma … si durante la explicación ve que no puede explicar todo, es una simple idea de que aún no haya terminado realmente con el trabajo y necesita mejorar (tanto el código que ha escrito como usted mismo en la programación).

No se desanime y siga aprendiendo.

He estado trabajando en un entorno profesional desde julio de 2017. Esto es lo que he observado:

Mis superiores no esperan que escriba cada línea de código desde cero todo el tiempo. De hecho, me dicen que vaya y mire el código de una aplicación en particular y haga exactamente lo que está haciendo ese módulo en esa aplicación específica. A veces tengo que escribir mucho código desde cero si se trata de una nueva funcionalidad que estamos creando. De hecho, he tenido que diseñar módulos completos que realizan una tarea específica. Siempre me ha animado hacer que los módulos sean lo más portátiles posible para que el código pueda reciclarse en otras aplicaciones si es necesario.

Voy y miro esa aplicación e intento entender qué está haciendo ese código. Luego replico la misma funcionalidad pero también vigilo los escenarios que podrían necesitar modificaciones en mi aplicación. Por lo tanto, hago bastante pegado de copias (hasta 70-80% a veces). El problema no es copiar y pegar. El problema es ¿entiendes lo que ese código intenta lograr? No copie y pegue ciegamente.

Los desarrolladores de software reales no reinventan la rueda cada vez que codifican.

PD
Si copia desde cualquier lugar, asegúrese de poner la fuente del código en los comentarios. Esto lo ayuda en el futuro cuando intente determinar de dónde obtuvo este código, así como también le ayuda a cometer plagio.

Al deshacerse del síndrome del impostor?

Siempre que trabaje con muchas bibliotecas con interfaces menos que simples, copiar y pegar es lo que todos hacen. Solo cuando necesita escribir algo que no puede encontrar listo en una de sus dependencias, escribe el código para resolver el problema usted mismo.

Si desea convertirse en el que escribe todas las bibliotecas que usa, en lugar de solo usarlas, vaya a aprender algoritmos y estructuras de datos a fondo, luego encuentre un trabajo en una empresa compiladora o participe en un proyecto de código abierto que se ocupe de componentes de infraestructura donde dicho conocimiento es importante (Kafka, Gnu Compiler Collection, Spark, etc.) u obtener un trabajo de investigación. (Advertencia: un puesto académico, donde la investigación se realiza con mayor frecuencia, no pagará tan bien como lo hace la industria, al menos no por varios años después de que comience. Y, para tener éxito, necesita obtener un doctorado – Es difícil progresar en la academia sin uno.)

Simplemente no estoy de acuerdo con la mayoría de las respuestas. Copiar y pegar no está bien y casi siempre lleva una solución por un camino largo y oscuro que el desarrollador nunca pretendió.

He hecho un poco de copiar y pegar es mi pasado. Las primeras veces descubrí muy rápidamente que tendría que aprender la lógica, ya que era mi solución, tenía que tenerla. No hay nada peor que pedirle que arregle o refine una solución de la que no tiene idea.

Por un tiempo, encontré que Stack Overflow es un recurso bastante bueno para encontrar ideas para soluciones. Lo más probable es que alguien ya haya hecho lo que intentas hacer, a veces no lo ha hecho. Pero a medida que se desarrolla, aprende y crece, SO se convierte en un peldaño.

He trabajado con desarrolladores que eran copy & peters, en empresas pequeñas y multinacionales, y su código sobresale como un pulgar dolorido. Es demasiado sofisticado o una locura de murciélago. Como líder tecnológico o líder de desarrollo, esas cosas realmente te preocupan.

Esta pregunta me comunica una falta de comprensión sobre qué es la programación. No es simplemente escribir en un teclado. Si lo fuera, los monos habrían sido entrenados para hacerlo hace 50 años.

La programación es análisis de dominio, resolución de problemas, comunicación, aprendizaje y, por último, programación. El acto de escribir en su teclado es la culminación de todo lo que está delante. Claro, puede abrir un editor y comenzar a golpear las teclas, pero intente eso en un lugar de trabajo.

Una vez me refirieron como un vaquero, tuve ese enfoque por algún tiempo y tenía una reputación como el lugar para cuando necesitas que se haga una cosa rápida que no se rompa. Con experiencia, aprende la ruta o menos dolor, pero no lo haga como un principiante, simplemente se verá como alguien que tiene una inclinación por los atajos y la brevedad.

Todavía tengo esa reputación, pero cuando tienes aplicaciones que generan cientos de miles de ganancias que creaste sin ayuda, o la longevidad del uso continuo de la producción sin cambios, puedes usarlas como una insignia de honor. Eso no me convierte en un mal programador, sino todo lo contrario. Soy muy diligente y minucioso con mi dominio, pero sigo cometiendo errores como todos los demás.

Un programador real hace preguntas, entiende el dominio y pasa tiempo analizando el problema para formar una solución. Un desarrollador de copiar y pegar no.

Hay muchos tutoriales en línea que lo guían a través de algunas cosas básicas. Podrías resolver algunos de esos pasos paso a paso. También busque reuniones en su área donde las personas se reúnan para escribir código y participar en algunas de ellas, si el tiempo lo permite.

Algo que puede hacer por su cuenta es elegir un problema simple, como la serie Fibonacci o el ejercicio FizzBuzz o uno de los katas de código que puede encontrar en línea, y resolverlo utilizando un desarrollo basado en pruebas. Al comenzar con una especificación ejecutable de un solo comportamiento, y luego construir el código suficiente para que esa especificación pase, puede comenzar a tener una idea de lo que hacen las declaraciones individuales y los fragmentos cortos de declaraciones en un lenguaje de programación. Gradualmente comenzará a poder recurrir a ese conocimiento en un contexto de trabajo. Este enfoque puede ayudarlo a elegir y comprender fragmentos de código que cree que serían útiles para pegar en sus soluciones, así como brindarle una mejor comprensión de cómo personalizar esos fragmentos. Es un camino para equilibrar el enfoque de copiar y pegar con la capacidad de escribir código.