Personalmente soy programador y me interesan la web, los sistemas distribuidos y el procesamiento de datos.
Veo la web como la tecnología de presentación y visualización más popular y, por naturaleza, multiplataforma; veo lo distribuido como la arquitectura más adecuada para la colaboración entre programas y para los programas colaborativos; y veo el procesamiento de datos como algo que requiere a la vez base, técnicas, cognición, visión y conocimiento del dominio. Por eso, dedicarse al procesamiento de datos mejora la base, las técnicas, la cognición, la visión y el conocimiento del dominio.
Todo esto son tonterías, y bastante enrevesadas, pero entender tonterías, para mí, no es algo tan sencillo.Creo que la mejora de las habilidades proviene de la acumulación profunda, así que hacia las cosas básicas hay que mantener un entusiasmo constante.
Creo que la base debe incluir,pero de ningún modo limitarse a,：
estructuras de datos y algoritmos、
algoritmos、
redes (tcp/ip, p2p, http, etc.)、
arquitectura de computadores y sistemas operativos (gestión de memoria, búfer de alta velocidad y caché, hilos y concurrencia, recursos y contención, ciclos de CPU, principio de localidad, etc.)。
Creo que en la base anterior nunca se alcanza la maestría, al menos desde mi nivel intelectual. Por ejemplo, leíste «Estructuras de datos» de Yan Weimin: muy bien; luego leíste «Introducción a los algoritmos»: mejor; si además puedes ver el libro de algoritmos de Princeton, estás bastante bien; y si además has leído algunos artículos académicos y de verdad has tecleado con vim, emacs, VS, Eclipse o Sublime, deberías poder detectar de un vistazo los errores y el nivel de los artículos sobre algoritmos en blogs por todas partes; entonces sí que tienes algo de oficio.La importancia de la estructura de conocimiento y la experiencia en proyectos se influyen mutuamente. Con el mismo proyecto y roles similares, por las diferencias en la estructura de conocimiento, los avances y las conclusiones también son diferentes; los beneficios que ese avance aporta al siguiente proyecto o a proyectos más complejos también varían. Con un horizonte más largo, esa diferencia es tan enorme que vale 100.000 o 1.000.000.
Tener diez años de experiencia laboral, o repetir la misma cosa durante diez años; la diferencia probablemente esté aquí.Creo que afirmaciones como «dominio de Java» existen, pero no hablar de la JVM es de sinvergüenzas. La familiaridad con las bibliotecas y los frameworks proviene de la ingeniería y los proyectos; puedes conocer bien una API simple o esforzarte por entender AOP; se puede aplicar de manera muy simple o muy compleja. Si te preocupan los escenarios de rendimiento, deberías prestar atención consciente a la JVM. Pero la JVM es un proyecto enorme, así que entenderla es un proceso largo; por eso, dominarla es algo bastante difícil. Sin embargo, en muchos escenarios habituales, como BufferedReader, FileChannel y mmap, todos pueden ser una opción de E/S; cuál es más adecuado suele depender de lo que hagan la máquina virtual y el sistema operativo, y solo así se deducenlas mejores prácticas; de paso, también tendrás una comprensión más profunda de configuraciones simples como Xss, Xmx y directMemory. Al mismo tiempo, ayuda a ver las limitaciones de los lenguajes basados en máquinas virtuales; por ejemplo, BlockBuffer de HBase es en sí un diseño para mejorar la eficiencia de lectura, pero debido al montón y al mecanismo de GC de la JVM, este diseño puede hundir a HBase.
Este punto también debería aplicarse a C# y CLR.Quien ha trabajado muchos años cree, o se tiene por, dominado algo en ciertos aspectos; algunos de verdad lo han logrado, pero a la vez hay cierta pose, hipocresía y muchísimas ganas de lucirse; no va a debatir contigo los problemas en serio. Ese tipo de personas puede estar entre amigos, compañeros de clase, colegas y jefes. Un programador no vive en un recipiente aislado; además de mantener confianza y humildad en su capacidad y de esforzarse más, también debe insistir en algunos principios propios y no dejarse influir por una cultura empresarial o de círculo no demasiado positiva. Ser uno mismo es la única manera de tratar mejor la tecnología y de ofrecer al empleador una mejor sensación de presencia y un valor real.
A este mundo no le faltan trolls; algunos trolls son muy capaces, incluso mucho más que uno. Es su manera de vivir; el control de las emociones no es una técnica; cuanto más a fondo lo entiendes, más claro ves qué es un troll y qué es un «echar de menos que el hierro se vuelva acero» (la frustración por la falta de progreso de alguien).Sobre el pragmatismo tecnológico, siempre hay una opinión como «si no has estado en Estados Unidos, no deberías conocer la bandera de las barras y estrellas». Por ejemplo, no todas las empresas ni todos los programadores entran en contacto conbig data, pero en la antigüedad remota, antes de que el ser humano volara, ya se había iniciado la exploración e interpretación de la civilización mediante tótems y pinturas rupestres. Esto, en el fondo, es la fuerza de la fe; dicho más llanamente, es donde está el interés; dicho aún más llanamente, la oportunidad siempre está reservada para los que están preparados. Estar dispuesto o no a prepararse depende de la actitud y la comprensión; que la preparación pueda servir o no en el futuro depende de la oportunidad. La fortaleza y la suerte son importantes, pero la suerte no la controlas.
La mayor parte del conocimiento humano proviene de canales indirectos, como leer libros, ver medios de comunicación y escuchar rumores; se sale de la escuela, pero no se sale de los medios de conocimiento. Una buena fuente de conocimiento es más importante que un buen método de aprendizaje; esta suele ser la principal diferencia entre universidades impresionantes y no tan impresionantes. En algunas universidades, los profesores ya empezaban a enseñar cuando Weibo todavía estaba en etapa de crecimientocomputación social; si no tuvieras este canal de conocimiento, probablemente no reconocerías el significado de ETL, minería de datos e índice invertido; puede que ya seas diestro en modificar, añadir y compilarlucene.
Pero no importa cuán buena sea la información; sin práctica nunca se sublima. Considero que un buen programador debe prestar atención al código y a la implementación, pero debe abandonar el simple principio de copiar y pegar, aunque copiar y pegar en la mayoría de los casos sea suficiente para el trabajo. En privado, escribir un fragmento de código clave diez y pico de veces es de verdad una estupidez, bastante tonto; pero si en cada forma de escribirlo hay un pensamiento y una comprensión, y lo haces con criterio, luego, al ver los patrones de diseño y la refactorización, oh, resulta que es justo así. Hacer el tonto a la manera de los «frijoles de hinojo» (la pedantería de Kong Yiji) no es algo tan insoportable: al menos entiendes qué es un error y qué es una diferencia, y también te crea escenarios de mejora fuera del trabajo.Mucha gente sostiene esta opinión: los chinos son malos en tecnología, incapaces de escribir Hadoop; lo más importante es ganar dinero, pero aun así se creen muy capaces.
En realidad, tomar «escribir Hadoop» y «ganar dinero» como criterios es de por sí una visión demasiado limitada. En esta vida, el dinero, claro, es importante; tanto da escribir un Hadoop funcional, un mini sistema operativo o una mini máquina virtual: no hay que darle demasiada importancia. La profundidad de comprensión que se crea leyendo el código fuente y la de implementarlo uno mismo es como del cielo a la tierra. Esta manera de hacer las cosas, a lo «Yu Gong moviendo montañas», se trata más de obligarte a conocer más, con más precisión y con más profundidad. La mayoría de los expertos en Hadoop, en realidad, solo han leído el código fuente y ya han podido publicar libros. De hecho, muchas empresas en la práctica solo ejecutan algoritmos de minería muy simples y maduros; los ingenieros de iQIYI también hacen regresión lineal solo para el uso práctico; la mayoría de las empresas todavía están procesando logs. A veces, pensar en un algoritmo increíble no es tan importante como cambiarse a un SSD. Entonces, ¿si no hay ese entorno ni esas condiciones, no se investiga? Yo creo que no.
Sobre ganar dinero: creo que, mientras esté el interés y se pueda hacer bien el trabajo, el dinero llegará solo. Si los ingresos no suben, suele ser porque lo que se hace no está en la franja de los altos ingresos; escribir programas difícilmente crea millonarios. Para ser sincero, el gasto de un día de una escort puede ser varias veces tu salario, por no hablar de los ingresos de una escort. En el club nocturno, si quieres pasarlo muy bien y no pides dos botellas de Louis XIII, hasta las chicas te llamarán falso ricachón; y si no le mandas el ramo de flores de marca roja, azul o verde que tanto te gusta, te dará vergüenza volver con ella al barrio o al hotel a «discutir algoritmos genéticos».
Entonces, los que se van con escorts a discutiralgoritmos genéticos, como el director Wang y el ingeniero Li, tienen unos ingresos que un programador no puede ni de lejos igualar.
Así que no ates deliberadamente el escribir programas con ganar dinero:limitaríastu capacidad de ganar dinero.
Fuente:http://www.cnblogs.com/foreach-break/p/be_a_real_programmer.html