Closed kfklein15 closed 4 months ago
@SallyMcGrath , one of the feedbacks of previous tech leads is that too much time and conflict of the Launch Module Teams (previous Final Project) is spent discussing architecture, which isn't something we teach and adds complexity for the Tech Lead. How do you feel about us adding a session of design/architecture to the open Briefings?
Hmmmm, I think I need more information before I can say really. Here are some maybe pertinent points around this subject:
We removed the specifications on React, Postgres etc, as those jobs are gone so we don't want to lock in there.
There is, however, a provided full stack starter kit with all those decisions taken. It has React etc - Jon maintains it. If the team is wasting its time on architecture then to some extent that's the TL's error? Just use the kit if the team isn't up to freestyling.
We want people to be able to diverge from that template if they are able. It's better for them. It's future proofing for everyone.
@oliverlloyd , this is what you raised last month. Can you give us more details on why the Full Stack Starter Kit isn't enough with the architecture side of it, please? Thank you.
There's also a v2 in progress, discussed in #cyf-full-stack-starter-kit
.
Can you give us more details on why the Full Stack Starter Kit isn't enough with the architecture side of it, please? Thank you.
I think the starter kit is great and indeed solves the problem of getting teams up and running quickly.
My point was more about the architecture of the solution they build. I've noticed teams get stuck when trying to build solutions because it isn't clear how things should fit together, especially when integrating 3rd party apis or setting up authentication.
I think it's valuable having experience solving these problems but it can be a challenging task even for an experienced developer.
Perhaps something that might help would be to give more architectural pointers on the briefings? Having some suggested approaches for certain knotty problems might help teams get started, avoiding some of the deeper rabbit holes
I think this is where the tech lead should fit in - these topics will be specific to the kind of task being solved (and how the team approaches solving it - there are usually mutiple valid options) and aren't covered during the course at the micro or macro levels, e.g.:
This is as you say a lot for trainees to take on at once in a time-constrained project. I also don't think it's representative of what would be expected of devs at their level (or at least not in a healthy org) - this is part of the reason I created the starter kit, as I saw several teams struggle with the same boilerplate setup to get something deployable to build on.
Authentication in particular is a complex topic that can easily take up the whole Launch schedule (some discussion here). I've considered (and spiked on - basically abstracting what's in https://github.com/CodeYourFuture/tech-products-demo) building a set of CYF auth components to plug into Express/React/React Router to do the basics via GitHub and cookies. There are generally also ways to avoid authenticating, e.g. using fake data, precreated users, etc. (but not if real external data is needed) but again team-by-team guidance is needed.
Thanks, both. If we believe some points are needed in the briefing, I would suggest creating a ticket to review them together and add them, since it will take some work. Or change/add something to the Tech Lead role description. Happy either way.
I will make changes to the Tech Lead role.
Background Not what they have to know for their first job Too much work for Tech Leads Created too much conflict in the team
Acceptance criteria