¿Está constantemente buscando ejemplos de código una señal de un mal desarrollador? [cerrado]


161

Soy un estudiante de CS con varios años de experiencia en C y C ++, y durante los últimos años he estado trabajando constantemente con Java / Objective C haciendo desarrollo de aplicaciones y ahora me he cambiado al desarrollo web y estoy enfocado principalmente en Ruby rails y me di cuenta de que (al igual que con el desarrollo de aplicaciones, realmente) hago demasiadas referencias a otros códigos. Constantemente utilizo Google para muchas cosas que imagino que debería poder hacer desde cero y realmente ha roto un poco mi confianza.

Los fundamentos básicos no son un problema, odio usar esto como un ejemplo, pero puedo ejecutar javabat en java / python en un sprint, obviamente no es un logro y lo que quiero decir es que tengo una base sólida para los fundamentos ¿Yo creo que?

Sé lo que necesito usar normalmente, pero la sintaxis de referencia constantemente. Me encantaría recibir algunos consejos y sugerencias sobre esto, ya que me ha estado frenando de manera bastante sólida en términos de búsqueda de trabajo en este campo a pesar de que estoy terminando mi carrera. Mi razón principal para preguntar no es realmente sobre el empleo, sino más bien que no quiero ser el único chico en un hackathon que no está forjando código sin parar y sentado allí con 20 pestañas de Google / github abiertas, y me he abstenido de asistir a cualquier debido a una ligera falta de confianza ...

¿Es una persona un mal desarrollador al buscar constantemente ejemplos de código para tareas moderadas a complejas?


14
Depende de lo que estoy trabajando, cosas en las que trabajo mucho, casi no se requiere ninguna búsqueda. Algo más desconocido, busco ejemplos todo el tiempo.
Jaydee

11
Depende de si realmente puedes escribir un código tú mismo.

18
Mi esposa mira esas competiciones de cocina y campeonatos de magdalenas en la televisión donde tienen una cantidad de tiempo absurdamente pequeña para cocinar una deliciosa comida con ingredientes aleatorios. La mayoría de las veces la comida es horrible o poco hecha y ciertamente no es la mejor calidad. Son buenos para mostrar, pero prefiero que mi chef se tome su tiempo y lo haga bien. Lo mismo se puede decir hackatones. Zuckerberg y sus compinches eran tipos hackathon que rápidamente escribieron un sitio web horrible que tuvo que ser reescrito una vez que comenzaron a obtener más de unos pocos usuarios. La mayoría de las personas preferiría que lo hicieras bien la primera vez.
maple_shaft

88
Mi jefe siempre dice "La mejor medida de la habilidad de un programador es su habilidad para hacer una buena búsqueda en Google". Todos los programadores que conozco buscan ejemplos en Internet, pero solo los malos pegan a ciegas. Si alguien ya ha hecho lo que quieres hacer, ¿por qué reinventar la rueda?
SSumner

99
La investigación es importante. Simplemente no participe en lo que yo llamo BSDD (Blog-Spam Driven Development)
Thomas Dignan

Respuestas:


238

Copiar y pegar a ciegas: malo.

Busque documentación, lea ejemplos de código para obtener una mejor comprensión: bien.

Prefiero trabajar con alguien que busca cosas todo el tiempo y se asegura de que todo funcione según lo previsto, que alguien demasiado confiado que cree que lo sabe todo pero no lo hace. Pero lo peor es alguien que no se molesta en entender cómo funcionan las cosas, y simplemente copia críticamente el código de la web (y luego, cuando los informes de errores comienzan a llover, no puede arreglar nada correctamente).


21
@NewlyInsecure Eso está bien ... algunos desarrolladores de software como yo creen que las personas que van a los hackatones son ridículas. La mayoría de ellos son grandes programadores pero terribles desarrolladores de software que bebieron demasiados red bulls.
maple_shaft

23
Un desarrollador tiene el cerebro para saber que alguien ha hecho algo de antemano y buscar ejemplos y adaptarlos. Un desarrollador no pierde el tiempo golpeando el cráneo contra la pared.
David

19
@NewlyInsecure Comparación mata. En serio, cuanto más te comparas con los demás, más desmoralizado, desmotivado y temeroso te vuelves. Forme sus propias convicciones basadas en la verdad, no en lo que hacen los demás. Si las personas en hackathons pueden descifrar más código más rápido, ¿a quién le importa? Incluso si eso fuera un indicador de habilidad, siempre habrá personas más inteligentes que tú, sin importar cuán hábil seas.
Phil

55
Personalmente, si encuentro un ejemplo de código que ya hace más o menos lo que quiero hacer, lo estudio para comprenderlo. Si es un código más grande, tomaré notas y tal vez luego pseudocódigo para una solución para mi caso específico y luego trataré de implementar mi pseudocódigo con código real. Creo que la clave aquí y lo que mencionaron tdhammers y David es que no estoy copiando ciegamente el código. Lo estoy mirando para entender lo que está haciendo y luego incorporar sus ideas en mi solución específica.
Shufler

3
@NewlyInsecure: También tienes dos cosas en tu contra: la primera es que las API se han vuelto mucho más grandes y complejas de lo que solían ser, lo que las hace mucho más difíciles de memorizar. La segunda es la edad, que no tienes ahora pero que tendrás antes de que te des cuenta. A medida que envejezca, descubrirá que no puede recordarlo todo y comenzará a conservar sus células cerebrales para las cosas que realmente necesita saber. Cultivar las habilidades necesarias para investigar y encontrar los detalles que ha olvidado necesita es importante.
Blrfl

110

Si codifica sus soluciones de manera sostenible y realmente ENTIENDE lo que copia / pega / modifica, entonces no hay problema.

Me muero por dentro cada vez que le hago preguntas a un desarrollador sénior sobre por qué hizo qué y la respuesta es "No sé, copié el código pegado y funcionó en ese momento".


8
A veces me deprimo pensando que podría no ser tan buen desarrollador. Luego leo una cita como esa y me siento mucho mejor conmigo mismo.
The Jug

18
@TheJug, recuerda, eres mejor desarrollador y peor desarrollador de lo que imaginas ser.
Joe

71

Al igual que con la habilidad de programar con / sin documentación de API , buscar ejemplos de código no es una señal de un mal programador, sino de uno que carece de fluidez ...

... Aquí estoy hablando de fluidez. Sobre ser no solo capaz de algo sino fluido.

¿Sabes lo que es ser fluido? Es cuando para alguien que te mira parece que codificas mientras escribes ...

  • ... Como si el código correcto simplemente fluyera de sus dedos a la pantalla. Como si no revisara los documentos API, tutoriales y manuales. En realidad, se hace comprobar a todos, pero que es invisible porque es todo en su cabeza. Tienes todo el conocimiento que necesitas allí mismo en tu cerebro: cargado, cargado y listo para usar.

... Eso es conocimiento fluido. Es cuando te toma un minuto hacer lo que le toma a un novato una hora. Vale la pena el esfuerzo, de verdad. Huele a victoria.

... y la práctica es para mí la única forma confiable de adquirir fluidez.


14
EXCELENTE punto sobre fluidez. Soy fluido en COBOL. Me tomé un descanso de TI durante 20 años y vuelvo a aprender Java. Instintivamente sé cómo hacer algo en COBOL ... pero parte del proceso de APRENDIZAJE de la fluidez de Java es buscar ejemplos de código, analizar cómo funcionan y adaptarlos a mis necesidades particulares. Cuando aprende un nuevo idioma VERBAL, al principio se refiere a su diccionario italiano-inglés con frecuencia, se equivoca la gramática y los tiempos verbales, y eventualmente, un día, habla como un nativo. El tiempo y la práctica son clave. No te preocupes por eso ... :)
dwwilson66

10
@ dwwilson66 La cuestión es que, a nivel diario, necesito recordar cuatro "idiomas": el lenguaje de programación del lado del servidor, el lenguaje de secuencias de comandos del lado del cliente, la sintaxis de marcado del lado del cliente y la sintaxis de estilo del lado del cliente. Simplemente no puedo mantener todo eso en mi cabeza: es como tratar de mantener conversaciones en italiano, chino, inglés y klingon al mismo tiempo.
Tacroy

@ Tacroy - ¡EXACTAMENTE! Sin la fluidez, NECESITAS recursos para ayudar. No te hace "menos" un hablante de klingon si necesitas buscar frases completas en lugar de solo una palabra de vez en cuando, pero no tan fluido como los demás.
dwwilson66

44
La última oración merece ser resaltada, no oculta en el subíndice. No hay otra forma de ser fluido que por inmersión.
jmlane

@ dwwilson66 tenga en cuenta que hay cosas que deberían hacerse muy diferentes en Java que en COBOL. Los objetos no son lo mismo que copiar libros.

54

Existe una teoría del aprendizaje llamada ciclo de Kolb (según la persona que lo describió). Las entradas en este ciclo son:

Concrete experience -> Reflective observation
    ^                        |
    |                        v
Active experimentation <- Abstract conceptualisation

A diferentes personas les gusta comenzar en diferentes lugares del ciclo. Así que es muy posible que el aprendizaje por buscar muestras (la fase de observación reflexiva), que entonces trabajaba a partir de esas muestras a la imagen grande a través de la abstracción.

Otras personas aprenderán de diferentes maneras: a algunas personas les gusta comenzar intentando (es decir, con experimentación) y luego reflexionar sobre lo que salió bien o mal. El punto es que estas son solo diferentes maneras de atacar el problema de aprender cosas: ninguna de ellas es incorrecta.


2
+1 Interesante. Intuitivamente, esperaría que uno avance en al menos algunas de esas etapas para aprender, ¿verdad? Es decir, solo observar probablemente no sea suficiente para que ocurra un aprendizaje real: debe pensar en lo que ha visto y probarlo.
Caleb

Realmente me gusta esto. Comienzo en Observación reflexiva en la mayoría de los idiomas, pero en PowerShell generalmente comienzo en Experimentación activa
Caleb Jares

@caleb correcto. Es un ciclo en el que te mueves de etapa en etapa, y quizás no internalices completamente algo hasta que hayas pasado por las cuatro. Es donde comienzas lo que más cambia.

39

Divulgación completa: soy una persona de edad que recibió capacitación en un pre-Internet diferente disponible en la era del trabajo. He visto cómo las habilidades de los desarrolladores más jóvenes se deterioran constantemente debido principalmente a que no retienen información ni comprenden la solución que obtuvieron de Internet. He observado que el nivel de competencia que tenía una persona después de 1-2 años de experiencia, hace 20 años, ahora es el nivel de competencia que alguien tiene después de 5-7 años de experiencia. (Sí, eso es una observación personal, pero he realizado muchas contrataciones, no tengo datos estadísticos sobre el asunto y sí, a veces soy viejo y de mal humor, tome esta declaración con un grano de sal. Y quédese fuera de mi patio. )

Buscar todo es ineficiente en términos de tiempo. También es un síntoma de alguien que no tiene mucha profundidad de conocimiento. Las personas con conocimientos profundos pueden escribir código más rápido que las personas que no saben cómo resolver un problema sin buscar las cosas. Por lo tanto, vale la pena aprender a manejar más cosas sin tener que buscar cosas continuamente.

Ahora no estoy diciendo que nunca debas buscar cosas, estoy diciendo que debes aprender a retener el conocimiento y solo necesitas buscar cosas que usas raramente o cuando te encuentras con un problema o lenguaje o paradigma realmente nuevo. Y no digo que no deba leer para mantenerse al día con nuevas soluciones, herramientas e idiomas.

Mi preocupación real con los desarrolladores que buscan cosas con demasiada frecuencia es que muchos de ellos (no necesariamente usted) nunca desarrollan las habilidades analíticas para comprender los problemas que tienen y las soluciones que se necesitan. Lea cuántas preguntas hay donde la persona pone el mensaje de error que él o ella claramente no entiende, pero que debería ser bastante claro para cualquiera que opere a nivel profesional. O aquellos en los que la persona dice: "no está funcionando, ¿por qué?" sin referencia al mensaje de error o cómo no funciona y el código es sintácticamente correcto. O los que reciben un código que debería funcionar,

Entonces, si lo que está buscando es material que forma parte de la funcionalidad principal de los idiomas (por cierto, esto debería incluir SQL si está accediendo a bases de datos) que ha utilizado durante más de seis meses, sospecho que también está buscando mucho. Si lo que está buscando son características avanzadas, especialmente aquellas que podría usar raramente, entonces está bien.

Pero, ¿cómo aprender a retener más información? Primero entienda por qué se rompió el código. Incluso si alguien le da una solución de trabajo, si no ve por qué funcionó y la suya no funcionó, pregunte. Si no comprende el mensaje de error, pregunte qué significa y luego intente resolverlo usted mismo.

Y nunca corte y pegue una solución que no entiende. De hecho, no corte ni pegue en absoluto. Si desea retener información, debe escribirla. En realidad, escribir el código físicamente te ayuda a aprenderlo. Esa es una técnica de aprendizaje bien conocida.

Practique generalizando su comprensión del código. He visto a personas hacer preguntas similares una y otra vez con el tiempo porque no entienden que la solución que obtuvieron hace un mes al problema ABC es la misma solución al nuevo problema DEF.

Entonces, cuando haya investigado algo, tómese un tiempo para pensar qué tipos de problemas sería bueno resolver y escriba notas sobre eso. Luego, cuando tenga un problema que resolver, primero revise sus propias notas para ver si ya ha notado una posible técnica. Si evalúa múltiples formas de resolver un problema, tome notas sobre el tipo de problema, las posibles soluciones que miró y los pros y los contras de cada uno. Una vez más, la toma de notas está ayudando a solidificar el conocimiento en su cerebro, ya tiene su propio proceso de pensamiento en términos de los pros y los contras resueltos y no tiene que volver a hacerlo (o al menos no con tanta profundidad, puede todavía busco más técnicas posibles) para el siguiente problema similar.

Y cuando decida qué aprender a continuación, profundice en una de sus tecnologías principales antes de comenzar a aprender los primeros 30 días de otra tecnología (esto supone que tiene suficiente conocimiento para realizar su trabajo, si es necesario). use 6 tecnologías: obtenga los conceptos básicos de los seis primero antes de profundizar). Luego, vaya y venga, aprendiendo cosas nuevas, a un nivel básico, aprendiendo algo con más profundidad, y luego aprendiendo más nuevas tecnologías a un nivel básico. Si hace esto con el tiempo, descubrirá que su nivel básico de lo que desea de una nueva tecnología es mucho más profundo porque comprende preguntas más avanzadas sobre el tema.

Otra forma de aprender a retener el conocimiento es enseñárselo a otra persona. Responda preguntas en lugares como este, presente temas de capacitación a su equipo, haga presentaciones en sus grupos de usuarios locales, escriba entradas de blog y ayude a mantener un wiki de información en su empresa para ayudar a otros desarrolladores.


11
Hay algunos puntos muy buenos aquí, pero creo que sufre debido a la "parte de los viejos tiempos". La gente ha estado denunciando la degeneración de la generación joven durante miles de años. Todavía tengo que ver pruebas sólidas para apoyarlo.

44
+1 @JonofAllTrades ... hombre, desearía poder retroceder veinte años y ganar un millón de dólares porque sabía ... FoxPro. solamente. Pero no, hoy en día debes ser competente en tecnologías de galaxias pequeñas solo para competir por un trabajo regular. ¿Se puede configurar y configurar Apache, IIS, ambos? ¿Te sientes cómodo en un dialecto SQL o dos, capaz de escribir SPROCs y al menos de administrar poco? ¿Eres competente en un par de lenguajes del lado del servidor y al menos en un lenguaje de script funcional para la manipulación de datos? ..y si programa para la web, ¿funcionará su material en los principales navegadores Y dispositivos móviles?
elrobis

Este argumento solo tiene sentido para la tecnología que ya existe hace 20 años. Y sí, usted es muy afortunado de conseguir un trabajo en su mayoría solo con conocimiento de SQL (su "patio"), que es insuficiente para los estándares actuales.
prusswan

@prusswan, soy especialista y hay muchos más trabajos de los que pueden ocupar en mi área. Pero cómo eso es relevante para lo que digo en la respuesta está más allá de mí. Las cosas de las que hablo son posibles para todas las tecnologías. El problema es que las personas no aprenden o entienden lo que están haciendo porque no retienen la información, no porque algunos de nosotros usemos tecnologías más antiguas. Es tan fácil retener el conocimiento para las nuevas tecnologías como para las más antiguas. Y el conocimiento retenido lo ayudará a aprender el próximo y se desarrollará más rápido.
HLGEM

24

Buscar ejemplos de código no es una señal de mal desarrollador. Raramente se necesitan tan pocas cosas para recordar todas las interfaces que necesitan con precisión, por lo que es natural buscar cosas y los ejemplos de código suelen ser la referencia más fácil de usar.

Lo que no debe hacer es copiar y pegar ejemplos porque funcionan allí, por lo que también deben funcionar aquí, sin comprender cómo funcionan. Eso generalmente lleva a muchos bits inútiles que se copiaron de forma incidental con un resultado difícil de mantener porque si no sabías cómo funciona cuando lo escribiste, tampoco lo sabrás seis meses después y no podrás arreglalo.

Pero siempre que comprenda el código que está copiando de un ejemplo, es una forma válida de hacer el trabajo más rápido, y eso generalmente es algo bueno.


2
Reviso todo lo que copio y entiendo todo lo que leo, es solo parte de la sintaxis y la funcionalidad es tan larga que no creo que pudiera haberlo sacado todo desde cero. Incluso cosas que deberían ser simples y segundas, como json o una consulta de base de datos, etc. (probablemente malos ejemplos). Gracias por su respuesta, realmente lo aprecio.
Recientemente inseguro

2
Y también debe pensarlo dos veces antes de copiar y pegar ejemplos de código en su propio proyecto. Puede tener más sentido separarlos en una clase y reutilizarlos.
stralsi

@SilviuStraliciuc: Creo que se trata más de ejemplos de 1 o 2 líneas. Lo cual no tiene sentido envolver en funciones. Pero generalmente vuelvo a escribirlos en lugar de usar ctrl-c + ctrl-v, así que aplico el formato correcto y reemplazo los identificadores y demás sobre la marcha.
Jan Hudec

1
A veces, los ejemplos de 1 o 2 líneas tienen sentido para envolver una función, especialmente si existe la posibilidad de que cambie de opinión más adelante sobre exactamente lo que quería que hicieran las líneas 1 o 2 (y ahora tiene que encontrar el 200 lugares dispersos en todo el código donde usaste ese patrón de 1 o 2 líneas Con una función con el nombre apropiado, incluso si tiene algo mal que todavía tiene que repararse en 200 lugares, al menos es más fácil identificar esos lugares.
David K

14

Estas respuestas son bastante buenas. Pero sufre un problema mucho más profundo que copiar / pegar o falta de "habilidad".

La comparación es letal. Cuanto más te compares con otras personas y dejes que su talento afecte tu forma de verte, más te marchitarás y morirás por dentro. No vas a hackatones por temor a que la gente vea lo poco talentoso que eres. Y la única razón por la que crees que no tienes talento es porque te comparas con los piratas informáticos que pueden eliminar más código desde cero, más rápido.

Incluso si las "Líneas de código por minuto" fueran una buena métrica para medir la habilidad, debe aceptar el hecho de que siempre habrá mejores desarrolladores que usted . Y está bien mostrarles a los demás que te falta habilidad.

No necesita ser tan bueno o mejor que nadie. Debe estar contento con el hecho de que siempre le faltará de alguna manera y que está aprendiendo constantemente. Si no puede ser feliz con ser un desarrollador inferior, NUNCA lo será.

Una cosa más: su miedo al rechazo de las personas que cree que son "superiores" es exactamente lo que le impide codearse con mejores desarrolladores y aprender de ellos. Entonces su miedo le impide crecer, lo que mantiene su miedo. Lo que te impide crecer. ¿Ves el ciclo? Tienes que romper el ciclo en alguna parte.


8
Buena respuesta, pero no debe leerse en el sentido de que está bien aceptar la mediocridad. Mantenga sus ojos en su propio trabajo y no se preocupe de que otras personas sean mejores que usted, pero trabaje para mejorar.
Caleb

12

Creo que mucho depende de cómo funcione tu mente. Mi memoria apesta, por lo que preferiría tomar el código que sea lo más parecido a lo que quiero y volver a trabajarlo para que haga el nuevo trabajo. Sirve como un ejemplo y un recordatorio de todas las cosas que tengo que hacer. Por ejemplo, he usado SQL simple durante 20 años, pero nunca puedo recordar el diseño de una instrucción SELECT o UPDATE. (Creo que uno necesita paréntesis, pero no puedo recordar qué.) Por otro lado, algunas pocas cosas que recuerdo; Puedo lanzar una implementación de Java Iterator con los ojos cerrados.

La mayor parte del código que copio es mío, pero ciertamente copio el de otros cuando estoy aprendiendo algo nuevo.

No sé sobre hackatones. Pueden recurrir a un subconjunto de programadores con recuerdos fotográficos. Lo probaría y veré. Si parece que un idiota te molesta, no deberías estar programando.

Le insto a que comprenda, a fondo, todo el código que copia y modifica, pero, hasta que lea algunas de las otras respuestas, nunca se me ocurrió que alguien podría copiar sin comprender. (Parece que estoy aprendiendo nuevos vicios todo el tiempo en este sitio ...)


Psst, ninguno de los dos necesita paréntesis, a menos que esté haciendo subconsultas en un SELECCIONAR, o una lógica booleana compleja en el DÓNDE. ;)
Izkata

2
@Izkata: ¿No? Déjame mirar un código viejo. Oh, es una declaración INSERT que necesita paréntesis.
RalphChapin

8

... llegué a darme cuenta de que ... me refiero demasiado a otro código. Constantemente busco la funcionalidad de Google para muchas cosas que imagino que debería poder hacer desde cero y realmente ha roto un poco mi confianza.

Luego se detiene. Dirígete en la otra dirección por un rato. Implemente todo usted mismo, incluso si sabe que puede encontrar exactamente lo que necesita en mucho menos tiempo.

Lo que sucedió es que su músculo para resolver problemas (nombre en latín glúteo mojo ) se atrofió por falta de uso, y ahora evita usarlo porque sabe lo débil que es. Debes comenzar a desarrollar y tonificar ese músculo tal como trabajarías en tus bíceps en el gimnasio. Comience con altas repeticiones y baja resistencia, muchos problemas fáciles. A medida que desarrolles algo de confianza, pasa a problemas más largos y difíciles.

Gradualmente sentirá que su mojo regresa y su necesidad de confiar en Google disminuirá. Sin embargo, sigue ejercitando ese músculo y asegúrate de no volver a caer en tus viejas costumbres. Desafíate a ti mismo para resolver un problema primero y solo luego busca otras soluciones. A veces encontrará que otros han encontrado una mejor manera de hacer lo mismo, otras veces decidirá que su propia solución es mejor.

¿Es una persona un mal desarrollador al buscar constantemente ejemplos de código para tareas moderadas a complejas?

Una persona que no puede hacer nada sin encontrar ejemplos es un mal desarrollador. La cuestión es: no sabrá si puede o no hasta que lo intente.


7

Eres joven y has trabajado con muchos lenguajes de programación. Supongo que probablemente aprenderás los nuevos idiomas más rápido que los antiguos. Aún no ha dedicado suficiente tiempo a un solo idioma en una aplicación lo suficientemente grande como para desarrollar fluidez.

¿Está buscando soluciones amplias todo el tiempo, como: todo el proceso de conectar una cuadrícula web a una tabla de base de datos o una parte más pequeña, como formatear la cadena de conexiones (tengo que buscar eso casi todas las veces desde que escribo alrededor de cuatro al año. )?

Siempre buscará referencias a la sintaxis de diferentes líneas de código o funciones. Mientras más programas, más desafíos y diferentes entornos y cambios de idioma encontrarás. Si necesita un tutorial completo cada vez que hace algo, entonces tiene un problema.


Estoy de acuerdo: siempre hay cosas que, aunque es una actividad lo suficientemente común (leer desde un archivo, conectarse a una base de datos, hacer una solicitud HTTP, etc.), la sintaxis y el enfoque difieren tanto de un idioma a otro que generalmente tengo que verificar. Así es como se juntan estos componentes básicos para crear algo nuevo y útil que es lo más inteligente
Kris C

5

Tenía un profesor que solía decir que odiaba hacer exámenes basados ​​en tratar de retener una gran cantidad de información que acumuló la noche anterior porque de todos modos olvida mucho después. Es mejor conocer sus recursos y que puede usarlos adecuadamente para encontrar la información que no conoce. Me gusta aplicar un principio similar a todo lo que hago, incluido el trabajo.

Creo que las herramientas más importantes que tiene son sus recursos, siempre que los use correctamente. Entonces, cuando escribo código, llego lo más lejos que puedo con mi conocimiento existente y luego investigo preguntando a otros programadores o buscando en Internet, para comprender mejor la solución adecuada. El conocimiento se desarrollará con el tiempo y después de un tiempo, naturalmente, conocerá y comprenderá mejor las habilidades. Constantemente busco cosas si realmente necesito la información o no, y honestamente puedo decir que aprendo algo nuevo todos los días.


66
"Nunca me comprometo a recordar nada que pueda buscarse fácilmente en un libro". - Albert Einstein, 1922.
gbjbaanb

3
@gbjbaanb Albert Einstein utilizó el control de versiones en 1922? Wow, fue realmente asombroso.
svick

4

Si comprende el problema que está tratando de resolver y comprende cómo desea resolverlo, buscar la sintaxis correcta no es un gran problema en mi opinión.

Me gradué hace unos dos años y fui arrojado a los lobos cuando obtuve mi trabajo. Tuve que aprender, mantener y actualizar una gran aplicación escrita en un idioma que nunca antes había tocado. Obtendría un informe de error, revisaría el código y descubriría cómo quería solucionarlo, y luego tendría que buscar en google ejemplos de cómo hacer las cosas que quería en ese idioma.

Si está haciendo las cosas y entendiendo lo suficiente como para no producir una rotación innecesaria, entonces probablemente esté bien.


3

Copiar y pegar sin crítica, como se dice muchas veces en estas respuestas, es malo. Pero también lo está escribiendo todo desde cero. Si no es un componente crítico que es esencial para su negocio, busque una biblioteca o fragmento de código para hacerlo primero. La excepción para encontrar un fragmento sería que el problema es muy simple, tiene una idea muy clara de cómo hacerlo y si no está utilizando una biblioteca: es poco probable que necesite hacer algo más.

Sé personalmente que si escribo algo que es común, es probable que tenga algunos errores sutiles y tal vez uno o dos no tan sutiles sin muchas pruebas. Así que busco una solución similar, modifico y pruebo eso para ahorrar algo de tiempo en las pruebas y el desarrollo en general. Porque al final soy responsable de entregar un producto que funcione, sea extensible, esté dentro o por debajo del presupuesto y cumpla con los plazos. Reutilizar el código y las bibliotecas es un buen paso hacia ese objetivo.


3

Creo que leer ejemplos de código, y solo leer el código fuente de lo que otras personas han desarrollado en general, es la mejor manera de mejorar sus habilidades. Realmente creo que abre puertas en tu cerebro que de otro modo no se habrían abierto.

Si piensa en una solución A, y alguien más piensa en una solución B, cuando cada uno de ustedes comparte sus soluciones, puede darse cuenta de la solución C, que puede ser incluso mejor que A o B.


2
Como desarrollador predominantemente solo, no tengo compañeros para verificar mi código, resolver problemas conmigo e inspirarme. Los ejemplos en la red son esenciales para mí, tanto para resolver problemas particulares como para aprender nuevas habilidades / mejores prácticas.
cjmUK

3

Creo que hay muchos niveles de dominio del desarrollo de software. Solo así, porque también hay muchos niveles de dominio de la documentación de desarrollo de software . Francamente, en estos días, los sistemas son órdenes de magnitud más complejos que cuando comencé a programar computadoras a mediados de la década de 1980.

Luego, tenía que saber qué quería que hiciera la computadora, y había escrito documentación de 6 pulgadas de grosor que le decía cómo la computadora hacía ciertas cosas más básicas. Poner lo que quería en una forma que la computadora pudiera tomar era una cuestión de conocer el contenido de los índices de esos libros y un lenguaje de programación (o dos. Realmente, después de aprender cuatro o cinco idiomas, los otros son solo dialectos).

Hoy, esa tarea requiere conocer un lenguaje, conocer un sistema, conocer un paradigma, un modelo de programación y al menos un conjunto de API, todos los cuales son objetivos móviles.

Entonces, una persona con cierto nivel de conocimiento básico que pregunta no es un buen programador. Es el mejor tipo de programador, dados los entornos actuales y las empresas desinteresadas como Microsoft en la aplicación de cualquier tipo de rigor a su propia documentación fundamental. La mayor parte de su material es material de referencia autorreferencial y un código de muestra muy malo . (Dos casos en el punto que he encontrado son "Windows Installer" y las API para hacer archivos de película WMV).

Debido a que Microsoft, Google y, en menor medida, Apple, todos confían en "la comunidad" para compensar esa deficiencia muy real, preguntar no solo es importante, es vital. Y ser una persona a la que se le puede preguntar y que puede dar respuestas y comentarios sólidos en el entorno actual es igual de vital. Es por eso que sitios como los sitios stackexchange.com son tan útiles como lo son.

Por lo tanto, haga preguntas (¡pregunte inteligentemente!) Para obtener muestras y respete a las personas que brindan las respuestas, y hacerlo no será visto como un signo de un "mal desarrollador".

Y una cosa más: suministrar malas muestras realmente es el signo de un mal desarrollador. Hace que los desarrolladores malos sean más fáciles de detectar, pero también agiliza las búsquedas de Google. Si carece de confianza en ejemplos de código específicos, simples y directos, no los entregue.

Y, por favor, no te burles de los que preguntan.


3

Me parece que el problema para usted es comprender menos a qué se refiere y más con problemas de facilidad y memoria. Si está minando su confianza, entonces sí, es un problema, ¡pero ciertamente puede abordarse!

Para mí, este tipo de desafíos se presentan en muchos aspectos diferentes de mi vida. Por ejemplo, para ser bueno interpretando una pieza musical, necesito desarrollar mi independencia de la partitura que me dan. ¿Cómo puede realmente sentir la música si su nariz todavía está enterrada en su folleto? A veces, si tengo tiempo, memorizaré toda la pieza musical, incluso si no es necesario para mi actuación. ¿Por qué? Sin la partitura, es mucho más fácil para mí concentrarme en los aspectos más desafiantes y generales de la música que necesito hacer bien, y es mucho más fácil para mí entrar en esa increíble zona de música pura. Así que creo que a menudo vale la pena el problema extra.

Mi experiencia con la programación ha sido similar. Creo que las claves son:

  1. practique el lenguaje: escríbalo, ejecútelo, hable si es útil; hazlo repetidamente.
  2. construya sus instalaciones: use la misma característica o patrón en diferentes situaciones; poner características juntas; hacer programas
  3. dedique suficiente tiempo entre repeticiones para asegurarse de que las cosas realmente lleguen a su memoria a largo plazo.

¡Estos principios parecen aplicarse al aprender cualquier idioma, en realidad! Vea Cómo recordar nuevas palabras, por ejemplo. El método Pimsleur también funciona así.

Descubrí que casi todos los principios, la sintaxis y las bibliotecas comunes del lenguaje y las tecnologías que uso regularmente se pueden memorizar por completo, usando estas teclas. ¡Aun así, todavía busco constantemente en Internet ejemplos y sabiduría! Pero ese punto, estoy buscando la validación del problema que estoy tratando de resolver, varios enfoques que se han tomado, herramientas que pueden ayudar y consultas para bibliotecas de uso menos frecuente. Es un tipo de búsqueda muy diferente a la que uso cuando estoy aprendiendo un idioma por primera vez en tutoriales y manuales.

De su historia, aquí hay algunos escollos específicos que creo que podría estar encontrando.

  1. Si tiene problemas con la sintaxis, es posible que no esté practicando lo suficiente. Esto es especialmente cierto si está copiando y pegando directamente en su código, en lugar de desarrollar la repetición y, ¿puedo decir? - Memoria muscular que te ayudará a ser realmente bueno. Para contrarrestar esto, simplemente desarrolle ejercicios y disciplina, enfocándose en la repetición y el tiempo, que mejorarán su instalación en las áreas que desea. Sugerencias:
    • Escriba un programa simple en el mismo idioma una vez al día, todos los días.
    • Escriba ejemplos en lugar de copiarlos y pegarlos.
  2. Si tiene dificultades para construir soluciones a problemas de tamaño moderado, es posible que no esté obteniendo suficiente experiencia en la construcción. Prueba estos:
    • Comience un proyecto de tamaño mediano en alguna tecnología o idioma en el que quiera ser bueno. O pruebe con una característica más gruesa en un proyecto de código abierto que le interese. Córtelo un poco todos los días. (Recuerde, cuando vaya tras estos proyectos más grandes: vaya a ellos ladrillo por ladrillo. ¡No intente construir todo de una vez!)
    • Use la misma característica nueva en cuatro días consecutivos, en cuatro contextos diferentes.
    • ¡Desafíate a codificar algo con el navegador web apagado!
    • En realidad, toma notas de las cosas que estás aprendiendo. Sintetice lo que está aprendiendo y escriba sus observaciones. (En realidad, escribir cosas y obligarme a expresar algo con mis propias palabras me ayuda mucho).
    • Escriba respuestas y verifíquelas para las preguntas de StackOverflow sobre la tecnología que está absorbiendo. (Esto a menudo tiene el beneficio adicional de ganar un poco de reputación mientras aprende. :-))
  3. Es posible que esté extendiendo su práctica muy poco. Parece que estás trabajando en muchos idiomas diferentes. Esto tiene muchas ventajas, pero tiene la desventaja de diluir su experiencia. Si pasa tiempo trabajando en cinco idiomas diferentes, memorizará menos que si pasa el mismo tiempo en un idioma. Peor aún, hay muchos cognados no muy similares entre diferentes idiomas (¿sería eso si, elsif o elif?) Para hacerte tropezar. Para contrarrestar esto, agudiza tu enfoque. Elige una cosa para aprender y aprende en frío. Luego pase a lo siguiente.

3

Creo que si te enfocas en crear un código moderado, tu eficiencia y productividad aumentarán. Probablemente lleve más tiempo buscar el código, leerlo / comprenderlo, copiarlo en su fuente, modificarlo en consecuencia, etc.

Si se te ocurre, lo más probable es que se adapte más a tu situación específica, y después de un tiempo estas soluciones te llegarán más rápido que buscarlas.

A mi modo de verlo, es como si quisieras una segunda opinión sobre una determinada solución, así que buscas cómo lo hacen los demás (en Internet). Si se encuentra haciendo / queriendo demasiado esto, piense en ello como si le preguntara a un colega qué piensa sobre una solución. Si le hace una pregunta a su colega cada 15 minutos, probablemente se molestará. Por lo tanto, hará menos preguntas e intentará formularlas usted mismo.

Visualice esto cuando quiera buscar cosas en Internet.


3

La mejor manera de aprender lo que no sabes: ¡búscalo en Google! Siento que estás a la par con la mayoría de los desarrolladores. Ponga el complejo de inferioridad en su mochila y entre con una mente abierta.

No tengas miedo de hacer preguntas, investigar en Google, probar y fallar. Todo es parte de eso.


3

El desarrollo de software en una configuración corporativa requiere una buena cantidad de reutilización de código. ¿Por qué reescribir una función / método si ya existe una API y se usa ampliamente? Lo más probable es que sea tan eficiente como cualquier cosa que escriba y tome menos tiempo.

Por supuesto, tener éxito en el desarrollo de software también requiere un descanso del teclado, para que pueda leer y comprender lo que realmente está sucediendo. Tome cualquier marco web. Debe saber lo que sucede debajo para comprender el código que está escribiendo, pero es probable que nunca tenga que escribir un marco web desde cero.

Solo tiene que escribir código que aproveche el tipo de marco (por ejemplo, un marco basado en componentes requiere un cierto estilo) y esto proviene de comprender el panorama general. Aprenda la imagen más grande y estará bien.


2

De las respuestas ya dadas queda claro que no hay nada de malo en investigar su problema, en lugar de codificar a ciegas. Pero la pregunta que no se abordó, porque no la preguntaste directamente, es por qué te sientes tan inseguro, ¿y qué puedes hacer al respecto? Después de todo, muchas personas buscan problemas en Google y tienen mucha confianza (incluso aquellos que no deberían ...)

¿Entonces lo que hay que hacer? Tal vez solo necesitaba unos cientos de palmaditas en la parte posterior, que acaba de obtener, y ahora puede codificar con confianza. Pero si eso no funcionó, le sugiero que examine las pruebas automatizadas y el desarrollo basado en pruebas. Nada dice "bien hecho" como un "Todas las pruebas aprobadas" de su conjunto de pruebas: cuando llegue allí, sabrá que lo ha hecho bien.

También deberías intentar desafiarte un poco: dices que siempre estás buscando sintaxis que ya conoces; así que esfuérzate a escribir algo de código sin buscar la sintaxis, y pronto (si no inmediatamente) descubrirás que lo estás haciendo bien después de todo.


2

Los desarrolladores no nacen "grandes", pero la grandeza no viene automáticamente con la experiencia. Por el contrario, la falta de experiencia no hace que un desarrollador sea "malo". La diferencia entre un gran desarrollador y un mal desarrollador no está en su dominio de conocimiento, sino en su metodología. La marca distintiva de un gran desarrollador es que codifica conscientemente. Dicho de otra manera, un buen desarrollador siempre sabe por qué está haciendo algo. Desde la perspectiva de la ética personal, esto requiere coraje intelectual e integridad.

Es muy importante tomarse un tiempo y comprender los conceptos básicos, las cosas más complejas se basan en eso. Si no hay una base para entender el lenguaje y lo que sucede detrás de escena, la codificación será simplemente piratería ...


1

Así que leer libros con ejemplos y referirse a ellos es una mala programación es el contexto de su pregunta. Bueno, ya que pocas personas documentan su API, un libro es todo lo que nos queda.

No sé cuáles son sus razones para hacer esta pregunta, tal vez pueda responderla usted mismo después de leer mi situación, ya que me refiero a muchos ejemplos de código.

Nunca tuve la oportunidad de ir a la universidad ya que estaba en la calle a los 16 años. De alguna manera, a los 24 años estaba en condiciones de estudiar a través de una universidad por correspondencia y hacer certificaciones de proveedores como SCJP, SCJD, SCBCD y SCWCD. Debo admitir que a veces luché y tuve que conectarme en línea para ver ejemplos. Sin saberlo, en este momento tenía un tumor cerebral creciendo en mi cabeza (en 2010 era del tamaño de una naranja). Después de mis 5 cirugías cerebrales, 6 semanas combinan quimioterapia / radioterapia y 10 meses de quimioterapia, todavía estoy programando con sitios codificados escritos a mano que se pueden ver desde mi perfil.

Sí, ahora necesito muchos ejemplos de código con daño cerebral, ¿eso me convierte en un mal programador?


Tienes un buen motivo. Por supuesto, uno podría argumentar fácilmente (¡incluso con su propia historia!) Que solo es un programador deficiente que no puede pasar sin que alguien les dé el código. La pregunta es si esa es una evaluación justa.
cHao

1

Entonces veo que mencionaste que vas a un hackathon. He estado en bastantes este año pasado (más de 15) y noté que son excelentes para aprender. Y por genial para aprender me refiero a aprender a nunca volver a codificar así. Principalmente trato de hacer algo nuevo en cada hackathon al que voy para aprender cosas nuevas. Como hay una gran limitación de tiempo, confías en copiar y pegar todo el código que puedes encontrar y esto te muerde el culo cuando lo estás probando.

Sin embargo, las cosas buenas salen de esto, usted: A) APRENDE tanto durante la prueba de errores (también llora mucho) B) Sepa que nunca debe codificar así de nuevo y aprenda mejores prácticas de codificación. Además, en los hackathons conocerás gente que puede enseñarte tantas cosas nuevas que nunca supiste, y harás cosas que nunca harás en la escuela.

Entonces, lo que digo es que el pegado de copias es malo, y no aprenderá nada, y el tiempo que ahorró al pegar copias lo morderá más tarde durante la prueba de errores y no tiene idea de lo que escribió, son las 8 AM, y se alimentan con toda la cafeína. Pero, creo que siempre y cuando pruebes tu código, tendrás que aprender todo lo que copiaste antes.


0

Bueno, no me llamo un buen programador. Pero lo que hago es simple. Si no sé cómo hacer algo, realmente miro algún código / ejemplo en Internet. Luego, después de leerlo, trato de reescribirlo, optimizarlo y usar las cosas que mejor se adapten al código que quiero.

Nota: Leer el código de Internet no te convierte en un mal desarrollador. Siempre es bueno ver cómo lo hacen otras personas, y siempre aprenderás algo. Pero entonces, copiarlo a ciegas no es bueno.


-1

Si un desarrollador / estudiante va a decir ... Wikipedia ... que copie / pegue el código en su proyecto, simplemente intenta que "funcione", entonces las únicas habilidades que esta persona está desarrollando es "Cómo googlear". Puede haber algún proceso de ósmosis allí, pero no un montón. (No creerías cuántas personas hacen esto en los cursos universitarios)

SIN EMBARGO, si analiza el código de otras personas y realmente piensa en lo que está sucediendo en el código, entonces eso no hace que una persona sea un mal desarrollador. Los convierte en un desarrollador determinado y probablemente indica un estilo de aprendizaje que es más táctil o visual. Aprendo con el ejemplo muy bien. Si alguien me dice algo o trata de explicármelo, generalmente les pido que me muestren de qué están hablando.

Mirar, analizar y aprender del código en realidad los convierte en un buen desarrollador con el tiempo , porque están leyendo y aprendiendo en el lenguaje que están utilizando.

A menudo bromeo diciendo que conozco los entresijos de los lenguajes de computadora que mi idioma nativo de inglés. Lo que plantea la pregunta; "¿Me lo explicas en Java por favor?"


-1

Creo que es un poco como jugar al ajedrez. Verificamos las piezas individualmente y rastreamos dónde pueden moverse de acuerdo con las reglas, y debemos pasar por esa comprobación consciente durante un tiempo hasta que el subconsciente se una, revelando patrones y secuencias inspiradas.

Con la programación puede haber más piezas y reglas, a menudo estoy tropezando con la sintaxis y atrapado en errores que tardan una eternidad en encontrar 'las reglas', pero eventualmente el subconsciente entrará en acción. Cuando permanece lo suficiente, puedo leer A veces vuelvo y maravillarse de lo que puede hacer

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.