Ka Wai Cheung

How I work.

I hold strong opinions loosely but here are the few that keep tightening their grip over time.

The technical stack is one thing to me. I view design, the frontend, backend, databases and all the languages, tech, and tooling behind a product as one canvas rather than a stack that requires you to choose what to specialize in. I often bounce between multiple layers during a day of work to avoid the natural fatigue that comes from staring at the same thing for too long.

I prefer to work alone or with a team where each person owns a different part of the system. Collaboration gets in the way quickly. When teams get large, days full of meetings, time estimates, and rigid processes become necessities. They eat up all the time (and joy) that's left for people to actually make things.

I find planning, wireframing, and figuring out the little details of a new feature up-front to be a waste of time. I prefer a few conversations with the people I'm working with to figure out the big picture, then getting to building. It's motivating to build on the real thing earlier in the process. You often get to the finish line more efficiently and produce something better.

I use as few tools as possible and try to build my own, specific to what I'm working on. I'm an advocate for writing code generators to generate the tedious, yet trivial, parts of a codebase (Documentation, ORMs, CMSs, API wrappers, etc.).

I believe building a product is as much like writing or making music as it is engineering. It's a creative process. If you find an idea strike you when you're doing something totally unrelated, you ought to have the authority to run with it.

I prefer concreteness over abstraction in code. I avoid leaning too heavily on interfaces, abstract classes, generics, and similar concepts. I find the mental cost-of-carry outweighs the rarely-manifested promises of reuse, swappability, and elegance almost every time. Abstraction should be a last resort.

I think there is too much emphasis on (and idolization of) automated testing and TDD. There is too little emphasis on other “practices” that have a larger impact on ensuring safe code—like what to test, naming things well, proper encapsulation, and simply having less people churn on a product.