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

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?

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).

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".

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.

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.

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.

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.

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.

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 ...)

... 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 ...

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?

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.

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.

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?"

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