About
Welcome to my personal blog.
This site is where I write about software engineering, product work, AI applications, and independent creation. Many posts begin with real problems from real projects: why a page becomes hard to maintain, why an engineering plan grows out of control, why a tool fails to deliver the expected productivity, or how a product decision eventually changes the user experience.
I try to keep more than technical notes here. The decisions behind a solution often matter more than the solution itself. Frameworks change and tools get replaced, but the ability to reason about tradeoffs, boundaries, reliability, and long-term maintenance is worth recording.
Who I Am
I am skyADMIN, a frontend engineer who has spent most of his career building user-facing products and business systems.
My work has focused on frontend engineering, H5, mini programs, cross-platform development, automation, and engineering productivity. I am less interested in chasing every new framework for its own sake, and more interested in whether a technical choice can support real product work: whether it reduces coordination cost, keeps the system easier to evolve, and improves both user experience and business outcomes.
In recent years I have also been following how AI changes software development. AI does not make engineering judgment less important. It makes context, system boundaries, data structures, and product understanding even more valuable. The clearer a system is, the more useful AI becomes as a collaborator. The messier a system is, the more likely AI is to amplify that mess.
What I Write About
This blog usually covers:
- Frontend engineering, architecture, and engineering practice.
- Mini programs, H5, cross-platform development, and complex user-facing entry points.
- Software development workflows, toolchains, and product forms in the AI era.
- Independent products, creator platforms, and personal website building.
- Work, cities, life, and long-term choices.
I prefer writing after practice rather than only summarizing concepts. Why a solution was chosen, what alternatives existed at the time, which assumptions turned out to be right, and where complexity was underestimated are usually more useful than the final conclusion alone.
Work Background
I have worked on frontend-related projects at Baidu, Didi, and Ant Group, mostly around user-facing product entry points, business systems, and engineering infrastructure.
During my internship at Baidu, I worked with early Vue, webpack, and hybrid development, and started building production features for user-facing services.
At Didi, I worked on WebApp and mini program entry points for core ride-hailing scenarios. I also participated deeply in team engineering work, continuous integration, and the Mpx mini program framework. That experience made it clear to me that the hard part of mini programs, cross-platform development, and frontend engineering is not only framework capability. Once the scale grows, the harder question is how multiple teams can collaborate under one reliable set of constraints.
At Ant Group, I continued working on frontend and merchant-facing products. Compared with pure consumer entry points, merchant products are often closer to complex business systems. They require repeated tradeoffs between efficiency, stability, permissions, workflows, and experience. This has shaped my view that frontend engineers should understand the full business path behind the interface.
These experiences led me to a simple belief: frontend work is not only about rendering interfaces or calling APIs. Valuable frontend engineering requires understanding the relationship between users, business logic, data, interaction, engineering constraints, and release processes.
Long-Term Interests
I keep returning to a few questions.
How can software engineering stay clear as complexity grows? Many projects do not fail because the technology is old. They become expensive to change because boundaries are vague, context is lost, and constraints stop working.
How will AI change the way developers work? It lowers the cost of writing code, but raises the bar for asking good questions, organizing context, and judging the quality of results.
Are personal websites and independent writing still worth the effort? Platform traffic is increasingly unstable. The value of a personal site is not only page views. It is also persistence, searchability, long-term access, and control over how ideas are expressed.
How can technical experience become reusable judgment? A debugging story has limited value if it only explains how one incident was fixed. It becomes more useful when it turns into a clearer understanding of boundaries, principles, and tradeoffs.
About This Site
This blog started in 2017 and has gone through several migrations and rewrites. It now runs on InkIsle, a static blog system I built for my own writing.
I keep maintaining this site partly because I want a stable place for long-form writing, and partly because it lets me practice my own view of personal content systems: content should stay portable, maintainable, and accessible over the long term, instead of depending entirely on a platform’s recommendation feed, account system, or editor.