5 ms·

Why is this a problem? You can replace meeting time with time reading specs / requirement if you’d like. Point is you need some constant amount of time to under

by yibg 5y ago

Why is this a problem? You can replace meeting time with time reading specs / requirement if you’d like. Point is you need some constant amount of time to understand the problem domain. If 2 people need to do that then that’s twice the time needed.

Aeolun 5y ago
Having a meeting involves more than 1 person spending time. Reading a spec involved only one person investing time (only those that need to know it anyway). Doing it in a meeting where everyone has different questions, tangents and other cruft that you have to sit through is extremely inefficient.
- yibg 5y ago
  Yes but if you have 2 part time devs, that requires 2 people spending time. The discussion here isn't meetings vs doc, it's full time vs part time.
  - keerthiko 5y ago
    If you have 2 part time devs with a manager giving them the info in the meeting, that's 3 people spending time, and the two part-time devs won't have 100% overlap of information needed and questions asked and answered (and if you have two separate meetings with each PT, then they won't have access to the questions/answers discussed with the other dev _in case_ they need it). Additionally, everyone can focus on producing and consuming information in the downtime between focus-work sessions, without interrupting flow at someone else's convenience. In all cases, quality documentation is more likely to produce accurate information transfer with less time wasted by everyone involved.
    - yibg 5y ago
      I dunno. I for one wouldn't want to work at a place where I'm just handed a bunch of docs to implement. I want to be able to ask questions for clarification, suggest alternatives etc. All of which takes time.
yurishimo 5y ago
Yea this has been my experience as well. You either have meetings, or spend hours reading specs and a sync talking back and forth to ensure the requirements are correct. The only way I see real value is if you’re the sold dev/architect or if you can come in and confidently pick up tickets and they’re properly scoped and documented.
ryanSrich 5y ago
What are you building that requires an individual dev to read hours and hours of spec? I’d like to think my company builds some pretty cool shit, and even then, I can explain an issue in less than 2 paragraphs. If you need developers to spend so much time ideating and figuring out how and what to build, you’re mismanaging those developers imo.
- yibg 5y ago
  The time require by devs for non coding work is inversely proportional to how relatable the domain is and how specific the problem is. Tell me to build a clone of twitter and I can make a lot of autonomous decisions. Tell me to be an ERP and I'll be spending most of my time not coding. Most of software development are in domains that most people don't intuitively understand.
keerthiko 5y ago
We run a 5-person dev team (1 designer, 2 technical founders, 1 dev full-time, +1 part-time dev) with 30 minutes of sync-time per week for non-founders. Our part-time dev can perfectly run with those specs thanks to our encouragement of daily documentation and written specs rather than waiting for a big meeting to ask and be asked questions.
- yibg 5y ago
  Heavily depends on the nature of the work in question and size of team. Larger the team, and more foreign the domain the more time is needed to coordinate work.
  - keerthiko 5y ago
    Broadly, I disagree, at least when talking about any team or sub-team focused on software development. It depends more on the personalities, values and organization of the workplace and the team — for any size, if more than 20% of people involved need to spend more than 2 hrs/week in meetings — it is an organizational/ops issue, not an inherent feature of the work. > more foreign the domain the more time is needed to coordinate work More foreign to who? If it is foreign to individual team members, then it is a problem of insufficient onboarding/training material and process, poor documentation, or under-qualified hire.
    - yibg 5y ago
      Foreign to the engineers. Onboarding still takes time, regardless of documentation. There is a reason why CPAs takes a year to complete, even though there are lots of high quality written material that have been used for decades. Ever tried getting productive yourself quickly when working with some domain specific software like accounting? There is a lot of context that needs to be learned.
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
deleted 5y ago
[deleted]

by yibg 5y ago

Aeolun 5y ago

Having a meeting involves more than 1 person spending time. Reading a spec involved only one person investing time (only those that need to know it anyway). Doing it in a meeting where everyone has different questions, tangents and other cruft that you have to sit through is extremely inefficient.

yibg 5y ago
Yes but if you have 2 part time devs, that requires 2 people spending time. The discussion here isn't meetings vs doc, it's full time vs part time.
- keerthiko 5y ago
  If you have 2 part time devs with a manager giving them the info in the meeting, that's 3 people spending time, and the two part-time devs won't have 100% overlap of information needed and questions asked and answered (and if you have two separate meetings with each PT, then they won't have access to the questions/answers discussed with the other dev _in case_ they need it). Additionally, everyone can focus on producing and consuming information in the downtime between focus-work sessions, without interrupting flow at someone else's convenience. In all cases, quality documentation is more likely to produce accurate information transfer with less time wasted by everyone involved.
  - yibg 5y ago
    I dunno. I for one wouldn't want to work at a place where I'm just handed a bunch of docs to implement. I want to be able to ask questions for clarification, suggest alternatives etc. All of which takes time.

yurishimo 5y ago

Yea this has been my experience as well. You either have meetings, or spend hours reading specs and a sync talking back and forth to ensure the requirements are correct. The only way I see real value is if you’re the sold dev/architect or if you can come in and confidently pick up tickets and they’re properly scoped and documented.

ryanSrich 5y ago

What are you building that requires an individual dev to read hours and hours of spec? I’d like to think my company builds some pretty cool shit, and even then, I can explain an issue in less than 2 paragraphs. If you need developers to spend so much time ideating and figuring out how and what to build, you’re mismanaging those developers imo.

yibg 5y ago
The time require by devs for non coding work is inversely proportional to how relatable the domain is and how specific the problem is. Tell me to build a clone of twitter and I can make a lot of autonomous decisions. Tell me to be an ERP and I'll be spending most of my time not coding. Most of software development are in domains that most people don't intuitively understand.

keerthiko 5y ago

We run a 5-person dev team (1 designer, 2 technical founders, 1 dev full-time, +1 part-time dev) with 30 minutes of sync-time per week for non-founders. Our part-time dev can perfectly run with those specs thanks to our encouragement of daily documentation and written specs rather than waiting for a big meeting to ask and be asked questions.

yibg 5y ago
Heavily depends on the nature of the work in question and size of team. Larger the team, and more foreign the domain the more time is needed to coordinate work.
- keerthiko 5y ago
  Broadly, I disagree, at least when talking about any team or sub-team focused on software development. It depends more on the personalities, values and organization of the workplace and the team — for any size, if more than 20% of people involved need to spend more than 2 hrs/week in meetings — it is an organizational/ops issue, not an inherent feature of the work. > more foreign the domain the more time is needed to coordinate work More foreign to who? If it is foreign to individual team members, then it is a problem of insufficient onboarding/training material and process, poor documentation, or under-qualified hire.
  - yibg 5y ago
    Foreign to the engineers. Onboarding still takes time, regardless of documentation. There is a reason why CPAs takes a year to complete, even though there are lots of high quality written material that have been used for decades. Ever tried getting productive yourself quickly when working with some domain specific software like accounting? There is a lot of context that needs to be learned.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]

deleted 5y ago

[deleted]