Work Reflections

Experiences of Using AI

• Process Engineering around LLMs: AI productivity is less about using a single model and more about imagining workflows and building small tools around the model to augment yourself. Different designs and workflows are essentially process engineering around LLMs. By envisioning how AI can help with different tasks, I can build lightweight tools, such as sub-agents, skills, reference documents, and specialized bots, to amplify my software development workflow.
  • Build specialized AI bots: Provide prompts, source code, and existing documentation to the AI model to create the markdown files needed for the bot. This specific set of markdown files with an LLM becomes a domain expert I can ask questions.
• Debugging with AI: For debugging difficult instances like memory leak issues, I find it more effective to write comprehensive test cases and log sufficient information and stack traces to the syslog. With AI, rich logs can often speed up debugging much more than stepping through code with breakpoints.

Things I learned about Computer Science & Architectural Design

Many of these are skills I picked up before AI-assisted development. I learned many of them from our company's principal engineers.

• Break Down Questions, and Find Answers in the Codebase: The codebase is the most reliable source of truth. When I have a technical question but do not know how to find the answer in the code, it is usually because my question is not specific or small enough. I need to break the question into smaller, more manageable parts that can be answered by examining the code. A non-specific question is "How does this feature work?" More specific questions are "Where is the entry point of this feature?", "What are the key data structures involved?", "What are the inputs and outputs?", and "What issue does this feature solve?"
• Debugging: One effective way of debugging is to guess where the error is before looking closely at the code.
• Ask for documentation: If I need to ask my colleagues questions, I ask for documentation as well. If a colleague can solve an issue I am struggling with, there is often an information gap between us. Having access to documentation helps me close that gap and become more self-sufficient. It also protects my colleagues' valuable uninterrupted time.
• Build the Skeleton First, Even if It Could Be Wrong: Reading large amounts of documentation—such as during a project ramp-up—can be overwhelming. My approach is to first imagine myself as the system architect and think about how I would design the system. This gives me a mental skeleton. As I read, information that fits the skeleton gets absorbed naturally as flesh. Information that contradicts my design prompts me to revisit and refine the skeleton. This way, I can ramp up faster in unfamiliar areas.
• Don't Stop at the Interface: Follow the Logic to the Bottom: I used to focus only on understanding enough to finish the task. A system architect I greatly admire taught me to keep asking, "What is happening underneath?" and to follow the code down to its lowest level. He also constantly asked whether there were alternative ways to solve the problem. Practicing this habit has helped me eliminate unnecessary abstractions and write cleaner, more maintainable code.
• Embrace Contradicting Theories: Humans naturally seek consistency, but seemingly contradictory approaches to learning and problem-solving can both be valid at the same time.
  • Depth vs. Momentum: When encountering an unfamiliar concept, there are two equally valid approaches. One is to investigate it until reaching a fundamental understanding, tracing definitions and concepts all the way down. The other is to accept temporary confusion, continue reading, and allow repeated exposure to gradually build intuition. Both approaches work. Learning is not about always choosing the "correct" method, but about maintaining curiosity and momentum.
  • Master the Map vs. Explore the Territory: Sometimes I want to understand the entire architecture before moving forward. Other times, I explore the areas relevant to the task at hand and allow the broader picture to emerge over time. Both approaches are valid. Understanding often comes not from seeing everything at once, but from gradually piecing together information through exploration.
  • Software Design: Sometimes violating a principle in a specific place is the right engineering decision because it provides benefits elsewhere (performance, simplicity, maintainability, delivery speed, etc.).

Reflections on Communication

• Closing Communication Gaps: After I ask my peers or mentees to do some work, I ask them to explain in their own words what they understood from my instructions. This helps identify misunderstandings early on and ensures everyone is on the same page. Similarly, after receiving instructions from managers or senior colleagues, I usually say, "My understanding is XXX." This way, if I misunderstood something, it can be corrected early.
• Information Density: "State important things three times" does not literally mean repeating the same words three times. It means increasing information density, such as using a component diagram, a state machine diagram, and a sequence diagram to convey the same concept from different perspectives. If I draw the same component diagram three times, the misinterpretation may still remain. But with three different diagrams, a misinterpretation naturally prompts questions when the information does not align.
• Extreme Ownership: Extreme ownership gives me freedom because I know I am fully responsible for my actions and accountable for the results. I can reject workloads that are beyond my capacity. But for tasks I commit to, extreme ownership means not limiting myself to the boundaries of my formal role. It requires me to proactively follow up on other teams' progress, organize alignment meetings to keep everyone on the same page, push initiatives forward even when I am not the official lead, and try different approaches until the problem is solved.
• Reduce Friction in Decision Making: Humans are often the slowest point in any process. Two major bottlenecks are communication and decision-making. I try to anticipate the information and context stakeholders need in order to make decisions efficiently. When critical context is missing, stakeholders are more likely to escalate decisions upward for additional approval, which slows down execution and delays progress.
• Get Excited, Not Scared: For tasks that scare me, I try to treat them as challenges.