Me encuentro ayudando a programadores novatos con relativa frecuencia; explicando por qué su código no funcionará cuando preguntan, sugiriendo soluciones y similares. Las personas a las que ayudo tienen una educación formal en programación desde un módulo de primer grado, en Java, pero siento que no puedo comunicarme con ellos muy bien.
Por ejemplo: uno podría escribir una función pero no entender por qué no se ejecuta, sin darse cuenta de que olvidaron llamarla. Si uso frases como "(make a) call (to) the function/it"y "pass it the.."obtengo miradas en blanco.
Mi proceso normal sería encontrar un lugar en su código donde invoquen una función desde el idioma y decirles que pueden llamar a sus propias funciones de la misma manera que llamaron a esta otra función. A veces, incluso eso se ve en blanco.
¿Hay otras piezas de vocabulario que sean más adecuadas para (¿mejor para?) Ayudar a los programadores novatos? ¿O no se trata de un problema de comunicación?
fuente
Respuestas:
Con el tiempo, tendrán que aprender los términos adecuados, cuanto antes mejor.
Úselos correctamente y explíquelos siempre que tenga una mirada en blanco. Solo trate de enviar las señales correctas, que está bien preguntar sobre cualquier cosa que no entiendan; las únicas preguntas estúpidas son las que no hace.
fuente
En general
Cuando una persona no te entiende, tienes dos alternativas:
Adaptar el vocabulario de acuerdo con lo que la persona sabe o no,
Explique a la persona los términos que no entiende.
El primer caso funciona bien cuando la persona ya conoce bastante bien el vocabulario técnico, pero no lo suficiente o no está en su dominio.
Por ejemplo, puede usar el término método en C # o Java, y la persona que trabaja principalmente con algún otro lenguaje no entendería este término. Luego explicará que en C # o Java, el método se refiere a lo que habitualmente llamamos función (por ejemplo, en C), y que no existe una función en C # o Java . En PHP , por ejemplo, existen métodos y funciones, y tienen un significado diferente . Si la diferencia es demasiado dolorosa para la persona, hablará sobre las funciones en aras de la simplicidad.
En su caso preciso, difícilmente puede elegir el primero: "hacer una llamada a la función" no puede reformularse de una manera más simple. Una llamada es una llamada. No puedes simplificar esto más.
Esto significa que debe elegir la segunda forma: explicar a la persona cada término técnico.
Apunte a la persona a un diccionario o Wikipedia, que funciona muy bien para conceptos básicos y terminología.
Elegiría esto para los términos de uso común . Por ejemplo, preferiría invitar a la persona a leer Wikipedia para comprender qué es el polimorfismo o qué son covarianza y contravarianza. Esos términos ya se explican muy bien, por lo que no es necesario reinventar la rueda aquí.
O explica en tus propias palabras .
Elegiría esto para términos que son específicos del contexto y / o que aceptan una amplia gama de definiciones . Por ejemplo, Wikipedia no es muy útil para comprender la visión de Microsoft de la computación en la nube, y preferiría explicarme qué es la nube a alguien que trabajará en una aplicación de Windows Azure.
En tu caso particular
Las personas con las que está hablando carecen de los conceptos y términos más básicos utilizados en la programación. No pueden continuar sin aprender este vocabulario básico , porque no pueden comunicarse en absoluto : no pueden leer libros sobre programación o blogs, no pueden escuchar a sus colegas e incluso no pueden hacer preguntas sobre Apila los sitios web de Exchange, ya que nadie entenderá lo que están preguntando.
En su caso, en lugar de buscar el vocabulario adecuado, pasaría unos días o semanas enseñándoles algunos conceptos básicos de programación y los términos de uso común . Después de unos días, podrá hablar con ellos sin tener que "dibujarles constantemente y usar metáforas que involucren a gatos y perros" .
fuente
En lugar de funciones , comience con subrutinas . Dígales que un programa es solo una lista de instrucciones, una receta para decirle a la computadora cómo hacer algo. Y que se está ejecutando una instrucción tras otra (con la posibilidad de hacer algunos pasos en paralelo, pero más sobre eso más adelante).
Algunas tareas son bastante comunes y repetitivas, por lo que sería terrible si siempre tuviéramos que escribirlas una y otra vez, por lo que las escribimos solo una vez y hacemos un "programa más pequeño": una subrutina que puede ser reutilizada por otras partes del programa Para poder ejecutarlo más de una vez, le damos un nombre significativo en nuestro programa. Y luego podemos usar ese nombre cuando queramos ejecutar este "pequeño programa" como parte de uno más grande, llamándolo por ese nombre.
Llamar a una subrutina es como convocar a un demonio que sabe cómo realizar esa tarea, con el nombre de ese demonio. Entonces, cuando queremos hacer esa tarea en particular en nuestro programa, escribimos "llama al demonio llamado Argoth", y el demonio aparece y hace la tarea por nosotros como le indicamos, y luego se va y podemos continuar con nuestro trabajo.
A veces, el demonio requiere información adicional sin la cual no puede decidir qué tareas realizar, o qué es lo que realmente queremos de él. Por ejemplo, si se supone que el demonio construye un castillo, es posible que necesite saber dónde se supone que lo construirá, o qué tan grande , etc. Esos son los argumentos pasados al demonio ... Quiero decir, la subrutina, que ahora se convierte en parametrizada .
Los parámetros son aquellas piezas de información que faltan, pero se requieren, para realizar la tarea. Cambian un poco lo que la subrutina puede hacer. Son como espacios en blanco en la receta que deben completarse antes de que podamos ejecutarla.
Los argumentos , por otro lado, son la información real (valores) que suministramos para estos parámetros.
En cuanto a la ejecución paralela, podemos pensar de esta manera: siempre hay alguien (o algo ) que está ejecutando el programa (la lista de instrucciones). Es otro ser humano (¿sabías que "computadora" alguna vez fue el nombre de una persona que realizaba el cálculo?) O una máquina. Un programa es solo una lista de instrucciones, no funciona por sí solo. Debe haber alguien o algo que haga el proceso computacional(realice estas acciones de la lista). Y a veces estas acciones se pueden hacer en paralelo: podemos distribuir las copias de la lista a varias personas y dejar que cada una de ellas realice un conjunto diferente de tareas de la lista, siempre que no se interrumpan entre sí, o no No tiene que esperar los resultados del trabajo de otra persona. Eso es multihilo para ti;)
En cuanto a la diferencia entre funciones y subrutinas (también llamadas procedimientos ), la diferencia habitual es que se llama a una función para calcular un cierto valor que devuelve como resultado de su ejecución, mientras que los procedimientos se ejecutan solo por diversión;) AKA por sus "efectos secundarios", solo por el bien de las operaciones realizadas de la lista.
Pero si llama un procedimiento o función causa algunos problemas al principio, puede usar otro término que alguna vez fue popular: saltar . Uno puede saltar a una subrutina, lo que significa que deja de ejecutar lo que esté haciendo en este momento y "salta" a otro lugar en la lista (u otra lista), la subrutina, para realizar sus tareas. Luego, cuando terminas, "saltas", es decir, regresas al lugar donde te interrumpieron, para que puedas continuar con tu tarea anterior. La diferencia entre llamar y saltar es que ahora eres el demonio.
En cuanto a los métodos mencionados aquí por alguien, o el hecho de que algunos lenguajes "no tienen funciones, solo métodos", ¡eso no es del todo correcto, porque los métodos son funciones! - un tipo especial de ellos: son funciones que se están utilizando para recuperar cierta información encapsulada dentro de un objeto, u operar en ellas. Son un "método de operar con esos datos". El nombre proviene del paradigma orientado a objetos en el que los datos están encerrados dentro de objetos y no se pueden operar directamente, solo mediante funciones especiales llamadas "métodos".
Un método es especial de otra manera: tiene que saber qué objeto en particular se supone que debe operar / ser llamado (el objeto "este"). Es por eso que los métodos generalmente se embellecen con un parámetro oculto adicional que almacena información sobre el objeto sobre el que se ha llamado (el puntero "este"). Esto complica la forma en que se llama un poco a la función, pero es un "detalle de implementación" que un programador no debería molestar mucho, siempre que sepa lo que está haciendo.
fuente