I've been building software for a long time, across quite a few different areas.
I started with C++ and game development, later worked on network services, mobile apps, backend systems, infrastructure, and product development. From 2016 to 2025, I was a technical partner at a startup in Shenzhen, where I was involved in engineering management, product work, backend architecture, and DevOps.
These days, I'm spending more time exploring independent projects, new tools, and different ways of building software.
I'm less interested in identifying myself with a particular programming language or platform than in understanding the problem and choosing the appropriate tools to solve it.
That mindset has taken me through very different parts of software over the years, and it still shapes how I approach new projects today.
A few things I'm currently interested in:
- AI agents for complex software development
- AI-assisted engineering workflows
- Software architecture and developer tooling
- Independent software products
- Product and interaction design
- Native desktop applications
- Backend systems and infrastructure
- New ways to turn ideas into working software faster
Most of these are driven by curiosity rather than a fixed career direction.
I like side projects because they give me room to explore things outside my main work.
Sometimes that means trying a new technology. Sometimes it's experimenting with an interaction model, rethinking an existing product, or simply building something because the problem feels interesting.
KeyTiler is a native macOS window management utility I'm currently building as a side project.
It's an experiment around:
- fast window management
- keyboard-driven interaction
- Swift / SwiftUI
- macOS Accessibility APIs
- native desktop UX
- independent software distribution
The interesting part for me isn't just implementing the features, but also thinking through the interaction model and how a small utility should behave.
I originally created ShadowsocksX-NG in 2016 and have been its primary contributor and maintainer over the years.
The project started as a new implementation of ShadowsocksX for macOS. It simplified the original architecture, moved the GUI to Swift, and separated the proxy process from the application itself.
Nearly a decade later, software development is going through another major shift.
As large language models and AI coding agents have become capable enough to take on increasingly complex engineering tasks, I decided to revisit ShadowsocksX-NG and explore what rebuilding a mature application looks like in this new environment.
I'm currently working on a new implementation using a modern technology stack.
This isn't just about rewriting an old application with newer tools. It's also a practical experiment in using AI agents for complex, real-world software development — working across architecture, implementation, debugging, refactoring, UI design, and the many small decisions involved in evolving an existing product.
For me, the project is both a continuation of something I started in 2016 and a way to explore how the role and workflow of a software engineer change when AI agents become active participants in the development process.
Over the years, my work has moved through a fairly wide range of technologies.
I spent a lot of time with C++ in earlier years, including game engines, MMO server systems, network programming, P2P software, and desktop tools.
Later, my work shifted toward backend systems, product development, and infrastructure, using technologies such as:
Go · Python · Node.js · TypeScript · Java
PostgreSQL · Redis · MySQL · Kafka · RabbitMQ · NATS
Kubernetes · Istio · Prometheus · Grafana · GitLab CI
I've also worked with native iOS and Android development, React, Swift / SwiftUI, Qt, WPF, and quite a few other tools along the way.
I don't try to keep a complete technology checklist anymore. Most tools are useful for a period of time, and the interesting part is what you can build with them.
I tend to care about a few things consistently:
Keep the model clear.
Complex systems become difficult to maintain when the underlying concepts are vague.
Use the simplest tool that fits the problem.
Architecture should reduce complexity, not become a source of it.
Product and engineering are connected.
A technically elegant solution isn't very useful if the interaction or product model is wrong.
Small details matter.
This is especially obvious in tools people use every day.
Keep learning by building.
I usually understand a technology much better once I've used it to solve a real problem.
My work has moved through a lot of different layers over the years:
desktop software → games → network programming → mobile apps → backend platforms → distributed systems → infrastructure → product development → independent projects
The stack keeps changing, and that's part of what makes software interesting.
I still enjoy the process of taking something vague, turning it into a concrete system, and gradually making it work better.