Programmer’s dilemma

https://medium.com/i-m-h-o/231d7499a75

Recently I interviewed tens of candidates for a kernel programmer’s position. These candidates are from big, good companies, which are famous for chips or embedded OS/systems. Many of them claimed they have at least 10 years on-job experience on kernel. Their resumes look fairly shiny — all kinds of related projects, buzz words and awards…

But most of them cannot answer a really basic question: When we call the standard malloc function, what happens in kernel?

Don’t be astonished. When I ask one of the candidate to write a simple LRU cache framework based on glib hash functions, he firstly claimed he had never used glib — that’s what I expected — I showed the glib hash api page and explained the APIs to him in detail, then after almost an hour he wrote only a few lines of messy code.

10年kernel工作经验的内核技术专家，但是却不能够回答比较基本的问题。

Why did this happen?

The more I think about it, the more I believe it is caused not only by themselves but also by the companies they worked for. These companies usually provide stable stack of code, which has no significant changes for years. The technologies around the code wraps up people’s skills, so that they just need to follow the existing path, rather than to be creative. If you happened to work for such kind of code for a long period and did not reach to the outer world a lot, one day you will find yourself to be in a pathetic position — they called you “EXPERT” inside the team or company, yet you cannot find an equally good job in the market unfortunately.

This is so called “Expert Trap”. From day to day, we programmers dreamed of being an expert inside the team/company; however, when that day really comes we trapped ourselves. The more we dig into existing code, the deeper we trapped into it. We gradually lose our ability to write complete projects from scratch, because the existing code is so stable (so big/so profitable). What’s the worse, if our major work is just to maintain the existing code with little feature development, after a while, no matter how much code we’ve read and studies, we will find we cannot write code — even if the problem is as simple as a graduate school assignment. This is the programmer’s dilemma: we make our living by coding, but the big companies who fed us tend to destroy our ability to make a living.

过于依赖原有的环境以及codebase,不能够独立完成项目以及缺乏从头编写代码的能力，循规蹈矩地完成事情缺少创造性。

How to get away from this dilemma?

For personal —

First of all, Do your own personal projects. You need to “sharpen your saw” continuously. If the job itself cannot help you do so, pick up the problems you want to concur and conquer it in your personal time. By doing so, most likely you will learn new things. If you publish your personal projects, say in github, you may get chances to know people who may pull you away from your existing position.

Do not stay in a same team for more than two years. Force yourself to move around, even if in the same organization, same company, you will face new challenges and new technologies. Try to do job interviews every 18 months. You don’t need to change your job, but you can see what does the market require and how you fit into it.

For team/company —

Give pressures and challenges to the employees. Rotate the jobs, let the “experts” have chance to broaden their skills. Start new projects, feed the warriors with battles.

Hold hackathon periodically. This will help to build a culture that embrace innovation and creation. People will be motivated by their peers — “gee, that bustard can write such a beautiful framework for 24 hours, I gotta work hard”.

对于个人来说，需要经常自己独立完成项目培养自己的编码能力，不要呆在一个团队超过2年以上（ #note: 这点我觉得有点道理。3年以内公司是在培养个人，所以个人发展收获相对更多; 而3年之后是个人为公司做贡献，个人付出相对更多 同时回报也会更多），不断接触更多的新技术。每18个月做一个面试，看看自己的能力是否有弱化。

对于公司来说，可以让员工做不同的事情来扩展能力，同时培养员工的创造性和积极性