1. Take time to read two books on software engineering every year
Every time I spend time slowly and carefully reading software engineering books recommended by others, I get improved. By reading carefully, I mean taking notes, talking with others, writing and drawing, hands-on attempts, and going back and reading again.
I hope I read software-related books in the first few years of becoming a developer. But I only started to do this around the 5th year of my career. Books such as "C# In-Depth", "Clean Code" and "Javascript: The Good Parts" all helped me improve my skills. I'm not recommending specific book titles—some of them are outdated anyway. My suggestion is to look for books that are more in-depth than your current knowledge, which can be books on specific technologies or software engineering practices.
I don't know how to read these books. Actually, I watched very slowly. I usually sit down and read only one or two chapters at a time. When reading, I will take notes or draw out the key points; after reading, I will review and often discuss with others. I also started writing some book reviews on my personal blog.
Mainly to reflect on what I learned. In the past few years, I developed these habits. These habits helped me grow quickly as a technical manager: they are also very beneficial to engineers. Looking for a list of recommended books? Here is a list of books that I have read and are currently reading.
Why are books better than blog posts, videos or speeches? In fact, I think books are better than the others combined. No matter what the subject content, compared with books, other formats will be superficial. The knowledge in the books is deeper and well organized. I only need to spend a few hours to write a post like this one, but I have spent almost a year on this book on the growth of software engineers that I wrote. I think reading can digest knowledge more slowly but deeply.
Don't be too greedy: reading a book every six months is great. Pick a good book and spend more time reading it. After reading a book or two, I also recommend that you read "How to Read a Book: A Classic Guide to Smart Reading", which is highly recommended.
2. Master the main programming language in your work and learn the bottom layer
When I first started, I mainly used PHP, and I also wrote some elementary JavaScript. I learned C and C++ in university, and I didn't like them. My first full-time job was C#. I know many languages, but none of them is very good.
Two years later, I started to have some troubles and had to ask senior developers for help when debugging C# code. One of them is a senior engineer who always helps me debug programs. He seems to know the language very well. He recommended a book "C# Deep Learning" for me to read. Then I watched. I learned threading, garbage collection, and generic working methods all the way. These are the low-level knowledge. I spent countless hours to understand covariance (covariance), inverse variance (contravariance) and other difficult topics.
One of the best decisions I have made is to study the main language of my work. In my first job, this kind of research was done unintentionally, and I had to rely on the senior engineer's guidance; however, this knowledge became an advantage in work and when interviewing for other jobs. In the latter part of my career, I deliberately delved into new languages and frameworks. I joined Skype as a C# programmer, but we need to switch to JavaScript and WinJS. Therefore, I learned JS in depth and mastered WinJS so that I could start a course on Pluralsight.
The more languages you know, the more you understand their strengths and weaknesses. When I moved to iOS, I was already proficient in several languages. When Swift appeared, I simply followed and participated in language discussions, and suggested adding the ability of reading and writing reflection to the future planning of Swift. After understanding the characteristics of the language, it will be easier to figure out the best strategy for my team to migrate from Objective-C to Swift. And, the more languages you know, the easier it will be to master a new language-and learn more easily when you need it.
3. Pair programming with others
I think pair programming has become obsolete recently. When we started, the long-term paired Extreme Programming, Test Driven Development and mob programming were all popular. After pairing up with someone, I got some of the biggest jumps in my career. These jumps are more important than reading.
I once had an unforgettable pair programming experience with a developer. He conducted a rigorous code review on everyone including me. One day I was fed up with the comments on the code review tool and decided not to reply on it, but to sit next to these commenters and ask them to explain their comments to me. I eventually learned a lot—and also told them that I thought their comments were unfair. They noticed this and suggested that I pair programming whenever this happens. Then I did it. This developer knows something about performance. I learned about the ins and outs of potential performance bottlenecks by pairing programming with him-and then I taught them about maintainability in return.
The test-driven development experience with another engineer is another fond memory of my pair programming. We take turns writing code and testing code. We did it for two days and realized a tricky part of the system. That experience really opened my eyes. In the process of verifying all boundary values, we even completely changed the implementation method in reverse. We also established a strong bond with the developer and lasted for several months.
4. Write unit test cases and run them in continuous integration
Senior engineers often talk about the importance of unit testing. But unit testing seems too counterintuitive: Why spend more time writing tests that seem simple? This is my opinion on unit testing at a certain time.
In order to appreciate the value of unit testing, you need to have the "Aha!" moment -when you write a unit test that saves you a day, that is the "Aha!" moment. Before reaching this step, you need to be down to earth, write these tests well, and make them run in continuous integration. Moreover, you may need to do it for several months before you get an "Aha!" moment.
I have two such moments. The first happened when I was building a back-end engine (as an auxiliary project) for a small online casino. The API is managing real money, and I covered all the code with unit tests because I was afraid of making mistakes. The project was delivered later than I expected-partly due to testing, which took a lot of time. But this is correct. I handed over the project to the client at the end of the contract. Two years later, they told me that these tests saved the team many times-if it were not for the failure of the test, the code vulnerability would spread to the production environment.
My other "aha" moment is building Skype on the Web. We created a new competitor for Google Hangouts on web.skype.com. Our team is a strong team with complete unit coverage and strict integration testing. Three months after entering the project, the engineer decided to reconstruct the structure of the entire project. This is a very risky refactoring, and all of us voted against it.
The engineer pointed out that based on the existing test coverage, this refactoring should be a piece of cake. As long as the test passes, the refactoring will be fine. I doubt it. But this is exactly the purpose of test cases. After a week of reconstruction, he promoted a huge change...everything was not interrupted, not at the time, and not since. All tests passed. At that moment, I realized the safety guarantees provided by a powerful set of test cases and the fact that it can make us not afraid of refactoring.
5. Develop refactoring habits and master refactoring tools
For many years, when I worked with the team, I tended to make the smallest possible changes in the code base. For my own personal projects, I have done a lot of refactoring-but I never do this kind of thing on a code base that I do not fully control.
Then, I met an engineer on Skype who would continue to make small or large refactorings. They all make sense, and the code always gets better. And they never mess up things. How did they do it?
When I paired programming with them, I found that they knew their IDE very well and added plug-ins for refactoring. Extracting method, changing the name of the quantity, extracting to constant... they only need a second.
I realized that I was afraid of refactoring. I missed both the practice and the tools that could help me refactor. So when I started to develop the habit of refactoring once a week, I improved in both aspects. This habit helped me a lot later-how I wish I had started doing this many years ago.
6. Learning good software engineering experience, which has benefited me a lot
When I first started as a software engineer, I was fooled by senior engineers. They saw mistakes that I didn't see, they knew the answers I didn't know. I thought they were smarter than me and accepted all this.
Now, I have worked closely with many well-known software engineers and served as a mentor to several others, and I found it not that bluffing. The best software engineers will combine the knowledge they have learned with practical experience-knowledge, you can learn; experience, you need to practice.
Look for opportunities to work in different technology stacks, different fields, and challenging projects. It took me seven or eight years to reach what I think is the "advanced" level. I saw some people join a high-growth company like Uber, and it took three or four years. What is the difference between this? These people work on challenging projects, try to keep up with others around them, and often change teams halfway through and start over. They voluntarily participate in new projects and are the first to try new technologies in the team. Although I eventually became such a person, it was later, not in the first few years.
7. Teach what you have learned to others
The best way to learn certain things is to teach them to others. I found this by accident. In 2010, I started to make presentations in the .NET and Windows Phone user groups. My speech was not effective, but I learned a lot in the preparation phase.
Now, when I want to learn something good, I sign up for a public discussion. One year after joining Uber, I offered to give a speech on how Uber rolled out backend changes on a large scale in 2017. At the time, I did not fully understand how we did it-before that, I was mainly engaged in mobile development and managing a mobile team. Through the lecture, I have no choice but to learn all the details. I’m under pressure to do this: about 100 local developers have signed up to listen to my talk.
Many others also said that this approach is effective-Shawn "Swyx" Wang is an outstanding representative of the #LearnInPublic approach. His growth story is far more impressive than my experience: After changing his career, he took the position of senior engineer at Netlify and AWS in four years, and wrote a book about his learning experience. You will only benefit by teaching others. Not only can you learn through teaching, but you can also help and inspire others.
And all the experienced model developers I know are qualified teachers and mentors. The sooner you start giving back and teaching, the more naturally you will become such a developer.