Ask HN: Born to code forced to write confluence and attend meetings? What are tasks that seem too trivial for someone of your expertise but are nonetheless essential for your organization's bottom line? How does this affect your productivity as a programmer? |
If your organization sucks at communication, then the meetings and confluence pages will suck, of course.
From my experience, especially within the startup ecosystem, there’s a tendency to prioritize rapid development and iteration over extensive documentation and lengthy meetings. This approach is often rewarded in such environments because it aligns closely with the need to move quickly and adapt to market demands. In my view, a piece of well-written, efficient code that directly contributes to a feature or product often delivers more immediate value than the documentation that accompanies it. This perspective isn’t to say documentation isn’t necessary, but rather that its depth and scope should be carefully weighed against the urgency of delivering functional, value-adding features to the market.
Of course, this balance shifts as teams and projects scale. Larger teams and more complex projects require more structured communication and documentation to maintain coherence and alignment. The challenge, as I see it, is finding the right balance that allows us to remain agile and innovative without losing the thread of effective communication and documentation.
In essence, I believe in the importance of both coding and communication tasks. My aim is to spark a discussion on how we can better align our efforts to ensure that we’re not only creating value through our direct development work but also supporting that work with the necessary documentation and meetings in the most efficient way possible. How can we optimize our approach to these essential tasks to support our main goal of shipping value, especially in fast-paced environments?
There needs to be a certain amount of communication between the different "organs" of a company in order for it to run efficiently and effectively. With 2-3 people, it's easy: Just go up and talk to the person. Up to 10 people it's still pretty easy, although you now need some coordination to make sure you're not stomping over each other's stuff.
At 20-30 people, you can't get anything done without team leads/managers. And this management layer would then handle most of the day-to-day while pushing important information to the exec layer (likely 1-3 people).
Getting up to 50 people and now you need to expand the exec layer to cover finance, marketing, production, legal, mission, etc. You'll also have managers handling multiple teams, each with a team lead.
Up to 100 people and now you probably have two layers of middle management just to keep the information flow and coordination at human scale.
It's a lot like the elevator conundrum ( https://elevation.fandom.com/wiki/Elevator_conundrum ): The taller you build a building, the more space is needed by elevator shafts in order to get people efficiently between floors. There are tricks that allow you to use the elevators more efficiently, but eventually you hit a maximum. People don't like the elevator shafts taking up valuable space, but you also can't have an efficient building without them.
And the bigger your organization becomes, the more of these management and policy "elevator shafts" you need. And then your organization just starts to slow down. Innovation stagnates because it takes so damn long for an idea to make its way through the organization, get all the sign-offs, get funding etc. It's why Google can't innovate anymore, despite their attempts to bake innovation into their DNA. A quick visit to https://gcemetery.co/ is enough to show what that "innovation" policy accomplished, and demonstrates that this isn't a culture problem, but rather a human scaling problem.
And it's even worse with human scaling, because unlike elevator shafts, humans aren't cogs built to specifications. We also have to handle the chaos of different personalities and traits and skill levels in various things that contribute or detract from harmony IN THAT PARTICULAR ORGANIZATION (that's right: one org's success story can't just be transplanted to another).
So yeah, you're not just dealing with production and documentation and meetings; you're dealing with the whole package. And your solutions will have to take that whole package into account. And you'll have to keep revisiting it as your organization grows.
Taking a narrow view of what you can or should be doing — “that’s not my job” syndrome — is a sure way to get stuck in the lower rungs and feel like you don’t make a difference.
The programmers who mainly think their “productivity” depends on removing “trivial” things so they can focus on themselves and “DX” are hunting for jobs right now. Employers are getting wise to that nonsense. Productivity is not the goal, adding business value is.
Shipping and refactoring code doesn’t necessarily add value. What business objective is it solving? What are what are the requirements? Where are the design/research artifacts? All of these “trivial” tasks are what help enable you produce something valuable.