104
edits
User:Jeffrey Fisher/2023 Feedback Session Brainstorming: Difference between revisions
User:Jeffrey Fisher/2023 Feedback Session Brainstorming (edit)
Revision as of 19:25, 3 January 2024
, 3 January 2024no edit summary
No edit summary |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
|
= Questions =
==
== Onboarding ==
* What were some of the most confusing/annoying things/topics?
* Did you feel you had enough support from the leads?
* What are your opinions on the overall format? (written materials/tutorials, project progression, independent work with leads available to help and answer questions)
= Brainstorming =
== Feedback stream of consciousness ==
=== 3rd meeting time ===
* 2 meetings = 4 hours per week. 4 hrs/week * 15 weeks = 60 hours per semester. That's 1.5 full-time work weeks.
* Three 2-hr meetings would bring it up to 6 hrs/week --> 90 hours per semester. Which is 2 full-time work weeks.
=== How do we merge the 3 groups (Clark, NBRF, RAL)? ===
* If we can get the Clark room reserved all semester again, that could be quite nice. Could probably fit software + electrical.
** Not sure if mechanical can work effectively in Clark. They may need tools that we own, which could be annoying to carry.
* Clark has fit all catamaran members pretty well.
** Having our own private-ish space would be ideal though. Also tools access?
* RAL is medium-sized. Might not be able to fit everyone. However the rest of IDEA may be okay? We've met there before. However software team has grown a bit, so that might not work well.
* Software can probably meet wherever / with electrical and only go to NBRF for pool tests.
=== Monthly all hands meeting ===
* idea: Just present what there is to present?
** Not everyone presents every time, but hopefully a good enough rate that we always have something to present. More in-depth presentations.
=== Stricter deadlines ===
* My conception of this boils down to: "be honest". Not looking for superhuman work pace, and of course it is an extracurricular even if can be more intense than some.
** Come up with a plan. Feels good to check things off, and useful to have an overview of what is coming next.
** The plan should include estimates of how long things will take, and self-prescribed deadlines.
** Accountability. Awareness of when projects go off-plan.
** If we are coming up on a deadline, or miss a deadline, re-evaluate. Be honest about how much time we have. If something takes longer than we expected, the plan likely needs to be changed.
*** Cut things out of the plan. Move them to "extra". Shrink the minimum viable product.
*** Ruthlessly shrink the core plan. It's better to have something that partially works, that is partially tested, than to have nothing at all.
** Incremental plans. Continuous testing.
*** Try to reduce integration hell.
*** On software side, merge frequently. Avoid long-running branches when possible, and try to have long-running branches frequently integrate code from main so that we are always running with as much code connected as possible. Integrate incrementally over time, rather than in a massive integration hell.
=== Hangout more ===
=== How did onboarding V.1 go? ===
=== General club enrichment ideas ===
== Onboarding stream of conciousness ==
* Likely will switch to Python, that sound good?
** '''Goal:''' Free up time to focus on more robotics and core software engineering stuff, by not having to spend as much time on teaching you just how to use C++.
*** e.g. would probably add stuff about automated testing, API design
*** Would still have stuff like Linux, command line, but w/ Python we can focus more time on those rather than time on how to use C++, how to use CMake.
** e.g. for PWM we just tell you the three library functions that you need, their signatures, and link to the documentation.
*** Small: Probably need to explain what the Pigpio Handle is, since it says "int", though that may go away when using Python.
* Will provide more / bigger templates next year
** e.g. not looking for people to learn code organization. Next year I will provide a pre-made Git repository with compilable/runnable code already there. Somewhat like the output of <code>cargo init</code>, but even more than that and specific to the catamaran code structure.
* Git.
** It's a pain. Didn't really have any learning materials for it prepared.
** Probably should suggest a specific GUI tool. VS Code has a built-in tool, but I think it's mostly for simple operations. I assume GitHub Desktop is somewhat good?
* Ways to encourage more asking for help?
** Few times that people stuck it through a crappy problem rather than asking for help.
** Personally I am not great at asking for help. But from that I think a significant part of the problem may be a lack of knowing the difference between things that are not worth figuring out on your own and things that are valuable to figure out yourself.
* VS Code / IDE features
** Saw a lot of people trying to use the run button in VS Code. Fair enough, we recommended VS Code. Maybe should figure out the configuration for getting that to work. Probably low priority though. I don't use VS Code so it might not be easy for me to figure out, and there are many places where a terminal will be necessary, so we have to teach that anyways.
| |||