¿Cómo se programa en una computadora sin utilizar ningún software?

40267">

7 cosas que aprendí de la programación y la escritura de software. De hecho, no es difícil aprender a programar y no es difícil escribir software. Depende de cómo lo vemos!

Estoy pasando de ingeniero a gerente poco a poco, no se equivoquen, aunque estoy cambiando a administración, todavía escribo código todos los días, pero me encuentro haciéndolo. en reuniones y en el teléfono. Dedique cada vez más tiempo a analizar discusiones, tratar de organizar el equipo y preocuparse por el panorama general en lugar de por tácticas específicas.

Por supuesto, esto no es algo malo. Las decisiones de nivel suelen ser mejores que las decisiones individuales. Los detalles de las clases y funciones tienen más impacto. Hacer que un equipo sea más eficiente tiene una mayor influencia que simplemente hacerse más productivo. Pero creo que he aprendido algunas lecciones de mis años de programación. Parte de la experiencia se puede aplicar a la gestión.

1. No hay reglas, sólo koans

Traducción: Koan tiene cinco significados importantes: Es una herramienta del Zen. ; es un método de prueba; es un modelo autorizado; es una señal de confirmación; es una guía definitiva)

Por ejemplo: DRY significa "No te repitas". Esto es fácil de entender como una regla básica del software, porque hay muchas maneras de decir: "Hago X porque no se repite". Esto tiene sentido, ¿no? Si tienes dos o más fragmentos de código haciendo lo mismo, lo estás desperdiciando. Y si necesita cambiar uno de ellos, probablemente también necesitará cambiar los demás, y es probable que se olvide de hacerlo. Cuando no están sincronizados, aparece un error extraño. Obviamente no puedes repetirte.

Sin embargo, después de algunos años de uso, la gente empezó a dudar de su aplicabilidad general. Supongamos que tiene dos métodos que contienen el mismo bloque de código, por lo que lo saca y lo convierte en una función separada. A menudo esos métodos comienzan a ir en diferentes direcciones... luego te encuentras agregando más parámetros a la función, probablemente estableciendo más indicadores para el resultado... y luego el próximo programador que tome el control se sentirá confundido por la separación de funciones y Lleva parámetros y resultados específicos, lo que resulta en una carga cognitiva. Te darás cuenta de que el código que generes será más simple e intuitivo si te permites repetirlo y dejar que las dos piezas de código se desarrollen naturalmente en entidades separadas.

¿Significa esto que DRY es malo? ¡Por supuesto que no! Generalmente es correcto usar DRY en las circunstancias adecuadas... bueno, tal vez. Mi experiencia personal es: "Una vez está bien, más de una vez no está tan bien... por supuesto que depende del entorno". El propósito de DRY no es ser SECO. Si eres supersticioso con esto, chico, tienes mucho que aprender. El propósito de DRY es permitirle comprender DRY. Por supuesto, esto no es una regla, sólo un koan.

(Permítanme reiterar: estoy hablando de software. En mi experiencia, las especificaciones de hardware tienden a ser más lo que entendemos que son. Es por eso que cambié de la ingeniería eléctrica al software)

Considere dos de mis “leyes” favoritas de la informática. Primero: "¡No hay ningún problema en informática que no pueda resolverse añadiendo otra capa de abstracción!". ¿Es esta afirmación completamente cierta? Por supuesto que no. ¿Es esto fenomenológicamente correcto? En realidad lo es. ¿Significa esto que la abstracción es la forma correcta de resolver cualquier problema? No, no lo es. Es un koan que puede inspirar el pensamiento.

Y mi favorito de todos los tiempos: "La Primera Ley de Optimización: No hagas esto. La Segunda Ley de Optimización (para expertos): No lo vuelvas a hacer. Obviamente, esto es un koan". , pero dice Hazte tú mismo la ley. ¿Es hora de hacer que su código se ejecute más rápido? No. ¿Es hora de hacer que su código se ejecute más rápido? Aún no. ¿Cuál es el significado? Significa tener en cuenta el tiempo, la complejidad, la carga cognitiva, los resultados concretos, el sentido de la vida, el sentido de la existencia humana. Y piensa antes de actuar, chico. Pero no tardes mucho, todavía tenemos trabajo por hacer.

2. Si quieres ganarte la confianza de los demás, confía en los demás primero.

Esto no es solo para gerentes. Aunque es especialmente importante para los directivos. La confianza es el único valor que realmente tienes. Si no se confía en su imparcialidad, juicio, comprensión y honestidad. A continuación, los miembros de su organización lo verán como un flagelo y lo rodearán.

Sin embargo, si es un desarrollador capaz pero no confiable, es posible que aún tenga algo de valor. Aunque el esfuerzo que pongas en cada decisión se verá muy reducido.

Pero el punto más importante es que los miembros de un equipo deben confiar entre sí. Cuando Natascia dice: "Yo arreglaré ese billete", debes confiar en que ella lo hará. Cuando dices: "Peter puede cumplir el plazo", tienes que creer que eso sucederá. Cuando alguien dice: "Tengo una idea loca", debe confiar en que será respetado y tomado en serio, aunque la idea sea realmente loca.

¿Cómo se construye y se gana confianza? La respuesta es simple: confías en los demás. Confías en el tipo que dice que puede aprender esta nueva biblioteca y que estará integrada el lunes. Le crees al tipo que dice que necesita salir temprano porque tiene algo que hacer en casa y mañana faltará al trabajo. Crees en las personas que quieren tomarse unas vacaciones un mes antes de la fecha límite porque sienten que están empezando a agotarse. Confías en los programadores junior que dicen querer resolver problemas difíciles.

Pero no siempre tienes la razón. A veces la gente tiene malas intenciones en el trabajo. Es necesario exponer los verdaderos colores de estas personas y sacarlas del camino lo antes posible. A veces hay que confiar en personas que realmente quieren triunfar, aunque fracasen. Pero, contraintuitivamente, esto suele ser una victoria a largo plazo. Porque esas personas recordarán tu confianza y harán todo lo posible para recompensarte.

3. La simplicidad es mucho más importante que la elegancia

También me gusta el código compacto y elegante. Me gustan los marcos flexibles que tienen tantos niveles de abstracción listos para manejar cualquier requisito cambiante que se les presente. Me gusta trabajar con vectores de bits, desplazamientos de bits, estructuras de datos un poco más complejas y pequeñas características del lenguaje que no son muy populares ni extravagantes, pero que son útiles en determinadas circunstancias.

Sin embargo, no solo escribes código para ti mismo. Incluso si es sólo un "prototipo". (He perdido la cuenta de cuántos “prototipos” he tenido que se estropearon en el transcurso de múltiples capas y pulidos). Y no lo estás escribiendo simplemente para resolver un problema actual. Lo estás escribiendo para que el próximo desarrollador que asuma el control pueda usarlo para resolver el siguiente problema. Expandir esas cinco líneas de código que escribiste a diez lo hará más legible, y sabes qué, tal vez extenderlo a quince sería aún mejor.

Puedes probarlos con antelación y resolverlos con un framework flexible y lleno de abstracciones. Pero tal vez la profecía no sea su fuerte, y tal vez su idea de de qué trata la siguiente pregunta sea simplemente incorrecta. Quizás escribir un código lo suficientemente simple sea la mejor opción. Existe una convención de nomenclatura y un estilo de codificación que hace que se lea como en inglés. Quizás en lugar de agregar una clase, el próximo desarrollador tenga que mantener otro archivo abierto cuando intente seguir su flujo de control. Deberías hacerlo de una manera estúpida, poco elegante, sencilla.

4. La motivación es más importante que la mayoría de las cosas

Todos hemos visto que esto suceda. Durante la semana, todos verifican el código, crean prototipos obvios, agregan funciones todos los días y obtienen una cobertura de prueba cada vez mejor. La negligencia también surge con la producción de ideas y soluciones. De alguna manera todo se ralentizó la semana siguiente. Una decisión sobre A afecta a B, C y D. Si bien se pueden ejecutar D, E y F, no forman parte del desarrollo de la secuencia lógica. Por lo tanto, es necesario hacer más suposiciones, la carga cognitiva aumenta y hay que simular muchas cosas para escribir código no imitativo. Algunas personas necesitan tomar esta decisión.

Quizás no sea la parálisis de decisiones, sino todo lo que hiciste la semana pasada lo que se basó en una base equivocada, la deuda técnica de una “zona propensa a terremotos”. Debes detener todo, regresar y refactorizarlo. Y tienes que empezar de inmediato, porque cuanto más esperes, peor se pondrán las cosas. Nadie quiere que esto suceda. Pero preferirían afrontarlo ahora que saberlo el mes que viene. Que la tormenta llegue con más violencia.

Tal vez todos trabajaron duro la semana pasada, pero ahora ya no pueden aguantar más. ¿Sabes qué hacer? Hay que darles un descanso a todos, un día completo. Lo prometo, esto le ahorrará tiempo en su próxima carrera larga.

Tengo dificultad para definir, medir y explicar la motivación. Pero es algo real en el desarrollo de software. Y su ausencia se convertirá en el impacto principal, lo que nos obligará a resolver muchos problemas fundamentales. No lo ignores y no esperes ni pretendas que volverá mágicamente. Reconozca alarmas y actúe rápidamente.

5. Trabaja con personas que te complementen, no que sean como tú.

Cada vez que veo personas que buscan personas basándose en su “adaptación cultural”, pongo los ojos en blanco desesperadamente. ¿Sabes qué pasa con la mayoría de los monocultivos? Se encuentran con un patógeno que no saben cómo combatir y luego mueren.

No desea que todos sus desarrolladores, diseñadores, personal de control de calidad, personal de productos, personal de ventas y ejecutivos sean clones unos de otros. Ciertamente no quieres hacerlo. Cada uno tiene sus propias fortalezas y debilidades, fortalezas y debilidades. Quiere contratar por sus fortalezas y dejar que las fortalezas de los demás compensen sus debilidades.

Por ejemplo, escribo código muy rápido, soy bueno comunicándome y puedo leer y escribir artículos muy rápidamente. Estoy familiarizado con muchos lenguajes y marcos de programación en un momento dado. Entiendo las cosas a fondo y rápidamente, y tengo una gran experiencia. Sin embargo, sigo siendo un generalista que carece de experiencia y dominio profundos en campos, marcos e idiomas específicos. Soy un arquitecto que realmente trabaja con otras personas, haciendo un seguimiento de todas las necesidades, agregando carne y pulimento después de que los huesos están construidos. Todavía soy analfabeto en UX (espera, ¿dijiste que todavía no están alineados?), Y siempre ha sido una broma entre colegas.

Las personas como yo son difíciles de encontrar y necesarias. Pero una empresa formada por mí y nueve clones como yo estaba condenada al fracaso desde el principio. Bueno, hacemos muchas cosas bien, pero sólo hace falta un punto ciego concentrado, una brecha catastrófica, para destruir una empresa. La mayoría de las personas admiten que hay cosas que no pueden hacer bien y que otras pueden necesitar atención. Suelen ser personas que buscan una "adaptación cultural" y tratan de contratar personas que sean como ellos. Es realmente asombroso.

6. Cualquier decisión es mejor que ninguna decisión.

No lo dudes, cuando no estés seguro, simplemente hazlo. Por supuesto, es posible que esto no se aplique al producir código. Pero se puede aplicar a cualquier otra cosa que no sea el desarrollo de software. Trabajamos en la industria de más rápido crecimiento de la historia. Vivimos en un mundo que evoluciona exponencialmente. El tiempo no espera a nadie, no lo desperdicies.

Esto es tan cierto como las discusiones de alto nivel sobre decisiones de bajo nivel. En discusiones de alto nivel, como "¿Deberíamos implementar la característica A o decir B? ¿De qué manera deberíamos implementarla, X o Y?", a menudo el diálogo resultará en: "Saltemos esto por ahora... Zhou lo analiza". otra vez...", o más insidiosamente, "Estudiemos lo que otros han hecho antes de discutirlo nuevamente". Preguntas como ésta rara vez tienen una respuesta correcta. La mayoría de las veces, es correcto decir algo como: "Decidiré cuál probaré hoy para que podamos empezar a hacerlo mañana".

Incluso si la opción A es básicamente la opción equivocada, empieza a hacerla. A Probablemente sea mejor que no hacer nada. Esto es contrario a la intuición, pero a menudo es cierto que es mejor comprender la naturaleza de A de manera práctica. Esta comprensión siempre es correcta y puede llevarte a tomar mejores decisiones. >Esto es especialmente cierto para decisiones de bajo nivel. "La especificación no dice cómo debemos manejar la condición de error X, o cuál debe ser el mensaje de error. "(La especificación parece estar escrita para una utopía aspiracional donde las condiciones de error son tan raras como los unicornios)." Lo sé, solo quería intervenir y volver atrás y preguntar qué pensaban en esta situación. ¡Hacer qué!"

Es muy tentador. Si lo haces, nadie podrá acusarte de hacer algo mal. Pero está mal hacerlo. Es mejor seguir tomando tus propias decisiones, aunque sea precipitadamente, que no hacer nada y esperar a preguntar a los demás. .Permítales repetir lo que ya ha escrito y las lecciones que ha aprendido, aunque sepa que no es perfecto, en lugar de comenzar desde cero con el conocimiento equivocado de que ellos y el proyecto mejorarán. dirección rápidamente.

7. Mantente humilde, pero ten confianza.

Incluso yo tengo que admitir que no. Hay todas las respuestas. Tengo la mayoría de ellos, pero estoy seguro de que, con suficiente tiempo y esfuerzo, puedo resolverlos y tú también.

No todos podemos ser Jeff Dean, Satoshi Nakamoto o Margaret Hamilton. Estamos en un lugar lleno de genios reales y genios autoproclamados del Trabajo.

Nadie lo sabe todo y todo el mundo es muy consciente de todo lo que no sabe. Afortunadamente, en su mayor parte no somos científicos. Nuestro trabajo no es encontrar nuevos avances. Nuestro trabajo es implementar los descubrimientos de otras personas, hacer que las cosas funcionen y, con suerte, servir a lo que la gente realmente quiere. Quizás nunca inventes nada como filtros Bloom o árboles Merkle. Pero tampoco lo hará la mayoría de las personas con las que interactúas. Y este no es el punto. El punto es usar filtros Bloom y árboles Merkle, o construir una capa de abstracción encima de ellos, para completarlos.

Así que es un error suponer que sabes más que todos los demás aquí, incluso si piensas que sus ideas contraintuitivas son una locura y sus elecciones de idioma son terribles. También es un error suponer que la gente sabe más que tú, e incluso si lo saben, está bien. Hay muchas personas inteligentes en el mundo que no han logrado nada práctico por razones inexplicables. (Solo una broma barata╮(╯▽╰)╭: Por eso tenemos la academia.)

Si realmente haces algo, frente a esos vertiginosos No hay necesidad de ser modesto cuando se trata a conocimientos teóricos, o personas similares a usted o incluso peores que usted. Al final del día, son los desarrolladores en las trincheras (las personas que crearon, probaron y desarrollaron el código) quienes realmente hacen el trabajo. Hablando de aquellos que se encuentran lejos de las trincheras, de aquellos desertores que no lucharon junto a vosotros, tenéis derecho a despreciarlos. Y quítate el sombrero ante tu pareja, no ante tu jefe.

Título original: Haz estas 7 cosas y te resultará fácil aprender a programar y escribir software

Enlace original: /peixun/software/201840267.html