¿Es posible que un desarrollador trabaje durante varios años sin tener que escribir un algoritmo exigente, o ningún algoritmo?

Te haces esta pregunta en la universidad. Las lecciones parecen demasiado fundamentales, y la industria parece estar construida “sobre el hombro de gigantes”, sin necesidad de reinventar la rueda nuevamente.

Una vez que pase unos años en la industria, descubrirá:

La ley de las abstracciones permeables

Ver:
http://en.wikipedia.org/wiki/Lea…
http://www.joelonsoftware.com/ar…

Esto es lo que nuestro amigo Fred Yeomans llama aquí sabiendo lo que está “oculto”, algo que una persona con una formación académica fundamental puede hacer mejor que alguien que ha adquirido habilidades en el camino. En esencia, cada algoritmo que “reutiliza” es una abstracción. Y “Como acuñó Spolsky, ‘Todas las abstracciones no triviales, hasta cierto punto, tienen fugas’. ”

El ejemplo simple es un automóvil. Puede comprar y conducir un automóvil durante mucho tiempo sin tener que saber lo más mínimo sobre lo que hay debajo del capó. Pero cualquier conductor experimentado le dirá que tarde o temprano se quedará perplejo si no conoce las partes internas. Olvidarás poner aceite, te quedarás sin gasolina, quemar el motor o abusar del auto. El “cuerpo” que encapsula las partes internas de un automóvil, en otras palabras, es una abstracción permeable, ya que en realidad no lo protege de la necesidad de saber qué hay dentro.

Lo mismo ocurre con la ingeniería de software. Por ejemplo, “ordenar” y “filtrar” se abstrajeron y resolvieron hace décadas. Pero aquí en Google, el mismo problema surgió nuevamente cuando algo tan gigantesco y en constante expansión como el universo de Internet tuvo que ser ordenado y filtrado (buscado). La abstracción de la clasificación y el filtrado resultó “permeable” a los primeros signos de que no se podía indexar todo en la memoria de una sola computadora. De hecho, la cantidad de computadoras que necesita usar para indexar Internet aumenta con el tamaño de Internet. En efecto, el algoritmo tuvo que reinventarse para ejecutarse en una arquitectura distribuida. (Ver MapReduce: http://en.wikipedia.org/wiki/Map…) Y esta no será la última vez que ocurra la reinvención. Cualquier cambio fundamental en la arquitectura de la industria, por ejemplo, computadoras cuánticas o nanocomputadoras, puede redefinir completamente cómo el mundo implementaría estos algoritmos. Al igual que el motor eléctrico está redefiniendo lo que hay debajo del capó en un automóvil.

La tecnología se reinventa cada vez más rápidamente debido a estos cambios sísmicos en los supuestos sobre los que se basa. Solía ​​ser cada 1000 años que estos supuestos cambiaron. Desde el Renacimiento, se convirtió cada 100 años. Desde la Revolución Industrial, comenzó a suceder cada 10 años. En la era de Internet, cada año presenta un cambio por el cual usted, entre la próxima generación de ingenieros, tendrá que reinventar todas las ruedas que hemos creado hasta ahora.

No solo es posible, sino bastante probable, dependiendo del tipo de rol en el que se encuentre. Hay muchas áreas de desarrollo de software que implican poco o ningún desarrollo “algorítmico” (utilicé las citas allí, porque todo lo que escribe es un algoritmo en algún sentido de la palabra). El desarrollo de UI más moderno (web, móvil, etc.) implica poco desarrollo algorítmico difícil (a diferencia de los viejos tiempos cuando la programación de gráficos, incluso en el nivel superior, era bastante desordenada). Implementar formularios sobre operaciones de base de datos generalmente no es tan “algorítmico”.

Gran parte de lo que ahora escriben los “desarrolladores de software” se encuentra en la parte superior de las bibliotecas algorítmicas que implementan la funcionalidad principal para que no tenga que escribirlo usted mismo.

Esto es a la vez una bendición y una maldición. Permite grandes ganancias de productividad sobre escribir todo usted mismo. En el lado negativo, muchos desarrolladores usan bibliotecas sin comprender realmente los algoritmos subyacentes (sus fortalezas, debilidades, costos, etc.). Creo que a menudo es la principal ventaja que alguien con un título de CS tiene sobre alguien con un diploma de programación, la comprensión de lo que está “debajo de las cubiertas”, aunque a menudo eso se pierde si no se usa.

Por otro lado, existen muchos roles en los que implementará algoritmos a diario (escribir servidores de bases de datos, motores de búsqueda, motores de gráficos, software de modelado y simulación, etc.) y si es inteligente y afortunado, podría llegar a trabajar en inventar algoritmos.

Alguien tiene que escribir cosas geniales, después de todo.

No solo eso, sino que puede escribir grandes aplicaciones, especialmente aplicaciones web, sin escribir mucho código. Pero si lo llamas un defecto en la universidad, te estás perdiendo el punto. Tus estudios te dan una base para resolver problemas. Una educación excesivamente vocacional te dejaría demasiado vulnerable al tipo de cambio que no solo es posible, sino probable. Aprende a aprender. Tener una base amplia y estable de conocimiento y es menos probable que la vida te vuelque.

Si. Cuanto más te acerques a la interfaz de usuario, menos algoritmos tendrás que escribir. Si usted es puramente un desarrollador front-end o un desarrollador de diseño que trabaja con diseños, animaciones y controles personalizados, será un día raro en el que tendrá que escribir cualquier algoritmo. Los desarrolladores que están inmersos en las transformaciones de datos, IA, motores de juegos, etc., hacen mucho con los algoritmos. Pero eso no es todo el mundo.

Completamente posible. Un desarrollador de UI, por ejemplo, no necesitará ningún algoritmo. Y especialmente porque existen muchas bibliotecas que ocultan la parte algorítmica (probablemente nunca volveré a escribir un algoritmo de clasificación).

En mi experiencia, esto también puede ser una elección. Puede reutilizar algo que esté disponible y hackearlo un poco para que se adapte a su problema. O intente hacer una rueda más redonda e implementar algo exactamente como lo necesita. No estoy discutiendo por una elección automática entre los dos para cada ocasión, aunque es poco probable que te despidan por primera vez. El segundo puede despreciar a los extremistas y trajes ágiles, pero después de un poco de práctica, sus soluciones probablemente serán mejores (mantenibles, eficaces, etc.) y probablemente aprenderá algunos trucos de los que su empleador puede beneficiarse.

Mi jefe se jactó de que nunca había escrito programación dinámica después de graduarse de la universidad