7 ms·
> Meetings and collaboration to figure out what to build, discuss issues etc. if these take up 10 hours a week [...] There's your problem.
by cloogshicer 5y ago
> Meetings and collaboration to figure out what to build, discuss issues etc. if these take up 10 hours a week [...]
There's your problem.
- yibg 5y agoWhy 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 agoHaving 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 agoYes 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 agoIf 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 agoI 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 agoYea 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 agoWhat 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 agoThe 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 agoWe 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 agoHeavily 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 agoBroadly, 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 agoForeign 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]
- rtlfe 5y agoWhat's the alternative? Have some PM+EM write a perfectly detailed spec for you to implement? That sounds like hell. I can't imagine spending all my time building something that I had no input on designing.
- tikhonj 5y agoI mean, that's one direction. But we could also give the part-time engineer more autonomy so that they can quickly make decisions on their own. They'll still need to spend time talking to people, but they can figure out an effective way to do that based on context—which might start out with them spending more time during the week just talking to people, but will fall off quickly once they build an understanding of their domain and the external interfaces of whatever they're building. If my experience is anything to go by, this sort of self-directed collaboration—think "design discussions" rather than "meetings" or "ceremonies"—will end up far more productive for everyone involved.
- rtlfe 5y agoThe comment that started this whole thing said "Meetings and collaboration to figure out what to build, discuss issues etc". I think that covers both categories of good and bad types of collaboration you describe here.
- deleted 5y ago[deleted]
- mattm 5y agoFor some engineers that would be bliss. They just want to churn through tickets and not have to talk to anyone (or very little).
- ebiester 5y agoAnd I can get someone for a quarter of the price who can do that on Upwork. (That isn’t to degrade anyone on upwork, but to point out that the code itself is a fraction of the job.) It might be more work to develop a specification that requires no context to complete than to do it myself. I too would crave a part time programming job, mind you, but I think that only works on a team that is completely part time.