Ask HN: Born to code forced to write confluence and attend meetings?
11 comments
Communication is essential, and improves my productivity. If you're not building what is required, your productivity is 0.
If your organization sucks at communication, then the meetings and confluence pages will suck, of course.
If your organization sucks at communication, then the meetings and confluence pages will suck, of course.
I don’t understand how writing documentation or attending meetings is “trivial”. Writing good documentation is a skill and is essential to effectively disseminate information throughout an organization. Meetings, if managed effectively, fosters collaboration and helps ensure everyone is on the same page. While you may love coding, as I do, we’re getting paid to solve problems and deliver business value. Communication is a critical element that ensures business value is delivered.
I certainly didn’t intend to undervalue the importance of strong and clear communication, which is undeniably crucial for the success of any team. However, my comment was aimed more at questioning the balance between the creation of documentation/meetings and the direct development work that contributes to shipping value.
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?
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?
This isn't a problem of just building vs meetings; it's the entire package of a company run by human beings.
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.
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.
You don’t get paid to write code. That’s a means to an end. You get paid for adding value to the business, solving problems, and multiplying the overall effectiveness of your team and the organization.
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.
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.
I agree with pretty much everything you’ve said. However, do you think that within most organizations there are workflows that could be made more efficient? That’s where I find some disagreement with your last point. By removing what’s seen as trivial, the focus shifts more towards the overarching goal of adding value, which, for most programmers, is often about shipping or refactoring code.
> focus shifts more towards the overarching goal of adding value, which, for most programmers, is often about shipping or refactoring code.
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.
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.
Your viewpoint is 100% understandable and agreeable. I also don’t consider the tasks you mentioned as trivial. However, for the sake of discussion and my own learning, do you view these tasks as directly critical to adding value as a programmer? Or do you see them as essential for establishing alignment, which, in turn, facilitates more efficient value creation? Personally, I believe the examples you mentioned are important but it’s hard for me to value the plan over the execution in such a rapidly adapting ecosystem. Not to tangent but I believe in the words of Mike Tyson everyone has a plan until you get punched in the mouth. We can plan, research and document but if the insight is found in the execution shouldn’t bottom line by trying to ship and iterate. My main point is objectives can often be succinctly summarized,and while the task you mentioned are important I think the weight we put to them discounts the value of just shipping. Our differing views might also stem from our backgrounds—I’m assuming (please correct me if I’m wrong) that you have more experience with larger development teams.
Yes, most organizations have inefficiencies. Reducing or removing those would likely add business value. But those inefficiencies don’t go away when people ignore them as trivial. If you identify an inefficiency do something about it. That may be in the code, or it may be in a business process.
This captures the essence of the discussion I’m aiming to foster. I realize that labeling tasks as “trivial” might undermine their perceived importance, as highlighted by the examples in my title and the primary discussion here. However, my goal is to spark a conversation about those simple, mundane, or “trivial” tasks that are crucial to your workflow, yet, in an ideal scenario(perfect information/100% aligned team), you’d prefer to allocate your efforts and time elsewhere. Additionally, I recognize that describing these tasks as both trivial and essential might seem contradictory, creating a bit of an oxymoron.
Developers hate meetings, but they can be very beneficial. I can't tell you the amount of times I've had miscommunications over slack/teams that were resolved with a 10 or 15 minute meeting.
How does this affect your productivity as a programmer?