How I became a better programmer
the Author, James long, one of the creators of the Firefox Developer ToolsSome people React Conf asked me for advice on how to program better. For some reason people see me as an advanced programmer, the advice is worth listening to. I thought I should record a "mental model" of how I came to programming through the years.
Some information: I am 32 years old and 10 years of solid experience. Probably only in the last couple of years I have gained confidence in what you do. But even now, I continue to doubt myself. The fact that this feeling never goes away, so try not to pay attention to him, keep hacks and gain experience.
I must say that here are just a few tips to improve their abilities. As a result, you need to figure out what works best for you. It's just those things that I have found to be useful.
the
Look for people who inspire you, but don't idolize them
Over the years there were a lot of people I watched with respect and followed with new technologies. I learned a lot just trusting their opinion and learn things that they're working on. As a rule, these people were very productive, bright and inspiring. Look for them and let inspire and teach you.
However, they do not need to worship. From the tape of Twitter's easy to look terrible, but if you look at how they work in real life, you will see that they are not as outstanding. Everywhere hacks, etc. we are All just experimenting. Finally, do not trust them blindly; if you do, that attract attention and get the experience of chatting. Some of my most productive conversations have happened that way.
My Emacs config in a mess. I don't know why I have broken autocompletion OCaml (over a month). I don't automatisera things and sometimes have to delve into the history of the shell to find the commands. First, I'm writing the ugliest code. I placed everything on the global object are not yet aware of what they are doing. Even the most skilled programmer consistently uses hacks; most importantly — to bring the case to the end.
the
don't knock your work
Beginners often think that their work doesn't matter, because they're new. Or maybe you are an experienced programmer, but I work in a new area where you didn't feel comfortable. In my opinion, some of the best ideas are offered by newcomers. They see the opportunity to improve existing things, which is familiar to the experienced people with an established opinion.
Your work always has value, no matter what. In the worst case, even if your idea doesn't work, the community will have a better understanding why this approach does not make sense. (Note to community: from our side, please keep this in mind and be friendly to newcomers).
the
No need to force yourself to work all the time
When new technologies come out every day, the impression is that you will lag behind the world, if you miss the evening without work. This is not so. In fact, you will work better if permanently disabled. The look will be fresh, and I myself subconsciously come up with new ideas when I'm not working.
Most of the daily new — just old ideas in new packaging. Do revolutionary things appear every few years. A good lecture on this topic — Hammock Driven Development.
the
don't be distracted by tinsel
One of the best ways to objectively approach — just ignore the "tinsel" which in reality will not improve your skills very much. In other words, competently distribute their time. In the day a certain number of hours, and if you spend them on more profound things, eventually you will notice a big difference.
So what "tinsel"? Depends on you, but can you give some examples of what I consider the tinsel: the syntax of languages, APIs, libraries, configuration build tools. Learning a new syntax of the Assembly ES7 JS doesn't make you a better programmer compared to the study of compilers, for example. The use of a new library that implements the same idea, but with the new API, not so interesting. All of this is important of course, but I recommend to spend more time learning the deeper concepts that will effect for years to come.
I like to ask this question: do you most of the time to make the code "beautiful"? If so, I recommend not to pay it much attention. Your code will still change dramatically over time. It is better to focus on the root problems that you face, and to think carefully about levels of abstraction. When dealing with this, you can spend a little time polishing the code. (This also applies to the DRY principle. Don't worry too much about it. Don't hesitate to repeat information at levels of abstraction.)
the
Examine past research
If you are concerned about some idea, can't wait to sit down and immediately begin. Can't do that without doing at least a cursory study of how others have solved this problem before. After several days of study tasks I always completely changed the intended way to solve it.
A very valuable quality to learn how to read scientific articles. I know nothing about denotational/operational and other semantics, so that many articles can't read. But many code is used instead of mathematics, and to read them is not very difficult. Just giant the amount of knowledge accumulated in articles over the past 30 years. If you learn to extract it, it will be a real opinion leader almost instantly.
Prettier is a great example. I knew that I want to, but in didn't understand how. After a short search I found this article and after a few days knew exactly what to do. A week later there was a basic working prototype. If I had ignored previous studies, all would have taken much more time.
If you need scientific articles, the GitHub repository Papers We Love is a good place to start.
the
Handle large projects. Feel the discomfort
There is nothing better than experience. Not everyone has the opportunity to experiment, but if you have time, then try and get big projects. Don't even need to finish. Just trying to overcome something like writing the compiler will give you a lot of new knowledge in the first week.
Honestly, I hate the feeling when you have no idea how to solve a complex problem. It's an unpleasant feeling. Understand that you have to learn a lot of material and much to understand, to get a little closer to the solution. But I always eventually become a much better programmer.
Start with learning a new language. This is the most effective way to force yourself to get out of the cycle of your current habits and look at things in a new light. For me the best thing I did in my youth, and was studying Scheme. This extremely simple language to write makes you write everything in functional style, and really learn the basics of how the code works. A few years that I have spent on the Scheme, still be to my advantage; my view code has changed fundamentally. (I even named my company Shift Reset LLC name operators shift/reset in the Scheme).
Here is a list of a few things that I would recommend to do. They all had a huge impact on my career. Most of them still continue to benefit indirectly and help me mentally to dismantle new ideas. You don't need to do it to become a good programmer, there are many other ways to do this, but it helped me personally.
the
Examine C − Just the basics, if you don't know them. I think it's important to understand why all complain about it.
Write the compiler − Probably the best way to feel discomfort and learn new knowledge. Take a look at supercrazy compiler.
Explore macros − View Scheme, Lisp or Clojure (Script). The macro really will change your view code.
SICP − SICP ("Structure and interpretation of computer programs") — it's an old book, which I think is still relevant (some disagree). It requires very little programming knowledge from the reader and leads you all the way to the creation of the computer with obvious management and a compiler. Another book that I really liked and which plunges much deeper into the compilers, Lisp In Small Pieces (in Russian translation — "the interpretation of the Lisp and Scheme").
Get continue − Continue is a low — level mechanism of program order. Scheme is the only programming language that implements continuation, and while you never used them in, they will change your view about the order execution. I wrote post, trying to explain to continue.
If anything, just try a new language − no Matter what you do, really should learn new languages. I would recommend any of the following: Clojure, Rust, Elm, OCaml/Reason, Go or Scheme. All of them have unique functions, and they will force you to learn a new way of thinking.
