Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide architecture for briefings in Launch Project #29

Closed
kfklein15 opened this issue Mar 2, 2024 · 8 comments
Closed

Decide architecture for briefings in Launch Project #29

kfklein15 opened this issue Mar 2, 2024 · 8 comments
Assignees

Comments

@kfklein15
Copy link
Contributor

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

  • Define architechture
  • Clarify which design to be used
@kfklein15 kfklein15 changed the title Decide architecture for briefings Decide architecture for briefings in Launch Project Mar 2, 2024
@kfklein15 kfklein15 self-assigned this Mar 2, 2024
@kfklein15
Copy link
Contributor Author

@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?

@SallyMcGrath
Copy link
Member

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.

@kfklein15
Copy link
Contributor Author

@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.

@textbook
Copy link
Member

There's also a v2 in progress, discussed in #cyf-full-stack-starter-kit.

@oliverlloyd
Copy link

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

@textbook
Copy link
Member

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.:

  • Everything is request-response (including the starter kit!), nothing event-driven (as would have made sense for Good PR IMO) or scheduled
  • Any separation of concerns is ignored (e.g. we show React components fetching their own data and Express controllers that query DBs)

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.

@kfklein15
Copy link
Contributor Author

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.

@kfklein15
Copy link
Contributor Author

I will make changes to the Tech Lead role.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Status: Done
Development

No branches or pull requests

4 participants