I myself am a programmer, focusing on the web, distributed computing, and data processing.
I regard the web as the most popular, natively cross-platform presentation and visualization technology; distributed computing as the most suitable architecture for program collaboration and cooperative programs; and data processing as something that requires fundamentals, skills, cognition, vision, and domain knowledge all at once. So doing data processing will improve your fundamentals, skills, cognition, vision, and domain knowledge.
These are all empty words, and quite convoluted at that. But understanding empty words is not such a simple thing for me.I believe improvement in ability comes from accumulation, so one should maintain lasting enthusiasm for foundational things.
I think the fundamentals should include butare far from limited to：
data structures and algorithms、
algorithms、
networking (tcp/ip, p2p, http, etc.)、
computer architecture and operating systems (memory management, high-speed buffers and caches, threads and concurrency, resources and contention, CPU cycles, locality principles, etc.)。
I believe the above fundamentals can never be "mastered," at least at my level of intelligence. For example, if you've read Yan Weimin's Data Structures, that's good; if you've also read Introduction to Algorithms, that's better; if you can read Princeton's Algorithms, you're pretty good; and if you've also read some papers and actually typed code with vim, emacs, VS, Eclipse, or Sublime, then you should be able to see at a glance the flaws and the levels in the algorithm articles in blogs all over the world—then you do have some real skill.The importance of knowledge structure and project experience influence each other. For the same project and similar roles, because of different knowledge structures, the improvement and takeaways will also differ, and the benefit this improvement brings to the next project or more complex projects will also differ. Over a longer span of time, this difference becomes as huge as being worth 100K versus 1M.
Having ten years of work experience, or repeating one thing for ten years—the difference may lie right here.I think claims like "mastering Java" do exist, but not discussing the JVM is being a rogue. Familiarity with class libraries and frameworks comes from engineering and projects. You can be familiar with a simple API, or you can chase down an understanding of AOP; the application can be very simple or very complex. If you care about performance scenarios, then you should consciously pay attention to the JVM. But the JVM is a massive engineering effort, so understanding it is a long-term process, making mastery a rather difficult thing. However, in many common scenarios—for example, BufferedReader, FileChannel, and mmap can all be options for I/O—which one is more suitable often depends on what the virtual machine and the operating system are doing underneath. Only then can you work outthe best practices.Incidentally, you will also gain a deeper understanding of simple configurations such as Xss, Xmx, and directMemory. At the same time, it helps you see the limitations of virtual machine-based languages. For example, HBase's BlockBuffer is itself a design intended to improve read efficiency, but because of the JVM's heap and GC mechanisms, this design can drag HBase down.
This point should also apply to C# & CLR.People who have worked for many years all believe, or pride themselves on, reaching a level of mastery in some area. Some have indeed reached it, but it often comes with some affectation, hypocrisy, and a strong love of showing off cleverness; they won't have a genuine discussion with you. Such people may exist among friends, classmates, colleagues, and superiors. A programmer doesn't live in an isolated container. Besides maintaining confidence and humility in ability and putting in more effort, you also need to stick to your own principles and not be influenced by corporate culture or circle culture that isn't positive enough. Only by being yourself can you treat technology better and bring your employer a better vibe and real value.
The world is not short of trolls; some trolls are themselves quite capable, even far more capable than you. That's just their way of living. Emotional control is not a technique; the more thoroughly you understand it, the more clearly you can see what is a troll and what is the frustration of wanting iron to become steel (disappointment at someone's lack of progress).Regarding technical pragmatism, there is always a viewpoint that if you haven't been to the United States, you shouldn't know the Stars and Stripes. For example, not every company or every programmer will come into contact withbig data, but in ancient times before humans could fly, they had already begun exploring and interpreting civilization through totems and murals. This kind of thing is actually the power of faith; to put it crudely, it's where your interest lies; to put it more crudely, opportunity always favors the prepared mind. Whether you're willing to prepare depends on attitude and understanding; whether the preparation can be used in the future depends on opportunity. Strength and luck are both important, but luck is something you can't control.
Some teachers at certain schools were already teaching while Weibo was still in its growth stage:social computing. If you don't have this knowledge channel, you probably wouldn't recognize the meanings of ETL, data mining, and inverted indexes; you might already be proficient at modifying, adding, and compilinglucene.
But no matter how good the knowledge is, without practice it will not be elevated. I think a good programmer should focus on code and implementation, but should abandon the simple copy principle, even though copy is good enough to get work done in most cases. In private, writing a key piece of code a dozen times is really silly and quite stupid. But if there is thought and understanding in each way of writing, and you do it selectively, then when you look at design patterns and refactoring—oh, so that's really how it is. Playing the fool in the fennel-bean way (like Kong Yiji, obsessing over trivial details) is not so unbearable; at least you understand what is wrong and what makes a difference, and it also creates scenarios for improvement outside of work.Many people hold this view: Chinese people are bad at technology and can't write Hadoop anyway; making money is most important—but they still think they're quite capable themselves.
Actually, taking "writing Hadoop" and "making money" as the standard is itself too limited. In this life, money is of course important, but whether you write a usable Hadoop, a mini operating system, or a mini virtual machine, none of it needs to be taken too seriously. The depth of understanding created by reading source code versus implementing it yourself is as different as heaven and earth. This "Foolish Old Man moving mountains" approach is more about forcing you to understand more, more accurately, and more deeply. Most Hadoop experts, in fact, have only read the source code and are already able to publish books. In reality, many companies just run some very simple, mature mining algorithms; iQiyi's engineers do linear regression just enough to be practical; most companies are still processing logs. Sometimes thinking of a brilliant algorithm isn't as important as switching to SSDs. So if you don't have that environment or those conditions, you just stop researching? I don't think so.
Regarding making money, I think as long as your interest lies there and you can do things well, money will come on its own. If your income doesn't go up, it's often because what you're doing isn't in the high-income bracket; writing programs rarely makes you rich. To be honest, one day of an escort's spending might be several times your salary, not to mention the escort's income. If you want to have a wild time at a nightclub and don't order two bottles of Louis XIII, the hostesses might even call you a fake rich man. If you don't send the red, blue, or green flower bouquets you fancy, you'd be too embarrassed to go back with her to the apartment complex or hotel to discuss genetic algorithms.
So the ones discussinggenetic algorithmswith escorts—Boss Wang and Engineer Li—their incomes are even less comparable to a programmer's.
So don't be too deliberate about linking writing programs to making money;it limitsyour ability to make money.
Source:http://www.cnblogs.com/foreach-break/p/be_a_real_programmer.html