Gregory's Server@mhoye first of all, a "how to work in teams" course or ten is apparently badly needed given my experience hiring recent CS grads, so this is a great question. I lack the breadth of experience to design such a course that would cover a wide enough range of possibility. But I would start with
non-programming associated disciplines, toxic vs healthy team dynamics, work/life balance, communication styles, code review cultures (taking/giving peer critique) plus "here's what the buzzwords mean"
|
Top-level
 12 comments
@mhoye I think about this a lot so I'll stop there, I could go on about "things I wish greenies came in knowing that aren't about computer science" for quite awhile I mean the main thing though is software is just ideas and is made by people and so if you got into computers to avoid people you're actually about to get a rude shock, but if you like people you'll actually do great in a healthy workplace Oh God, this Schools are terrible at teaching how to work in teams and junior devs fall into endless rabbit holes because they don't know how and when to ask for help, or let their pride prevent them from asking questions. It would also be delightful to instill a good mentor experience as well, so that they have a less toxic base to work from. @jrconlin @mhoye yep just assume I have to teach most non senior devs how to work in a team. And we have a super healthy communication driven work style where everyone is in everyone's tickets and code all the time so it's a bedrock requirement (outside our platform team which at this point is just super senior staff engineer wizards and another whole style) @mrcompletely @mhoye  @spodlife @mrcompletely @mhoye Yes, this is very true and important. A lot of faculty avoid teamwork themselves. A good research-based tool to improve student teamwork is CATME.org. @JMMaok @mrcompletely @mhoye @spodlife @mhoye curious if they were cross disciplinary teams or just a group of coders with similar skill sets? To me, a generic fully staffed dev team includes full stack engrs, front end specialist devs, possibly back end specialist devs, UX, PM, QA, plus product ownership and business stakeholders, with their actions mediated by a ticket system, chats, etc. Coding with other coders is the least of it. And then there's all the variations in team size/composition/style I mentioned elsewhere @spodlife @mhoye if the functional spec isn't clear do you know who to ask? If one of your issues bounces off QA after your code review and merge, do you pick it up or does it go back on the pile? If you pick it up, how do you know whether to do that or your current ticket first? What if you get 3 unfair seeming code review thumbs down in a row from the same person? How do you handle that? What if someone you like is heavily slacking or writing bad code? These are all things I've seen this week @spodlife @mhoye no, the unfair seeming reviews were last week 😂 Edit: note I'm not asking schools to teach answers to these questions since every shop has its own style. Just to make people aware of these dimensions to the work, which by and large seem to be totally opaque to recent grads unless they had a great internship experience. Also note I do generally like hiring recent CS grads overall when they fit our needs so I'm not just bitching about The Youths here @mrcompletely @mhoye |
@mhoye I think detailed examples of several wildly different work groups would be informative. This small team is all senior level and above, they have very lightly written specs, no PM, write all their own tests, bitch a lot but are really fine, etc. This large team has UX including both functional and UI specs, dedicated QA, intricate PM process etc. This gang of adorable cutting edge loons is building a game from their various polycules spread across several time zones.