The Monster-Slaying Road to Leveling Up in Software Development

Many newcomers to the field share the same bewilderment: I’ve just finished a course in language X (or taught myself language X) — what should I learn next to reach the level where I can build a real product?

There are many ways. Let me talk about my favorite, and the most brutal one — take the skill you’ve just acquired and go build a product with it, hands on.

There are two paths: (1) join a team that builds products with that skill; (2) build something yourself.

Path (1) is always the best choice at any given moment. A group of people exploring together (especially when some of them are more advanced) is the most efficient arrangement, and you’ll grow the fastest. But in this world it often happens that the gentleman is willing while the lady is not — the team you admire may not think much of you. When that happens, (2) becomes the only option.

But I don’t even know what I should build — what then?

Let me give you an example — you can use it as practice, or follow the same line of thinking to imagine other “products” that mean more to you.

The example comes from a few days ago, when someone in the comments wrote the idiom “血脉喷张” incorrectly. I corrected it to “血脉偾张”, and then someone corrected me in turn, saying it should be “血脉贲张”. Later I looked it up on Baidu Baike: both “血脉偾张” and “血脉贲张” are correct. That got me thinking: could I build a product that automatically corrects the idioms in an article?

That’s a big problem, and there are plenty of pits to fill in along the way. Often, the same outcome is far less difficult if you ask the right question. So let’s tweak the problem a little: could I build a product that automatically completes idioms as the user types?

Now it’s much simpler. That already satisfies 80% of the need.

Let’s break it down further into a problem a beginner-level programmer can understand.

(1) Get a lexicon containing as many idioms as possible.

(2) Read the lexicon in, and store it in a particular way that makes scanning easy.

(3) Based on the user’s input, do the matching and completion.

For (1), the simplest approach is to export the idiom dictionary from some input method (you may need to do some filtering first). For (2), you might build a prefix-matching tree. For (3), recommend the results that satisfy the prefix match to the user.

This isn’t hard to solve, so I won’t go into the detailed implementation. Next you can consider these questions:

(1) How can you further improve matching speed and precision? (Is there a better algorithm?)

(2) If you wrap it as a Unix service, how would you do it? (For instance, make matching and recommendation into a service that listens on a TCP/unix domain socket, so that local — or even remote — processes can access it.) What protocol would you design to govern client and server?

(3) If you wrap it as a web application, how? How do you achieve an effect like Google suggest?

Some people think (2) and (3) are much the same; in fact they differ a great deal. For (3), every HTTP request is an independent request, with no state shared between them, so you can’t just use an already-loaded lexicon the way you can in (2). But loading it on every request is very expensive. So you either reuse the output of (2), or you spin up a cache service (like Redis) and load the lexicon into it in your storage format.

Once you’ve walked through all this step by step, you can ask yourself more questions:

If the user is typing continuously rather than entering a specific idiom, how do I recommend completions? For example, given “顿时感觉血脉” (“suddenly I feel blood…”), can I recommend “贲张”?

If you’ve solved that too and still have energy to spare, you can explore the next question: could I build a product that automatically corrects the idioms the user enters?

Correction and completion are two different concepts. Correction is a lot harder. For instance, if the correct idiom is “血脉贲张” and the user types “雪脉贲”, can I recommend “血脉贲张”?

Or, back to the original — and possibly hardest — question: could I build a product that automatically corrects the idioms in an article?

I won’t analyze them one by one. If you can dig deep into the example above and produce a solution, I believe BAT (Baidu, Alibaba, Tencent) will be happy to have you on board.

This example is only meant to throw out a brick to attract jade. It may not be to your taste, but I believe that in daily life you can always find plenty of similar problems that you think are worth spending time on, solving them the programmer’s way. They may start out as very big, very hard problems, but as long as you simplify them bit by bit (using recursion, divide and conquer, and other techniques) and keep thinking, you’ll eventually find a problem that suits you to implement, implement it, and then trace back up layer by layer. You’ll feel that sense of achievement that comes from grinding monsters and leveling up.

But one thing you must keep in mind: if a problem already has an answer, you may learn from it, but don’t copy it. Others may already have solutions to the problems above, but those are the fruit of their own thinking and practice. You can copy-and-paste a hundred times, and it still won’t be worth a single thought, a single exercise of your own.

So: find a problem, dig deep into it, and (preferably together with others) seek a way to solve it. That, in my eyes, is the monster-slaying road to leveling up in software development.