Is coding more efficient than meetings?

This question is almost every engineer's "soul-searching dilemma." You feel like you can create a world when you sit down to code, but when you're pulled into a meeting, you feel like life is slipping away. This feeling is completely normal.

We can look at "efficiency" from two perspectives.

First, from the perspective of "individual output," you are absolutely more efficient when coding.

Coding is a creative task with immediate feedback. You write a feature, and it works; you fix a bug, and the program runs normally. This feeling is like a craftsman building a piece of art, where every strike and every polish brings the work closer to completion. This output is visible, quantifiable, and brings immense satisfaction and a flow state. An hour of coding might mean the birth of a new page.

And meetings? In an hour-long meeting, you might spend most of your time listening to others or engaging in seemingly "abstract" discussions. Meetings themselves don't directly produce code or fix bugs. From this perspective, they are, of course, "inefficient."

Second, from the perspective of "team output" and "avoiding waste," an effective meeting might be more "efficient" than you burying your head in code alone.

Let me give you an analogy: we need to build a ship. You're a top-notch carpenter; give you wood, and you can quickly build the hull.

• Scenario 1: You don't meet with anyone. You get the wood and start working, relying on your imagination and experience. After a month of hard work, you build a beautifully crafted hull. Then the designer comes to you and says the client's requirements have changed; they don't want a pointed bow, they want a flat bow. What do you do? A month's work is wasted, and everything has to be redone.

• Scenario 2: Before starting, you spend half a day in a meeting with the designer, sales, and the colleague responsible for making the sails. Everyone reviews the blueprints, confirms the ship's size, shape, purpose, and each person's division of labor. Although you didn't touch a single piece of wood during this half-day and felt "unproductive," it ensured that your next month of hard work would be entirely in the right direction.

This "meeting" process is for aligning goals, synchronizing information, and removing obstacles. Its purpose is to ensure that everyone on the team is pulling in the same direction, preventing wasted effort or conflicts due to poor communication.

A good meeting can resolve a critical decision and save a project weeks of detours. This kind of "efficiency" is exponential, though it's not as immediately visible as writing code.

So, your feeling is correct: for you personally, the per-unit-time output of coding is far higher than that of meetings. This is where your core value as an engineer lies.

However, for the entire team and project, a brief and efficient meeting can prevent future costs and waste that far exceed weeks of work from several engineers.

This is especially true for startups, where resources are limited, the cost of trial and error is high, and the biggest fear is the entire team rushing forward only to find they've run in the wrong direction.

Of course, in reality, what we dislike isn't meetings themselves, but "meaningless, lengthy, unprepared, purposeless" meetings. So, the key isn't whether to have meetings, but how to hold good meetings that truly serve to "align the blueprints" rather than waste everyone's time.