I put this together from an interview I did at an architecture conference. The questions themselves were fairly gentle, so what follows is less a dramatic interview and more a整理 of how I think about writing, programmers, and the direction this site has taken.
How CoolShell began
I started writing online in 2002, before the word “blog” had really become common. At the time, I didn’t have my own computer, internet access wasn’t convenient, and I had a habit of taking study notes. I wanted a place to store what I learned from books and work so I could pull it up from anywhere, especially because my job involved a lot of travel. There happened to be a feature on CSDN called an “expert column,” which was basically what blogs later became.
When blogging platforms became popular, those columns were moved over to CSDN’s blog system. Around 2007 to 2008, that platform had become painfully hard to use. Performance was terrible, downtime was frequent, uploading images was annoying, and posting code was equally unpleasant. Maybe that was just what came with using .NET and Windows—just kidding.
I started CoolShell in March 2009 for three very practical reasons:
- I needed a more stable and convenient place to write, somewhere my own style wouldn’t get buried under a generic platform style.
- My wife, who works in journalism, really disliked my old technical blog because she thought it was too dry and too bookish.
- I had come across a site that curated entertaining material from abroad, and I was already spending about two hours a day reading foreign technical communities.
So I rented a server myself for 4,500 RMB a year and built CoolShell.
That also explains why the site looked the way it did at the beginning. Early on, it had a stronger entertaining side. I collected interesting things happening around programmers, along with opinions and observations from different corners of the programming world.
My original plan was simple: very technical material could still be mirrored elsewhere, while the lighter and more relaxed content would live on CoolShell. I wanted to show that programmers are not a dull, wooden, socially detached group with no sense of humor. The programmer world has plenty of interesting culture inside it. If you look at the site before early 2011, you’ll notice a lot more playful language, teasing, and internet-style joking.
Why the site changed after 2011
Around the beginning of 2011, something shifted.
The readership grew, and with that growth came pressure. More and more people were no longer just dropping by for amusement. Some were treating the site as a place to improve themselves, broaden their perspective, and even look for guidance. Once that happened, I couldn’t keep writing in a purely entertaining mode. If people were reading seriously and expecting to get something useful from the site, then I had to take that responsibility seriously too.
That’s why the tone and content gradually became heavier, more deliberate, and more demanding of my own time.
There is no secret formula for running a personal blog
If you ask me what the secret is to making a personal technical blog stand out, honestly, I don’t think there was any grand strategy. It happened naturally, almost by accident.
There are countless technical blogs. CoolShell was never the strongest in pure technical depth, and it wasn’t the fastest source of news either. Many team blogs from large companies are very good. So are a number of well-known independent blogs, along with large technical communities and publishing platforms. If I wanted to matter, I had to do something different—something those communities and blogs were not really covering.
The weakness of many large communities is that they often resemble schools obsessed with accumulation: collect more articles, gather more knowledge, keep feeding users in bulk. The editors may not really understand technology. On the other hand, many technical blogs have the opposite problem: they understand technology perfectly well, but they are too technical. They contain only technology, and leave out programmer culture, perspective, and worldview.
Programmers are not just a labor category. They form a circle, almost a small society. That circle doesn’t contain only code and knowledge. It also contains frustration, pride, values, conflict, identity, and shared habits. Programmers often talk about how hard they work, how little respect they receive, and how their voices are absent from discussions about agile methods, processes, or products. There are also topics that belong very much to programmer culture itself—arguments over programming languages, for example. Those could be meaningful cultural discussions inside the profession, but too often they collapse into pure abuse.
Someone needs to help steer those conversations and encourage programmers to examine them with healthier values and clearer thinking.
That is where I see CoolShell as being different. I care not only about technology, but also about the culture and mindset of programmers. I also put forward values that may be stubborn, sharp, personal, or even radical. You may agree with them or reject them, but at least what you see there is real. The site is real, I am real, and the discussions are real.
Why I wanted to move from low-level technology toward business-facing work
I had spent too long doing low-level work.
At some point, staying only at the bottom of the stack starts to make you too bookish. You can become less comfortable dealing with people, and a little too far removed from ordinary reality. I wanted to know how users actually use our products. I wanted to know how they think. If all you do every day is tune network performance, tune system performance, work on multithreading, and dig around memory bugs, it can start to feel like you’re spending your life drilling tunnels underground. Eventually, you want to come up and see daylight.
That does not mean I think business and users are automatically more important than technology, and it definitely does not mean technology is useless.
I think of it like a tree. Low-level technical foundations are the roots and trunk. They let you stand very firmly; they let you survive floods and storms. But if you want to grow taller and wider, you also need branches and leaves above ground. I felt my low-level foundation had already gone deep enough. What I needed next was a better understanding of business and users. I don’t just want to stand steadily and root deeply; I also want to stretch upward.
How the writing happens, and why the posting pace slowed down
I read every day, especially material on the web, usually about two hours a day. I also like thinking. Whether my thinking is always correct is another matter, but I genuinely enjoy working through ideas. On top of that, conversations with friends and interactions online often trigger new thoughts.
That’s where the articles come from: reading, exchanging ideas, and then thinking things through.
Before early 2011, I averaged about three posts a week, and sometimes as many as ten in one week. Now it is basically one article per week.
The reason is simple: the nature of the writing changed. The earlier pieces were more entertaining and didn’t take as much time. The newer ones take much longer. One article, a guide for programmers leveling up, took me four weeks. Another article on performance tuning took more than three weeks. In general now, even a normal article usually costs me at least one or two full days.
I’d rather reduce the number of posts and think more carefully and more thoroughly, so the writing carries more substance.
Advice for younger developers
If I were to give a few pieces of career advice to younger people or to those just entering software development, these would be the main ones.
- Don’t chase every new technology. Spend more time studying technologies that have survived for a long time.
- Study history and the evolution of technology. That is how you begin to see where technology is going. Many things we consider new today have older reflections. The relationship between mobile or cloud architectures and the old Unix-plus-terminal model is one example. Pipes and Unix design philosophy also continue to echo in today’s service-interface style design.
- It is fine to be pragmatic when solving immediate problems or catching up with trends. But if you want to become an expert in a field, you must care deeply about fundamentals. Quick-fix programming may turn you into labor, but not into a craftsman, and not into someone who can truly command technology and knowledge.
- Don’t let vendor culture define your entire view. Pay more attention to community culture, especially Unix and C culture. That is where much of computer culture has its roots.
- Focus on fundamentals. Breadth is a byproduct of depth.
What an architect really is
My view of the “architect” role is fairly plain: architecture is part of design. It is one piece of software design, and good software design depends above all on two things:
- analyzing both functional and non-functional requirements,
- and having a deep technical foundation backed by substantial experience.
Now ask yourself: can programmers build software without design? And if there is design, can there be no architectural design involved? In practice, engineers and programmers are already doing architecture-related work all the time. So to me, architecture has always been part of a programmer’s job—more precisely, part of a senior programmer’s job.
That said, in some situations I do think dedicated architects are necessary. But the right kind of architect must understand both the business and the technology, lean technical, and still write code. In some companies, where the whole organization needs a coherent overall design and a shared framework across multiple engineering teams, it makes sense to have a group responsible for that. Even then, those people should stay close to frontline engineering teams.
So in my mind, an architect is a senior programmer, not someone who waves their hands, talks big, and never actually builds anything.
If you want an example, just look at the teams responsible for Linux architecture. They still write code, still fix bugs, and still need to understand the wide variety of demands different companies place on Linux.
Is CoolShell written by one person?
No, not entirely.
I’ve always hoped it could be a place written by many people together, and in fact some others have contributed, just not that many. The bigger issue is that my own personal style is too strong. My personality tends to overshadow the group voice.
As for whether everything is written by me, whether there is a team behind it, or whether someone else ghostwrites—honestly, I can’t prove any of that to everyone, and I don’t care much to. What matters is whether the articles are useful to readers and whether they contribute something to the community.
What I want the site to become
For now, the site still carries a strong cultural and value-driven side, and in the short term it will probably continue to be shaped mainly by my own voice, even though I do want it to be a place where more people can share.
Some time ago I had an idea for what I called a “programmer vaccine station.” The metaphor is simple: just as vaccines given at birth help us resist different viruses, such a site could help programmers develop immunity to common low-level mistakes. I haven’t fully thought it through yet, but the direction is roughly there.