How to grow from rookie programmer to (pseudo) master
I recently had some colleagues who graduated recently ask me, "Do you have any tips for working? How can I become a master quickly? "
When I think about when I first joined the company and the newcomer training, I also discussed this question with other colleagues: how can I become a big player in the industry? At the time, I just thought that interest was the best teacher, and I didn't think much about the thought process or anything.
It's not a short time since I joined the architecture department of microblogging platform, so I took advantage of the Chinese New Year to summarize my work since I joined microblogging, from being a half layman in internet development to being able to design some architecture, troubleshoot some problems and share some experiences, I have gained a lot and felt a lot, I also gradually realized the importance of ideas and methods, so I'd like to share them with you. It is divided into three main areas: learning, doing and thinking.
2.Learn to learn
Learning is undoubtedly one of the most important qualities of a programmer, especially in a rapidly changing industry like the Internet, where it is not too much to consider learning as a big part of the job.
2.1. Independent learning
Recently found that people around me do not want to learn, just every day they are tangled in the end what they learn good: simple no challenge, complex can not read; old technology fear obsolete, new technology no direction ......
Talk about their own experience after graduation, after graduation to a small company, the work is mainly to do some XX management system and other things, nothing challenging, but also with no technology, basically the front-end with an extjs behind a set of sql server on the solution. After a few years of steady work, with nothing else to do in my spare time but wow, I thought it wasn't a good idea to be so idle, so I spent the year after that learning these things in my time at work groping and off work.
I was bored and wanted to make a small game, and found that most of the game related books are in English, so I couldn't read them, so I translated the first few chapters of "Real-time rending 3rd". After translating a few hundred pages of English books, I found that I had no more obstacles to read English books, so I started to spend my daily breaks and groping time reading books. After reading the game engine book, went through the code for the irrlicht engine and then cottaged myself a 3d rendering scene manager and a plain rendering engine. Writing an interpreter for my own game engine based on a scripting language, for which I read a lot of books on compilation principles and virtual machines to understand what the program is actually about, was one thing I found very rewarding. When I read the compilation principles book, I found that my knowledge of operating systems was a bit lacking, so I went back to the linux kernel related books. After that, I bought a development board and modified the kernel every day to play with it. After graduating, I once again learned about the kernel's cpu scheduling, memory management and file system, and how applications run on the OS and how the OS runs on the hardware, which is also a very rewarding thing. After reading the operating system and going through the network-related books, I read through the code of lighthttpd, wrote an http server under linux in c, and implemented several network programming models one by one. In the process of implementing the http server, I felt that my coding skills were still lacking, so I went through the code book, read the design patterns book along with it, and redescribed each pattern in words with my own understanding. There are many more language and framework related books in between, too many to list. You can refer to it here. I have divided my studies into three categories.
For work, knowledge necessary to meet the current job For advancement, knowledge related to the current job (depth) Expanding horizons, knowledge unrelated to the current job (breadth) After learning (1) is only a skilled worker, 2 and 3 is the way to improve yourself, along with the increase in knowledge base, it is easier to find similar knowledge to analogize when you are exposed to new things, speeding up understanding and making it easier to grasp the essence. If you are struggling with "what to learn" every day, then you are still learning too little. (I don't think the big bulls who really have nothing to learn are reading this ...... )
So, if you feel there is nothing to learn, then think about learning something more in-depth (like virtual machines or compilers), or something completely different (a new language or a current hot direction), or even something completely unrelated (simply practicing English reading, learning PowerPoint layout, etc.). As your knowledge base increases, your deficiencies and the direction of your future studies will become clearer.
In the case of microblogging, for example, there have been many twists and turns in the development of microblogging and the current system architecture has gradually been derived. The most popular question that many newcomers ask is "How do you do it online now? "
That's a good question, but not good enough. In the programmer's world there are few "silver bullets" that can solve all problems, and the current approach will soon be replaced, so if you want to understand something, pay more attention to "how it got to be the way it is today". Learning to look at things through a developmental lens and understanding some of the lessons learned from experience will yield much more than just learning one thing or another.
So, how do you learn from history?
The company's internal database, wiki, etc. will have most of the old information, most of them are not too busy when you first join the company, these databases are simply endless treasures Departmental internal sharing, for example, when I first joined the company, I often go to listen to "microblogging XXXX architecture evolution" and other internal sharing Ask yourself more "why it is not so designed" Old employees remember the bitterness and bragging when more flattering a few _(:з" ∠)_
There are two extremes here.
Some people like to bore themselves, do not ask anything, which is inevitably not conducive to their own improvement; some people encounter problems and ask questions, which is also problematic, not to mention wasting the time of others, but more critically, this person to learn from others the wrong way of thinking, to learn from others is not a specific knowledge (to learn knowledge can be solved by reading a book), but to learn the way of thinking of others. But things like mindset are hard to learn through communication, and then I discovered a very simple way to learn: a mantra. A few examples to give you an idea.
"This is really two questions." "Is there a better solution?" "Can you give me an example?" "Can you give me a one-sentence summary?"
In addition to the mantra, many cattlemen will have very distinctive ways of thinking and principles of doing things. If you are fortunate enough to work with a great cattleman in the industry, then congratulations, as long as you communicate more, observe more and think more, then the speed of improvement will increase by several orders of magnitude.
Some people waste their time every day on things that have nothing to do with the problem itself, such as thinking about how to draw architecture diagrams when I want to design the architecture, deploying and testing the code several times before passing it after writing it, and wasting time on scanning logs when checking for bugs. People always have a limited amount of energy, and by wasting time on these things, the time to allow yourself to improve becomes less.
There is a misconception that "doing something meaningful" is not the same as "only doing what you haven't done".
For programmers, writing code is the basic of basic skills. Coding specifications, design trade-offs, and even smooth IDE shortcuts all depend on trial and error and accumulation over time, and are difficult to comprehend through a few books or a few days of training.
I have witnessed some people write code for a year and then start to do some small project design, and then can't wait to shift all the focus to design and even architecture, this kind of design and architecture without the basic ability to support the most can only be considered advanced masturbation, most of the waste without waiting for the landing, not very meaningful. Most of the reasons for this are that the design is "not good" or "not useful", like taking an advanced mathematics exam after reading the textbook once. (Schoolboys I was wrong ...... )
For example, a few years ago in the process of looking at design patterns, using qt to make a comic book reading application, the patterns can be used to try, of course, there are a lot of use of inappropriate places, it is these inappropriate places let me object-oriented programming and design patterns of thinking a lot deeper, how to weigh the flexibility and complexity also has a new understanding. After that there were a lot less detours in designing many systems, both in terms of timing and quality. If you were expecting "we'll talk about it when we use it", you'd probably have been screwed out of the project.
Use tools for things that can be solved with tools, and good tools save big time on more meaningful things.
The scope of tools is wide, such as various commands for linux, various systems within the team, smooth applications, and even bicycles for commuting to work. As long as it saves time and increases efficiency, then it's worth a try.
Here I list a few things that have substantially improved my efficiency.
Dual screen monitor Smooth keyboard google (not baidu!) Not bing! ) Apps on mac mac: idea, alfread, omnifocus, even synergy and istats menus and such that have little to do with development itself. I prefer to think of "using tools" as an attitude to life: whether I want to focus my life on something meaningful. If you agree with this, then think about the input to return ratio, it's still substantial.
(And of course, the gods who hack their own apps to not spend money are extremely dense ...... )
Time is the most valuable resource for all those who look to improve themselves, and there is no point in being efficient and not having time to do it.
There's a pretty widely circulated graph on the internet: the cost of bothering programmers. The truth is that my work day is very fragmented, and when I arrive at work I may be constantly answering phone calls, being asked questions, being pulled into meetings, answering emails, etc.; and I am often confused about not having enough time or nothing to do, so here are some insights to share.
GTD can integrate many fragments of time. In addition to getting things done, it's also helpful to get things done together that are contextually relevant. For example, consolidate several things you want to do in other offices into one trip to complete. Reducing pointless time wasters, such as living by the office can save a few hours a day for studying or doing other things. (But if the time saved is spent tweeting, it's not necessary. ) Another interesting phenomenon: the registration fee for a software is just 10 or so dollars, more expensive hundreds of dollars, the cost of all the tools used in daily life can not add up to a kidney 6 expensive, but many people still adhere to the concept of no crack not used, for a few hundred dollars wasted a lot of time. Working overtime creates a lot of time and is effective in reducing the chances of being interrupted, but it can also be physically and mentally taxing. Therefore what is done overtime must yield more than enough benefit to personal progress. If overtime is only used for meaningless work, then something should be wrong with the routine. Things can be divided into four categories: urgent and important, urgent and unimportant, important and unimportant, and unimportant and unurgent, and it is important to have important and unurgent things in the todo list at all times.
When there is a problem that cannot be solved, many people will have the mood of fear or procrastination, the typical mantra is "let's just make do with it" or "let's do this first, we will study it later when we have time", most of those who say these words are not really that busy, and some even said to me while tweeting that they do not have time to study ...... (Are you fucking kidding me? )
To overcome intimidation is actually quite simple, find a specific plausible problem, find a way to work it out, experience the pleasure of solving it a few times, and build confidence.
Most of the problems are not really based on any high scientific principles, or even solved by flipping through a few pages of a book, but not digging deeper into the problems you encounter will, over time, develop the self-importance that these are the problems I understand and those I don't, blocking the path to your own progress instead.
When it comes to how to look deeper, there are also a few takeaways.
Think about why when things happen and ask why over and over again. Many seem to understand the problem after a while to rethink, often find that there are still not considered before the question to have a clear answer, philosophy and so on, do not dwell on Find information to choose the authoritative books or websites, to avoid being misled Find someone to discuss, or directly pull partners, not only to communicate with each other, but also to monitor each other Share your results Do not everything in depth, will give yourself too much pressure
There is a feeling at work in general that people who are in the habit of communicating and writing think a little more clearly and have access to more viewpoints. This area is actually among my weaknesses, so I'll probably summarize a few points.
It's a good idea to summarize your recent work in written form every once in a while, such as writing an insight or updating your resume on an ongoing basis There are two difficult points when writing: summarizing and abstracting what you want to explain, forming a main line with a unified point of view and a clear tone; and thinking from the other person's perspective to make things clear and avoid talking to yourself. You need to have a basically complete idea yourself before you get someone to discuss it, otherwise most of your time will be spent explaining the principles and such googling things that would be faster instead. The discussion should be followed by a conclusion that can be stated in one sentence and a clearly described point in time. Some people like to dwell on things like "this isn't my problem, why should I deal with it". It seems to me that this is a great opportunity. Why not gain insight, showcase the level and leave a good reputation for being serious and responsible.
Finally, I'd like to share a few words about what I understand to be the self-mastery of a programmer, which, in my opinion, can be summarized as: being responsible and valuing reputation.
Responsible, to be more specific: did you test the code you wrote, did you use the framework you made, did you weigh the architecture you designed carefully.
Reputation, to put it bluntly: there's no face delivering code that hasn't been tested, frameworks that haven't been used, or solutions that haven't been weighed.
With all of you. Original source. Enter link instructions Author. Enter link instructions